Blake Ramsdell wrote:
I don't believe that the current discussion should apply to the current
use of RC2 as a message encryption algorithm -- I don't think there is a
problem here. Changing this for the sake of being in parallel with RC2
when used as a KEK with DH is interesting, but unnecessary. I don't
believe that there is any complexity for implementors.
I think the only potential problem is using DH and RSA. It is quite
reasonable to assume that someone might want to send encrypted mail to
people some of whom have RSA certificates and some of whom have DH.
In this case the easiest way to deal with things is to have RC2 use the
same standard with DH and RSA for its key.
There are lots of other alternatives which might be regarded as better,
one is to explicitly include the keylength as an OPTIONAL parameter if
the content encryption algorithm needs it and then just make
recommendations in the spec with the proviso that the recipient MUST be
able to handle different keylengths.
Another solution is to just specify a standard for the wrapping key and
leave the content encryption key unspecified. That way whatever is used
for RSA it can be wrapped appropriately.
The only problem here (which may be due to my missing the latest key
wrapping spec) is that the key wrapping spec doesn't allow the length of
the "packaged" wrapped key to be unambiguously determined (except
through trial and error): my suggestion (in another message) about using
PKCS padding would fix that though.
Based on the underwhelming poll results (two responses), I'd say pick an
answer and write it up for the DH using RC2 as a KEK, and leave existing
RC2 MEKs alone. This is, of course, unless I'm missing something
significant about RC2's use as a MEK within the DH realm.
I counted three. Maybe there should be other alternatives, "don't care"
and "Whut?" :-)
Steve.
--
Dr Stephen N. Henson. UK based freelance Cryptographic Consultant.
For info see homepage at http://www.drh-consultancy.demon.co.uk/
Email: shenson(_at_)drh-consultancy(_dot_)demon(_dot_)co(_dot_)uk
PGP key: via homepage.