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
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
More information about the Gnupg-users