22

Suppose I want to encrypt a file so that only I can read it, by knowing my SSH private key password. I am sharing a repo where I want to encrypt or obfuscate sensitive information. By that, I mean that the repo will contain the information but I will open it only in special cases.

  1. Suppose I am using SSH-agent, is there some easy way to encrypt the file for only me to open it later?

  2. I cannot see why I should use GPG for this, question here; basically I know the password and I want to only decrypt the file by the same password as my SSH key. Is this possible?

|improve this question
27
+50

I think your requirement is valid, but on the other hand it is also difficult, because you are mixing symmetric and asymmetric encryption. Please correct me if I'm wrong.

Reasoning:

  1. The passphrase for your private key is to protect your private key and nothing else.
  2. This leads to the following situation: You want to use your private key to encrypt something that only you can decrypt. Your private key isn't intended for that, your public key is there to do that. Whatever you encrypt with your private key can be decrypted by your public key (signing), that's certainly not what you want. (Whatever gets encrypted by your public key can only be decrypted by your private key.)
  3. So you need to use your public key to encrypt your data, but for that, you don't need your private key passphrase for that. Only if you want to decrypt it you would need your private key and the passphrase.

Conclusion: Basically you want to re-use your passphrase for symmetric encryption. The only program you would want to give your passphrase is ssh-agent and this program does not do encryption/decryption only with the passphrase. The passphrase is only there to unlock your private key and then forgotten.

Recommendation: Use openssl enc or gpg -e --symmetric with passphrase-protected keyfiles for encryption. If you need to share the information, you can use the public key infrastucture of both programs to create a PKI/Web of Trust.

With openssl, something like this:

$ openssl enc -aes-256-ctr -in my.pdf -out mydata.enc

and decryption something like

$ openssl enc -aes-256-ctr -d -in mydata.enc -out mydecrypted.pdf

Update: It is important to note that the above openssl commands do NOT prevent the data from being tampered with. A simple bit flip in the enc file will result in corrupted decrypted data as well. The above commands cannot detected this, you need to check this for instance with a good checksum like SHA-256. There are cryptographic ways to do this in an integrated way, this is called a HMAC (Hash-based Message Authentication Code).

|improve this answer
  • 5
    You're right that an SSH key is an asymmetric key, not suitable for encrypting a file. And as a consequence, the commands you provide at the end won't work. You're attempting to encrypt a file with RSA, but you can only encrypt a very small payload with RSA (the size of the modulus minus the padding). The normal method is to generate a single-use symmetric key, encrypt that with RSA, and encrypt the real data with the symmetric key. It may be possible to import the ssh key in gpg, that would be the sane way to implement hhh's requirement — but using gpg with a gpg key is the right thing to do. – Gilles Mar 2 '12 at 0:53
  • 1
    Why do you suggest gpg with the symmetric -flag? It works also with "gpg -e something" but for different cases? – user2362 Mar 3 '12 at 22:25
  • 1
    @hhh I assumed that you would not share your files, so using just plain symmetric is more secure than using public key cryptography. No need for public/private keypair etc. From pgp.net/pgpnet/pgp-faq/… : "it is still believed that RSA is the weakest link in the PGP chain." This also applies to other pubkey mechanisms like x509. – vasquez Mar 5 '12 at 7:57
  • 1
    What would the openssl -one-liner look like? Something equivalent to $ gpg -e --symmetric? – user2362 Mar 5 '12 at 9:14
  • 1
    Use this to encrypt: openssl enc -aes-256-cbc -in my.pdf -out mydata.enc, decrypt with: openssl enc -aes-256-cbc -d -in mydata.enc -out mydecrypted.pdf both commands ask for the password. See man enc (on rh/fedora/centos) for all options like keyfiles, base64 encoding etc. – vasquez Mar 5 '12 at 12:55
21

I would prefer to use the openssl utility as it seems to be fairly ubiquitous.

Convert RSA public key and private key to PEM format:

$ openssl rsa -in ~/.ssh/id_rsa -outform pem > id_rsa.pem
$ openssl rsa -in ~/.ssh/id_rsa -pubout -outform pem > id_rsa.pub.pem

Encrypting a file with your public key:

$ openssl rsautl -encrypt -pubin -inkey id_rsa.pub.pem -in file.txt -out file.enc

Decrypting the file with your private key:

$ openssl rsautl -decrypt -inkey id_rsa.pem -in file.enc -out file.txt

But, as Gilles commented above this is only suitable for encrypting files smaller than your public key, so you could do something like this:

Generate a password, encrypt the file with it symmetrically, and encrypt the password with your public, key saving it to file:

$ openssl rand 64 | 
tee >(openssl enc -aes-256-cbc -pass stdin -in file.txt -out file.enc) |
openssl rsautl -encrypt -pubin -inkey id_rsa.pub.pem  -out file.enc.key

Decrypt the passphrase with your private key and use it to decrypt the file:

$ openssl rsautl -decrypt -inkey id_rsa.pem -in file.enc.key | 
openssl enc -aes-256-cbc -pass stdin -d -in file.enc -out file.txt

You'll end up with two files, your encrypted file and your encrypted passphrase, but put into a script it would work nicely.

You could even add a tar cvf file file.enc file.enc.key to tidy up.

Optimally, you would maximize the size of your passphrase as well changing rand 64 to the size of your public key.

|improve this answer
  • Very nicely done, considering the OP's quirky requirements. – rsaw Mar 4 '12 at 22:10
  • 2
    only just found this, nice post. I found that the maximum size symmetric key you can generate from the ssh-key is 12 bytes shorter than the ssh-key itself otherwise the rsautl would fail with "data too large for key size". So this worked in a script: KEYLEN_BYTES=$(ssh-keygen -l -f $PRIV_KEY | awk '{printf("%d", ($1 - 96) / 8)}') to autogen a key length. Given ssh-keygen has a minimum keylength of 768 bits, this still leads to minimum symmetric key of 672 bits, or 84 bytes. – markf Dec 18 '12 at 16:15
6

Look at luks/dm-crypt. You can use your ssh-private-key as encryption key by using the appropriate option.

Update: Example encryption using LUKS with a LV-block-device (LV test in VG system):

KEY=/home/youraccount/.ssh/id_dsa
DEVICE=/dev/system/test
cryptsetup luksFormat $DEVICE $KEY
cryptsetup luksOpen $DEVICE test_crypt --key-file $KEY

This should gnerate a block-device /dev/mapper/test_crypt which you can use to store your data on (after formatting it with a filesystem of your choice).

To get rid of it, umount it, and use cryptsetup luksClose test_crypt.

|improve this answer
  • Could you give MVO to do so it is easy to reuse? "$ sudo apt-get install cryptmount crypt-setup; cat '...' > bin/myEncrypt.sh; chmod +x bin/myEncrypt.sh; ./bin/myEncrypt.sh; ...; ..." If I can understand right, this method is a file-system-level encryption. It encrypts the fs which you need umount/mount or am I misreading this? – user2362 Mar 1 '12 at 0:18
  • 2
    I dont think this does what you think it does. The --key-file option to cryptsetup uses the actual content of the file as one big password. It doesnt read the openssl key out of the file and just use that. You can use a file of random bytes for the --key-file if you want. – Patrick Mar 2 '12 at 7:26
  • @hhh Yes this is a FS-level-encryption. – Nils Mar 2 '12 at 21:44
  • 4
    @Nils but what happens when he changes the password on his private key, he'll now be unable to decrypt his files as the data in the key file changed. --key-file is really a poorly chosen name for the option, it should be --password-file – Patrick Mar 2 '12 at 23:31
  • 1
    @Patrick This is true - changing the passphrase will change the file and thus the key (from the perspective of luks). But even from the perspective of ssh I would not name it a password file. I know that my answer does not hit the mark - but I think it will provide some ideas. – Nils Mar 3 '12 at 21:32

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy