AES-NI, symmetric key generation

[Pete Stephenson]

On 3/11/2015 6:55 PM, Maricel Gregoraschko wrote:
> 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.

Indeed. The folks who created the OpenPGP standard were quite
forward-thinking in regards to such 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.

Ah, that was my mistake: I forgot to specify that --show-session-key
only works when decrypting a message. Considering the intended purpose
of that option (being compelled to turn over a key), I suppose that's a
reasonable limitation in when it can be used.

> 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?

You'd have to ask Werner, the head developer, about that.

RFC 4880 completely specifies how the algorithms are implemented. In
theory, it should be possible to split a message into it's various
packets (gpgsplit is designed to do this), then decrypt the
symmetrically-encrypted packet using the method specified in the RFC,
but I have not attempted to do this.

Cheers!
-Pete