Subject: RC2 Keylength Strawpoll

From: Eric Rescorla <[email-masked]>
Date: Fri, 02 Oct 1998 17:02:50 -0700

Russ has requested that I summarize the results of the RC2 keylength
strawpoll and close out this issue. Unfortunately, the strawpoll
reached no clear consensus. (It's pretty much dead even).

Consequently, we're going to leave things more or less as-is. RC2
keys MUST be 16 octets, both when used as KEKs (the output of DH
computations) and MEKs. Implementations SHOULD accept other length
MEKs when RSA encrypted, in the interest of backwards compatibility.

If you have an objection to this (admittedly flawed) decision
procedure (I.e. I as document editor just decide), speak up now.
This isn't the time for substantive technical argument, however.

Thanks,
-Ekr
[Eric Rescorla                                   [email-masked]]

---

From: Dr Stephen Henson <[email-masked]>
Date: Sat, 03 Oct 1998 14:35:24 +0100

> This isn't the time for substantive technical argument, however.

Fair enough. Just a few comments.

For the record what was the actual result?

IMHO CMS needs a specific comment re RC2. Currently it doesn't
specifically exclude RC2 with keylength > 128 in DH.

Is this going to apply to the other two possibilities, E-S and S-S DH?

There was never any mention of why the key wrapping standard or CMS
couldn't be changed to allow the MEK length to be determined explicitly
and thus enable current RSA implementations to be unchanged in mixed RSA
and DH environments. As I recall one parameter in CMS or the alteration
of key wrap to use standard block padding would allow this. Did you see
this discussion Russ?

Steve.
-- 
Dr Stephen N. Henson. UK based freelance Cryptographic Consultant. 
For info see homepage at http://www.drh-consultancy.demon.co.uk/
Email: [email-masked]
PGP key: via homepage.

---

From: EKR <[email-masked]>
Date: 04 Oct 1998 15:13:48 -0700

> For the record what was the actual result?
4-4.

> specifically exclude RC2 with keylength > 128 in DH.
Fair enough. Paul, Can  you add the appropriate ocmment?

> Is this going to apply to the other two possibilities, E-S and S-S DH?
That's what it's intended to apply to, yes. As you know, DH
is the case that creates this problem in the first place.

> and DH environments.
Correct. This could be done and it's a separate issue.
I'd argue against it on consistency grounds, but I'm not
violently opposed to it. Perhaps Russ would like to weigh in,
since wrapping is really his document.

-Ekr

---

From: Russ Housley <[email-masked]>
Date: Tue, 06 Oct 1998 11:55:14 -0400

Eric & Steve

I would like to keep the key wrap algorithm as simple as possible.  It is
getting too complex already.

Perhaps the key agreement AlgorithmIdentifier should have two paramters,
both AlgorithmIdentifiers.  One alg id tells the key agreement technique
and the second tells the key wrap technique.  This should make it more
flexible for the future.

Russ

---

From: Dr Stephen Henson <[email-masked]>
Date: Tue, 06 Oct 1998 22:14:39 +0100

> and the second tells the key wrap technique.  This should make it more

What I was personally suggesting would make almost no changes to the
wrapping spec: more a modification than an additional complication. Two
ideas sprang to mind:

Currently we have in the spec:

"5. Generate the number of pad octets necessary to make the
    result a multiple of the key-encryption algorithm block
    size, then append them to the result."

If this is modified to:

"5. Pad the result using standard block padding (as described in
    CMS 6.3) to make the result a multiple of the key-encryption        
    algorithm block size, then append them to the result."

with corresponding decoding the MEK length can be determined
unambiguously. This would apply to all cases: it is needed for RC2 but
it could perform an additional integrity check in other cases.

This might even simplify things because some crypto libraries have
separarate (for example) "XXX" and "XXX with padding" algorithms. Since
the content encryption involves the "XXX with padding" form this would
mean that only "XXX with padding" algorithms would be used throughout.

The other alternative would be to simply have an OPTIONAL MEKlength
INTEGER parameter in CMS which would only be present for variable key
length algorithms whose key length is not specified in the
AlgorithmIdentifier: this probably means just RC2.

Steve.