Subject: RE: Comments on x942-05 draft

From: "Linn, John" <[email-masked]>
Date: Fri, 19 Feb 1999 08:50:30 -0500

Here's some analysis on the RC2 effective key issue, thanks to Burt Kaliski.

> ----------
> From: 	EKR[SMTP:[email-masked]]
> Sent: 	Wednesday, February 17, 1999 2:09 PM
> To: 	Linn, John
> Cc: 	[email-masked]'
> Subject: 	Re: Comments on x942-05 draft
> 
> "Linn, John" <[email-masked]> 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

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 22 Feb 1999 09:14:20 -0800

> Here's some analysis on the RC2 effective key issue, thanks to Burt Kaliski.
[...]
Clearly we do have to defend against the partition attack on effective
key lengths. 

As John suggests, I propose that we place the RC2 effective key 
length into the the suppPubInfo. However, this leaves us with
an unfortunate inconsistency, in that for some algorithms it's
the length and some it's the effective length. One solution
to this would be to revert to what Stephen Henson has termed
the X/8 strategy. I.e. make the effective and real lengths
the same for RC2. This is slightly more tasteful than having
a bunch of special case language.

Comments? I'd like to get this settled quickly.

-Ekr
[Eric Rescorla                                   [email-masked]]

---

From: Russ Housley <[email-masked]>
Date: Thu, 04 Mar 1999 12:57:26 -0500

Eric:

I am comfortable mandating the effective and real key lengths are the same
for the calculation of the key-encrypting key.  If some policy wants to use
a reduced effective key length for the content-encryption key, thsi can
still be accomodated.

Russ