I'm planning on writing a section on algorithm notes, because it seems
apparent that there are a number of things that need to be explained
explicitly.
The most important is what the symmetric algorithm preference is. It's a
list of symmetric algorithms that the keyholder accepts. If an algorithm is
not in the list, then the keyholder doesn't speak it, and consequently an
implementation MUST NOT use an algorithm absent from that list. If that
packet is absent, then it is implicitly stating a preference for 3DES, and
all keys implicitly accept 3DES even if unstated.
Similarly, the other algorithm preferences (compression, hash) state what
the keyholder accepts for those. The interesting case is the compression
preference, in which it is assumed you accept compressed data unless you
put in a preference for only uncompressed. We live with that because we
don't want to make compression a MUST, and we don't want to force all
existing keys to put in a compression preference.
Within this context, it is clearly wrong to use any encoding, be it a
cipher, a code (rot-13 is an code, and to my mind so is rot-n), or
plaintext (the null encoding) in a Symmetrically Encrypted Data Packet that
the recipient has not told you you may use. If a message is being encrypted
to more than one person, then you have to find a suitable algorithm from
the intersection of the recipients' preferences. The MUST algorithm (3DES)
is there to ensure than the intersection is not null. (To my mind, there is
a corrolary here that an implementation should (must?) warn someone when
they get a message that the implementation can decrypt, but the user
doesn't accept.)
I'm planning on a few other things in the algorithm section. Among them, I
plan some notes on Elgamal, particularly notes explaining the restriction
on an Elgamal key that is going to be used for signatures. I always thought
that "plaintext" means plaintext, with no CFB stuff, but after reading
tzeruch's comments, it seems that having 10 bytes of reset data is more
correct. Arguably, this is a way to satisfy the desire for a debugging
algorithm without grossing out the people who don't like the idea. Comments?
Jon
-----
Jon Callas jon(_at_)pgp(_dot_)com
CTO, Total Network Security 4200 Bohannon Drive
Network Associates, Inc. Menlo Park, CA 94025
(650) 473-2860
Fingerprints: D1EC 3C51 FCB1 67F8 4345 4A04 7DF9 C2E6 F129 27A9 (DSS)
665B 797F 37D1 C240 53AC 6D87 3A60 4628 (RSA)