At 8:02 PM -0500 3/29/98, Russ Housley wrote:
All:
S/MIME 3 requires a function to encrypt one Triple-DES key in another.
Below, I propose such a function, and I am writing to request review of
that function.
Here is how S/MIME 3 will use the function. S/MIME 3 locally generate a
random content-encryption Triple-DES key. As the name implies, this key
will be used to encrypt the message content. Then, Diffie-Hellman will be
used to generate a pairwise Triple-DES key with each message recipient, and
the content-encryption key will be encrypted under the pairwise key. I was
unable to find a standard for the encryption of one Triple-DES key in
another Triple-DES key. The obvious encryption of the three DES keys in
ECB mode does not seem sufficient to me. This method would allow an
attacker to rearrange the three blocks and the recipient could not detect
the problem until the entire message we decrypted. So, I have proposed a
technique that provides confidentiality and integrity.
1) I know this is a stupid question because this has been accepted as a
given by the WG for quite a bit of time, but why is S/MIME using the
Diffie-Hellman algorithm, which requires a bit of wedging to work as a
store-and-forward key transport algorithm, rather than ElGamal? Note that
this proposal is basically identical to ElGamal, only it uses 3DES and a
checksum instead of modular multiplication and PKCS#1-style padding.
2) Unless S/MIME is only going to support 3DES, it seems that there must be
a method capable of wrapping keys other than 3DES keys. Is that the intent?
Why not just create a single wrapping mechanism for all kinds of keys?
(Note that this comment has nothing to do with the selection of 3DES as a
wrapping mechanism, just the fact that it wraps only 3DES keys.)
3) Is 16 bits the appropriate place to trade off the work factor for
causing a checksum collision with the overhead per recipient? Why not 8, or
24? (I don't have a problem with 16, I was just interested in why that
value precisely.) (Note that the work factor is actually 2^19, thanks to
the requirement that the resultant keys must have odd parity.)
4) You may want to clarify step 3a of the key checksum algorithm to "Create
a 16 bit integer, called temp, by setting the high 8 bits to zero and the
low 8 bits to the key octet." to avoid (probably unreasonable) endian-ness
confusion.
- Tim
Tim Dierks - Software Haruspex - tim(_at_)dierks(_dot_)org
"Well, cyberterrorists may be difficult to capture in the act, but from what I
know about people who are highly skilled with computers, they should be easy
to beat up." - Ernest Cey, quoted in The Onion, <http://www.theonion.com>