AES-NI, symmetric key generation

Wed Mar 11 18:55:20 CET 2015

Thank you Pete for clearing things up. Makes a lot of sense to store passphrase-to-key identification data, in addition to actual algorithm used, in the output message rather than have the decryptor just assume things.
I figured out how to use --show-session-key: in my tests it doesn't show the key when encrypting, only when decrypting, that's good enough, I'm ok with doing a test decryption just to show the key.
One more question: Is there any standardization in output formats between encryption programs and libraries, for example say you encrypt with AES128 in CBC, with the same key (directly or via passphrase), and since the output will have to have, in addition to the actual ciphertext, algorithm indentification on it, possible pasphrase-to-key, plus mode-specific data such as the iv/nonce, is there a specification of the format of how these come in?Thanks!

      From: Pete Stephenson <pete at heypete.com>
 To: Maricel Gregoraschko <maricelgregoraschko at yahoo.com>; gnupg-users at gnupg.org 
 Sent: Tuesday, March 10, 2015 5:32 PM
 Subject: Re: AES-NI, symmetric key generation

On 3/10/2015 8:28 PM, Maricel Gregoraschko wrote:
> Pete,
> Very useful info about using --show-session-key to avoid revealing your
> private asymmetric key.

No worries.

> In your example ("gpg --show-session-key < example.txt") , had you
> somehow set up gpg to use symmetric by default, rather than asymmetric +
> symmetric?

No. It was a nearly "out of the box" setup with only some minor changes
to my gpg.conf file in regards to accessing keyservers. Nothing that
would affect the modes of encryption.

> If I explicitly pass --symmetric, --show-session-key does nothing
> (gpg4win) (and I guess the key is not really a random "session" key as
> when sending a PGP message) but rather the key deterministically
> generated from the passphrase.

Works fine for me. Try copy-pasting the text into the command prompt
rather than reading from a file. Use Ctrl-Z then Enter to tell GnuPG
you're done entering a message and it should start processing things.

Here's an encrypted message I generated with "gpg --symmetric --armor"
on GPG4Win 2.2.3:

-----BEGIN PGP MESSAGE-----
Version: GnuPG v2

jA0EAwMC2lG4z3grm9G1ySTYXvITlKTun7NvaLnznJZI4AhGJyTk+rFkAdufNRzB
cC6eqAI=
=j73k
-----END PGP MESSAGE-----

(password is "test" with no quotes)

gpg --show-session-key yields a session key of
"3:C4A5BBCBB7C8F846FCA3A9BDDED0EB7F".

The same message encrypted a few seconds later with the same password
yields:

It appears that GnuPG uses the iterated-and-salted secret-to-key method
(see https://tools.ietf.org/html/rfc4880#section-3.7.1.3 ) to generate
the session key.

You're right: the key is derived from a passphrase and so is not truly
random, but the salt is random which helps a bit. Of course, the salt is
not encrypted, so the message protection depends only on the strength of
your passphrase.

> I agree, using key instead of passphrase doesn't enhance security
> (assuming an attacker knows that the key was derived from a passphrase
> and with what key derivation algorithm? I assume the randomness/entropy
> of the key itself is high enough regardless of the passphrase strength?). 

The attacker would be able determine quite a bit of information about
how the message was encrypted (as this same information would be needed
by a legitimate user to decrypt the message):

Here's an excerpt from the double-verbose (-vv) output from the second
encrypted message above (all this is available without entering the
passphrase):

:symkey enc packet: version 4, cipher 3, s2k 3, hash 2
        salt 8272250a9f3a68ba, count 2752512 (181)

The attacker would know the cipher being used (cipher 3 = CAST5), the
fact that the key is derived from a user-provided string (the fact that
s2k is used), which string-to-key algorithm is used (s2k 3 =
iterated-and-salted), the hash used (hash 2 = SHA-1), the salt, and the
number of times to iterate the S2K algorithm.

The attacker won't know the strength of your passphrase -- it could be
"cat" or a long string of random characters -- but it tells them that
the key was generated using user-provided input.

> The reason I was asking if it's a possibility to store the symmetric key
> to decrypt with later, was to protect against future changes in the key
> derivation algorithm, that would make gpg generate a different key for
> the same passphrase, useless to decrypt previously encrypted data.

GnuPG follows the OpenPGP standard (RFC 4880). The standard defines
certain key derivation algorithms and provides the ability to add new
ones if needed. Adding new key derivation algorithms in the future
should not have any affect on existing encrypted messages.

Since each message clearly identifies the algorithm used to encrypt it,
future versions of GnuPG should have no problem decrypting it. Indeed,
the current version of GnuPG is able to decrypt messages generated from
old (even ancient!) versions of PGP and GnuPG with few, if any, issues.

Cheers!
-Pete

-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20150311/a8a499c3/attachment.html>