AES-NI, symmetric key generation

[Maricel Gregoraschko]

Pete,Very useful info about using --show-session-key to avoid revealing your private asymmetric key.In your example ("gpg --show-session-key < example.txt") , had you somehow set up gpg to use symmetric by default, rather than asymmetric + symmetric?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.
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 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.Thank you for your support.
      From: Pete Stephenson <pete at heypete.com>
 To: Maricel Gregoraschko <maricelgregoraschko at yahoo.com> 
Cc: gnupg-users at gnupg.org 
 Sent: Tuesday, March 10, 2015 10:36 AM
 Subject: Re: AES-NI, symmetric key generation
   
On 3/9/2015 6:15 PM, Maricel Gregoraschko wrote:
> Hello All,

Hi!

> 2.  When using symmetric encryption and providing a passphrase, I
> understand the actual encryption key is generated on the spot, used to
> do the encryption, and then discarded from memory and not stored
> anywhere, is that correct?

Correct.

> If the user wanted, can they dump the encryption key to store it
> securely, and use it to decrypt, instead of the password?

Yes, but the security is only as strong as the weakest link: if one uses
a weak passphrase to encrypt a message, an adversary could guess the
password.

If one used a long random string as a passphrase, this is functionally
equivalent to a strong key, so why bother with using the key itself to
decrypt instead of the passphrase?

You can show the symmetric session key for a message using the
"--show-session-key" option.

Here's an example of text I encrypted with "gpg --symmetric":
-----BEGIN PGP MESSAGE-----
Version: GnuPG v1

jA0EAwMCYFod0NxVEONgySM6oLcax81PoXTPKk2R+zdP2XZ+rA1ILbKy3+sg0xs8
B8SW2A==
=Iz40
-----END PGP MESSAGE-----

The passphrase is "test" (no quotes).

pete at kaylee:~$ gpg --show-session-key < example.txt
[prompt for password]
gpg: CAST5 encrypted data
gpg: gpg-agent is not available in this session
gpg: encrypted with 1 passphrase
gpg: session key: `3:62A2421F805F6CB1767A9DF07983ADDF'
gpg: example.txt: unknown suffix

Later, I can use gpg with the "--override-session-key" option to supply
the decryption key directly. Use "gpg --override-session-key [session
key]", using the format given above:

pete at kaylee:~$ gpg --override-session-key
3:62A2421F805F6CB1767A9DF07983ADDF < example.txt
gpg: CAST5 encrypted data
gpg: encrypted with 1 passphrase
Hello world!
gpg: WARNING: message was not integrity protected

See the manpage or https://www.gnupg.org/documentation/manpage.html for
more details.

One interesting note about show/override-session-key: if one is
compelled to decrypt a message (or else...), one can use those options
on messages encrypted using GnuPG's symmetric or the more usual
asymmetric (i.e., public key) encryption methods. The manpage says,
"This option is normally not used but comes handy in case someone forces
you to reveal the content of an encrypted message; using this option you
can do this without handing out the secret key."

In other words, if you're compelled to decrypt a message that was
encrypted to your public key, you don't need to hand over your private
key (which would allow someone to decrypt all your messages, sign new
messages, etc.). Instead, you would just hand over the encrypted message
and the session key used to encrypt it. Since each message uses a new,
random session key, only that single message can be decrypted and your
private key is not compromised.

Cheers!
-Pete





  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20150310/3e2dc630/attachment-0001.html>