Session Key Questions

[David Shaw]

On Wed, Sep 17, 2008 at 01:45:05PM -0400, vedaal at hush.com wrote:
> David Shaw dshaw at jabberwocky.com wrote on
> Wed Sep 17 18:21:42 CEST 2008 :
> 
> 
> >I think you're confusing the notion of the "default" algorithm with
> >the "preferred" algorithm.  The default algorithm in OpenPGP is 
> 3DES.
> 
> why then, if there are no preferences used, 
> or listed in the gpg.conf file,
> does gnupg use CAST-5 instead of 3DES 'by default' for symmetric 
> encryption when no key is used.

Symmetric encryption algorithm choices are not specified in RFC-4880.

> also,
> by when gnupg generates a new key, even though the top of the key's 
> preferences is AES, the cipher which protects the secret key, is 
> still CAST-5 and not 3DES

Secret key protection algorithm choices are not specified in RFC-4880
either.

> theoretically,
> if there were a new minimalist 'open pgp implementation' that used 
> only 3DES as its encryption algorithm, and gnupg send a 
> symmetrically encypted message,
> then 'by gnupg default settings' it would be incompatible.
> 
> (some people actually do send conventionally encrypted messages to 
> users they know personally, ;-)

If you drive a manual-shift car, you are responsible for shifting.

> "great to hear that you're using an open-pgp program,
> i'll be sending you my public key in an encrypted message that only 
> needs a passphrase,
> i wrote it down for you, here,
> then send me a reply that is encrypted to my key"

Why would you do something that is a) more complex, b) less secure,
and c) very prone to failure?  There are standard ways to do these
things.  Sure, you can force it to break if you try hard enough, but
why would you want to?

> theoretically, also
> if someone wanted to use this new program that had only 3DES, and 
> tried to import a keypair made with the default setting in gnupg, 
> it wouldn't be usable, because the secret key is, 'by default' 
> protected with CAST-5, not 3DES

Secret key protection algorithm choices are not specified in RFC-4880.

David