3

I'm configuring scripts etc. to use GPG's symmetric mode to encrypt some files on my home desktop system.

When I want to edit one of the encrypted files I decrypt it and pipe it into my editor and then, to save it, the editor writes the file to a named pipe and the following encrypts it:-

echo $pwd | gpg --symmetric --passphrase-fd 0 epipe

The named pipe, epipe, is then deleted.

This works fine as long as there is no MDC integrity checking but if I use --force-mdc or use a cipher which defaults to doing MDC then the above command hangs. I think this must be because gpg is trying to read the MDC string from epipe as well as the file data and the read blocks.

If I want to use AES256 does turning off MDC integrity checking actually make things any less secure? These are files used only by me, never exchanged with others.

1

The original issue was because I was trying to (reasonably) securely feed both the password/phrase and the file to be encrypted into gpg.

I have a simple script that decrypts the file and feeds it (via a pipe) into my editor. The script asks for the password and it's kept in an environment variable, not perfect but better than putting it in a file or something.

The difficult bit was, after editing the file, to get both the file and the password back into gpg. It turns out that gpg is actually quite well behaved and where it says " Only the first line will be read from file descriptor n." in the --passphrase-fd description it really means it. Thus you can simply prepend a line containing the password to the file to be encrypted and pipe both into gpg, as follows:-

<password + file> | gpg --symmetric --passphrase-fd 0 >file.gpg

I can now have:-

s2k-cipher-algo AES256 s2k-digest-algo SHA512 s2k-count 65011712

in my gpg.conf file such that MDC integrity protection is used (because it comes with AES256) and so I don't get any warnings.

I edit these files on my own home desktop computer so using an environment variable for the passphrase is reasonably OK and I have avoided saving anything in a file anywhere that might persist if something dies on the way.

0

The modification detection code especially prevents a rather esoteric decryption oracle attack, which does not seem applicable in case of locally encrypted files only relevant when you're able to repeatedly send an encrypted message to some decrypting entity revealing some success information on valid or invalid encrypted messages.

In the end, the modification detection code will allow you to realize the encrypted data was changed (and thus would result in garbled plain text after decryption), if not signing the message anyway (signed messages cannot be modified without breaking the signature, anyway). So, as long as you don't need the integrity check during decryption, but only require privacy of the information, you're safe without the MDC.

  • I've found a workaround. I can feed both the password and the file to be encrypted into gpg via stdin. With the --passphrase-fd 0 option gpg only reads one line as the password and, if no input file is specified on the command line, the rest of stdin is the file to be encrypted. This allows me to avoid using any temporary files at all. – Chris Green Oct 11 '15 at 14:58
  • @chrisgreen you may want to answer your own question. It might help readers of this question find the best answer – Neil Smithline Oct 12 '15 at 0:49

Your Answer

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

Not the answer you're looking for? Browse other questions tagged or ask your own question.