Here's some analysis on the RC2 effective key issue, thanks to Burt Kaliski.
----------
From: EKR[SMTP:ekr(_at_)rtfm(_dot_)com]
Sent: Wednesday, February 17, 1999 2:09 PM
To: Linn, John
Cc: 'ietf-smime(_at_)imc(_dot_)org'
Subject: Re: Comments on x942-05 draft
"Linn, John" <jlinn(_at_)securitydynamics(_dot_)com> writes:
In sec. 2.1.2, description of "algorithm": suggest adding the following
sentence at end: "As an implication, it may be appropriate for
algorithms
employing variable parameters other than key size to be represented with
different OIDs corresponding to different parameter combinations, if
parameter values cannot be unambiguously determined from usage context".
As
a related point, would it be acceptable to state that the structure of
suppPubInfo may be defined on a per-algorithm basis? For the case of
RC2
usage in S/MIME, where the key length is fixed to 128 bits, it seems to
offer more protective value to represent the variable effective key
length
within suppPubInfo than to represent the fixed 128 bit length.
Is this necessary? The simple partition attack obviously doesn't work.
Given knowledge about the 40-bit "effective key" generated by a given
128 bit key, do you get information about the 128-bit "effective key"
that would be generated?
An RC2 key has actual length t (fixed to 128 for S/MIME purposes) and
effective length k. RC2 key setup has two phases: (1) map t-bit actual key
into t-bit state, then (2) map last k bits of state into 128-byte table.
Partitioning can therefore take place in the state space. If an actual key
is used for both k=40 and k=128, an opponent can solve for the last 40 bits
of the state by a 2^40 exhaustive search against data encrypted with k=40.
--jl