[Top] [All Lists]

Re: IDEA licensing vs RSA licensing (Re: What do we have to do today?)

1997-11-04 12:19:20
At 01:37 PM 11/2/97 GMT, Adam Back wrote:
   It may not be necessary to have CAST5 to be interoperable with pgp5.x
   -- the symmetric cipher capability flags which are attached to public
   keys would allow people not implementing "MAY/or just OID listed"
   CAST5 to warn pgp5.x that they can't handle CAST5.
   Or stated the other way around, if CAST5 is not to be listed as a
   SHOULD, there better be a way to tell pgp5.x not to send email
   encrypted with CAST5 which reliably ensures you don't get CAST5 in
   your mailbox.  By reliably I mean even with Cc combinations of people
   with different combinations where multiple recipient encryption is
   Perhaps someone from PGP Inc with a better understanding of how this
   works (as the draft is not out yet) could explain how this would work
   There may even be that there is a case for CAST5 to be a SHOULD for
   compatibility with pgp5.x.  PGP Inc clarifications please!

The whole reason I originally suggested that CAST5 be a SHOULD algorithm
was my principle that any algorithm needed for compatibility ought to be a
SHOULD algorithm. Since then, though, Hal told me that PGP 5.x does not
need CAST5 to be a SHOULD algorithm. In other words, given that Triple-DES
is the MUST algorithm, a MUST-only implementation can interoperate with PGP
5.x. This is why I'm leaning away from making it a SHOULD. If Triple-DES is
the MUST, and IDEA is a SHOULD, everything else can be a MAY and you still
have maximal backwards compatiblilty. (Again, the most RSA or IDEA can be
are SHOULD algorithms.) 

If you have a message that is encrypted to more than one recipient, and
they all have their preferences, you quickly get to the MUST algorithm
being the lowest common denominator. The painful rub for our current
situation is that the MUST algorithm can't be the one for backwards
   > My understanding is that CAST5 is the default algorithm in 5.x, if
   > it is not a MUST or SHOULD there still should be some mention that
   > it is the default in PGP and those wishing to be able to communicate
   > with 5.x users will need to implement it. Simmilar documentation
   > should be provide in regards to 2.6.x and the RSA/IDEA/MD5
   > algortihms.
   I agree with the need to document cipher mode as well as OID -- for
   instance the IDEA mode is particularly odd: a non-standard CFB and it
   has particular checksum requirements.  (8 byte random junk is
   encrypted to act as IV, and then 2 bytes of checksum repeating the
   last 2 bytes of the random junk.  In addition something weird is done
   to the feedback at semantic boundaries in the message.  Personally I
   find this quirky mode annoying, but we've got it now for backwards
   compatibility.  Is this quirky semantic context variable length
   feedback CFB used with CAST5 and 3DES?)
Hal can speak most clearly on this, but my understanding is that all the
cyphers do the same thing.


Jon Callas                                  jon(_at_)pgp(_dot_)com
Chief Scientist                             555 Twin Dolphin Drive
Pretty Good Privacy, Inc.                   Suite 570
(415) 596-1960                              Redwood Shores, CA 94065
Fingerprints: D1EC 3C51 FCB1 67F8 4345 4A04 7DF9 C2E6 F129 27A9 (DSS)
              665B 797F 37D1 C240 53AC 6D87 3A60 4628           (RSA)