Dr Stephen Henson <shenson(_at_)bigfoot(_dot_)com> writes:
I've been perusing the DH draft: great work!
Thanks.
I have a few comments.
2.1.4. Keylengths for common algorithms
Some common key encryption algorithms have KEKs of the following
lengths.
DES-ECB 64 bits
3DES-EDE-ECB 192 bits
RC2 (all) 256 bits
RC2-n in the content encryption cipher I take to mean a keylength of n/8
bytes and an effective keylength of n bits. I can't give a reference but
for me at least it's simply "what works" and established practice for
existing S/MIME implementations for RC2-128, RC2-64 and RC2-40.
Hmmm...
The RC2-RFC implies that standard practice is otherwise:
This memo describes a conventional (secret-key) block encryption
algorithm, called RC2, which may be considered as a proposal for a
DES replacement. The input and output block sizes are 64 bits each.
The key size is variable, from one byte up to 128 bytes, although the
current implementation uses eight bytes.
Can some of the implementors comment on what they do?
For my part, I'd prefer a standard key size with variable effective
key lengths.
This need not be followed for the key wrapping algorithms of course but
it might be preferable if e.g. "RC2-40" always refers to the same basic
algorithm.
We're talking about OIDs here, so they really have to have
a standard meaning.
Also the standard has SHA-1 hard coded. Perhaps this should be
selectable by the CMS with a default of SHA-1. This would allow for
healthy paranoia in that SHA-1 might be broken some day. Otherwise
changing it would be very painful if CMS had no provision for an
alternative digest function.
I see your point, however that requires some way to specify the
digest algorithm which means you have to worry about the
consequences of it being changed on the wire.
Considering that all the workable attacks on digest algorithms
seem to involve generating collisions, not reversing the
digest, and that collisions aren't a thread to this usage.
I think I prefer simplicity.
I suppose it could be commented that using an OCTET STRING for "counter"
to represent a number is a bit naughty and an INTEGER would be more
appropriate: but that doesn't really matter (to me at least).
Not my idea. That's the way it is in X9.42. Compatibility seems
more important than taste, in this case.
-Ekr
--
[Eric Rescorla Terisa Systems, Inc.]
"Put it in the top slot."