Miscellaneous questions

Sven Radde email at sven-radde.de
Tue Apr 15 14:18:39 CEST 2008

Herbert Furting schrieb:
> But imagine the following:
> Yours: 3DES, AES256
> Mine: AES256, 3DES
> Which one is chosen now? But when I only include AES256 I can at least
> somewhat control it. 
If *you* send, it is AES; if RJH sent, it would be 3DES.
It doesn't matter if your key indicates a preference for 3DES, as RJH's 
implementation will assume that you have the availability to handle 
3DES, it will happily chose that.

Maybe, the "preference" setting on keys should be renamed to 
"capability". In practice, the ordering of algorithms in your key's 
"preference" string does not have soo much influence about what others 
will use when sending messages to you. The mechanism practically only 
guarantees that you can handle whatever is sent to you.
> Because A user might think 3DES is unsafe for his needs.
That user should get professional advice in implementing a security 
solution for his/her extraordinary needs. Plain GnuPG/OpenPGP is not 
necessarily the best choice for such an advanced scenario. Mind you that 
"PGP" means "pretty good privacy" and not "perfect global protection". 
For most people, however, the "pretty good" offered by OpenPGP equals to 
"way more than they'll ever need".

If you want to keep compatibility to OpenPGP, you should simply accept 
that you cannot completely control what algorithm is used for *incoming* 
messages. You can completely avoid sending 3DES encrypted messages, if 
you prefer.
If any particular user group finds that 3DES is unsafe for their needs, 
they can arrange for it that it is never used in communications between 
them. (Same goes for SHA-1 or uncompressed or ...) You might consider to 
use a modified gpg that warns you when it would choose 3DES for a 
message and give you the option of encrypting anyway or not sending the 
You might even want to modify GnuPG in a way that is incorporates a 
custom algorithm, such as Quintuple-AES or an 
AES-Serpent-Twofish-RC6-MARS cascade and distribute that within the user 
group which you target.
These changes of behaviour IMHO could even be done within the limits of 
the RFC. Alternatively, GnuPG could be modified in way that ignores the 
interoperability issues, which is probably fine if that version is only 
distributed within a closed group where you can control these issues for 

cu, Sven

More information about the Gnupg-users mailing list