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

[Adam Back <aba@xxxxxxxxxxxx>]

William Geiger <whgiii@xxxxxxxxxx> writes:
> >>[MUST = DSA/EG/3DES
> >> SHOULD = RSA/IDEA/MD5]
> >
> >A very basic reason: SHOULD is only for things that are strongly desired
> >by all implementations. If we have a strong algorithm for a MUST and
> >another strong algorithm for a SHOULD, I see no point to tossing another
> >SHOULD in. Many developers try to implement all SHOULD-level specs, and
> >this would cause needless software bloat with little definable benefit.
> >
> >And, again, I would strongly lobby against any MAY list. A list of IDs
> >for all known algorithms identifiers is enough.
> 
> Well FWIW I don't have a problem with only having one MUST and one SHOULD
> but if we are going that route there should be some documentation on what
> algorithms PGP 2.6.x & PGP 5.x are using and what the default operations
> are so implementors can insure that they have compatability with the
> current software available. 

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
used.

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
out.

There may even be that there is a case for CAST5 to be a SHOULD for
compatibility with pgp5.x.  PGP Inc clarifications please!

> 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?)

Adam
-- 
Now officially an EAR violation...
Have *you* exported RSA today? --> http://www.dcs.ex.ac.uk/~aba/rsa/

print pack"C*",split/\D+/,`echo "16iII*o\U@{$/=$z;[(pop,pop,unpack"H*",<>
)]}\EsMsKsN0[lN*1lK[d2%Sa2/d0<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<J]dsJxp"|dc`