Unusual (unintended?) behavor upon decryption of a message

[Peter Lebbing]

On 19/11/13 22:37, vedaal at nym.hush.com wrote:
> But this isn't the way hybrid gnupg messages work.
> 
> Gnupg does not use one symmetric algorithm to encrypt the session key, and
> then another to encrypt the message. The user can choose 'which' symmetric
> algorithm to use, but it will be the same for both.

I only did a quick check of RFC 4880, and that (section 5.3) clearly states
there is an octet for the symmetric algo used inside the encrypted part:

> The decryption result consists of a one-octet algorithm identifier that
> specifies the symmetric-key encryption algorithm used to encrypt the
> following Symmetrically Encrypted Data packet, followed by the session key
> octets themselves.

So even if GnuPG always picks the same algo for both, the format of an OpenPGP
message still separately specifies the algo for the data.

> My question is, is there oracle behavior on gnupg's part which will allow an
> attack on the string-to-key part of the symmetric encryption?
>
> If an attacker knows which symmetric algorithm was used, then concentrating
> of the first few characters of the passphrase, and trying variations of
> those, until gnupg identifies the correct algorithm, then gnupg may 'leak'
> the first few characters of the passphrase when the correct algorithm is
> identified, even if the message is not yet decrypted.

How is this different from just writing your own implementation for decrypting
the symmetrically-encrypted session key packet? Why would you abuse the GnuPG
binary for this? The GnuPG binary doesn't provide the security, the encryption
on the file does that.

Furthermore, since the password is iteratively hashed with a salt, I don't think
it would be possible to leak anything about the first few characters of the
password. A hash evenly spreads all characters over the key (I'm oversimplifying
a bit here).

You just know the first octet of the plaintext of the symmetrically encrypted
session key packet; the rest is utterly random. This is even a better situation
than with "Monthly results.doc.gpg" where you probably know a lot of the header
of a Microsoft Word document; it would be a lot easier to immediately attack the
symmetrically-encrypted data than to first attack the session key packet and
then try that on the data.

When I say a lot easier, I still mean utterly impossible, though ;).

HTH,

Peter.

-- 
I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
You can send me encrypted mail if you want some privacy.
My key is available at <http://digitalbrains.com/2012/openpgp-key-peter>