The following command works even though I really don’t think I should have permission to the key file:
$ openssl aes-256-cbc -d -pbkdf2 -in etc_backup.tar.xz.enc -out etc_backup.tar.xz -k /etc/ssl/private/etcBackup.key
I’m unable to even ascertain the existence of the key file under my normal user. I’m a member of only two groups, my own group and vboxusers.
The permissions leading up to that file:
drwxr-xr-x 1 root root 4010 Jul 31 08:01 etc
...
drwxr-xr-x 1 root root 206 Jul 14 23:52 ssl
...
drwx------ 1 root root 26 Jul 31 14:07 private
...
-rw------- 1 root root 256 Jul 31 14:07 etcBackup.key
OpenSSL isn’t setuid:
> ls -la $(which openssl)
-rwxr-xr-x 1 root root 1004768 Jul 14 23:52 /usr/bin/openssl
There don’t appear to be any ACLs related to that key file:
> sudo getfacl /etc/ssl/private/etcBackup.key
[sudo] password for root:
getfacl: Removing leading '/' from absolute path names
# file: etc/ssl/private/etcBackup.key
# owner: root
# group: root
user::rw-
group::---
other::---
> sudo lsattr /etc/ssl/private/etcBackup.key
---------------------- /etc/ssl/private/etcBackup.key
Finally, it’s not just the case that the original file was encrypted with an empty file:
> openssl aes-256-cbc -d -pbkdf2 -in etc_backup.tar.xz.enc -out etc_backup.tar.xz -k /etc/ssl/private/abc.key
bad decrypt
4047F634B67F0000:error:1C800064:Provider routines:ossl_cipher_unpadblock:bad decrypt:providers/implementations/ciphers/ciphercommon_block.c:124
Does anyone know what I’ve missed here?
I have about 0 experience with openssl, I just looked at the man page (openssl-enc). It looks like this command doesn’t take a positional argument. I believe the etcBackup.key file isn’t being read, as that command simply doesn’t attempt to read any files without a flag like -in or -out. I could be wrong though, see previously stated inexperience.
Almost. -k is to supply the passphrase directly, while -kfile does what OP believes -k does. That’s why it reports “bad decrypt” as well.
It seems OP wanted to pass the file name to
-k, but this parameter takes the password itself and not a filename:-k password The password to derive the key from. This is for compatibility with previous versions of OpenSSL. Superseded by the -pass argument.So, as I understand, the password would be not the first line of
/etc/ssl/private/etcBackup.key, but the string/etc/ssl/private/etcBackup.keyitself. It seems that-kfile /etc/ssl/private/etcBackup.keyor-pass file:/etc/ssl/private/etcBackup.keyis what OP wanted to use.Oh that’s nasty. I bet a quick github search would turn up some people making the same mistake.
The -k argument on my openssl accepts a passphrase, not a file. You likely encrypted with the filename as the secret, not it’s contents. Perhaps you should use -kfile instead.
$ openssl aes-256-cbc -help Usage: aes-256-cbc [options] General options: -help Display this summary -list List ciphers -ciphers Alias for -list -e Encrypt -d Decrypt -p Print the iv/key -P Print the iv/key and exit -engine val Use engine, possibly a hardware device Input options: -in infile Input file ** -k val Passphrase** -kfile infile Read passphrase from fileWow, thanks for this. Those are two very similar flags and I missed this entirely.
Everyone - Now that you know my passphrase, be sure to keep it a secret!
On my machine at least
man opensslshows that-kis for specifying the password you want to derive the key from, so in that case I think you are literally using the string/etc/ssl/private/etcBackup.keyas the password. I think the flag you want is-kfile.You can verify this by running the command in
straceand seeing that there is noopenatcall for the file passed to-k.Edit: metiulekm@sh.itjust.works beat me to it while I was writing out my answer :)
Just to verify all permission-related things in one go, see if you can open the key as your user with an editor like vi or nano. This will let you separate out some behavior specific to OpenSSL vs some behavior purely permissions-based.
I’m not sure what’s happening here, but the above test can at least narrow the focus.