We continue to have an RC2 keylength issue. Russ has
asked me to do a straw poll to resolve it.
To review, RC2 is a cipher which accepts a key of variable
length and which incorporates a keyspace reduction function
to control the effective keylength of the cipher. These
sizes don't have to be related, except of course that the
key length must be of greater size than the effective
number of bits. There has never been a written standard
clearly stating how long the key should be for a given
number of effective bits, although the RC2 RFC states
that a fixed length 64 bits (8 bytes) is common.
This is clearly inappropriate in the S/MIME case, however,
since one of our choices is 128 effective bits.
Why wasn't this an issue before?
All that is required is that the sender and receiver agree
on the length of the key. When using RSA (the only key exchange
algorithm in S/MIME v2) the PKCS-1 padding explicitly provides
the length of the wrapped key, so there is agreement.
Why is this an issue now?
The Key Agreement mechanism specified in draft-ietf-smime-x94-00
specifies two uses for RC2 keys. In neither case is the keylength
explicitly provided in the message. The first case is as a
Key Encryption Key which is generated as the output of a SHA-1
digest. The second case is the familiar Message Encryption Key,
which is wrapped according to section 12. As a consequence, we
need to have a standard for how long the key will be so that
the sender and receiver can agree.
What's standard practice?
It seems that there isn't any. Due to the aforementioned
feature of RSA, implementors were free to choose any keylength
they wanted while remaining interoperable, and according to
Blake Ramsdell at the Chicago IETF, they have done pretty much
that.
What are our choices?
"OPTION 1: RC2 Key Length X/8"
We choose the actual keylength to be equal to the effective
keylength. I.e. 40 bit RC2 has a 5 byte key.
Pros
(1) Slightly faster when wrapping an MEK for 40 bit RC2
since you don't need to wrap as many blocks worth of key.
(2) May be slightly more common.
Cons
(1) Less obviously secure.
(2) More complicated to code and test.
"OPTION 2: RC2 Key Length Fixed"
Pros
(1) Simpler to code and test.
Cons
(1) Slightly slower key wrapping for 40 bit RC2
To vote, send an email to ietf-smime(_at_)imc(_dot_)org with one of
the following subject lines:
"OPTION 1: RC2 Key Length X/8"
"OPTION 2: RC2 Key Length Fixed"
Don't bother with a message body, I am just going to count the
messages. Discussion of the content of this message should reply to
this message.
-Ekr
[Eric Rescorla ekr(_at_)rtfm(_dot_)com]