Subject: Re: Fwd from sci.crypt: Error in RFC 3217

From: Russ Housley <[email-masked]>
Date: Tue, 02 Oct 2007 16:37:48 -0400

I asked a developer to take a look, and they are unable to figure out 
what the problem.  More information is needed to confirm.

Russ

At 11:21 PM 9/25/2007, Peter Gutmann wrote:

>-- Snip --
>
>From:  [email-masked]
>Newsgroups: sci.crypt
>Subject: Error in RFC 3217
>Date: Wed, 01 Aug 2007 11:54:13 -0700
>
>There is an error in the test vectors for RC2 Key Wrap given in RFC
>3217. The specification states that RC2 should be used with a 128 bit
>key and 128 effective key bits. The test vectors are however generated
>using RC2 with a 128 bit key but only 40 effective key bits (which BTW
>was the default for MS CryptoAPI prior to Windows XP).
>
>I don't know if R. Housley is reading these groups, but clearly this
>is an error that should be corrected.
>
>The algorithms specified in RFC 3217 are primarily used for S/MIME. If
>you have ever used S/MIME for encrypting email using a certificate
>with a DH public key and the RC2-CBC encryption algorithm, chances are
>you only got 40 bits of security even if you opted for 128 bit
>encryption.

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 2 Oct 2007 15:49:02 -0700

[[ Never hurts to ask the original poster ... ]]

At 4:37 PM -0400 10/2/07, Russ Housley wrote:
>I asked a developer to take a look, and they are unable to figure 
>out what the problem.  More information is needed to confirm.
>
>Russ
>

---

From: Henrick Hellström <[email-masked]>
Date: Wed, 03 Oct 2007 10:46:01 +0200

Hi,

The problem has two sides.

Firstly, RFC 3217 doesn't explicitly say that the test vectors are
generated using 40 effective key bits. Without that information the test
vectors are not unequivocally specified. You need that piece of
information in order to reproduce the values.

Secondly, RFC 3217 is now part of S/MIME Charter. This charter also
includes RFC 3370 (CMS algorithms) which refers to RFC 3217, but states
that RC2 Key Wrap keys MUST be used with 128 effective key bits
(parameter value 58).

This is a potentially serious documentation bug. Say, for instance, that
you are programming against MS CryptoAPI in Windows 2000 or earlier,
which had 40 effective key bits as the default for RC2. In such case the
test vectors in RFC 3217 *will* check out OK with default settings, and
you might be mislead to believe you have implemented RFC 3370 correctly
even though you haven't. If the test vectors in RFC 3217 had been
generated using 128 effective key bits, or if RFC 3217 had explicitly
specified the use of 40 effective key bits, such errors would be a lot
more easy to spot during testing and code review.

Hope that makes my case clear.

P.S. Why doesn't *this* list accept S/MIME signed email? ;) D.S.

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 3 Oct 2007 10:37:33 -0700

>information in order to reproduce the values.

After reading and re-reading, I do not see how you can say that the 
test vectors are generated using 40 effective key bits. Where does 
that show up in the RFC?

---

From: Henrick Hellström <[email-masked]>
Date: Wed, 03 Oct 2007 20:43:16 +0200

> test vectors are generated using 40 effective key bits. Where does 

It *doesn't* say that in the RFC, which is *exactly* what I am
complaining about.

I discovered it myself by trial-and-error, and to be honest, it took me
a couple of days, because there were a lot of other variables I checked
first (such as endianess etc)

---

From: Blake Ramsdell <[email-masked]>
Date: Wed, 3 Oct 2007 16:15:53 -0700

> information in order to reproduce the values.

This observation is correct, based on my own testing here. In order to get the
example in section 4.4 of RFC 3217 to work correctly, you need to use an
effective key length parameter of 40 bits. The effective key length parameter
is not discussed, and it is an important input to the RC2 algorithm.

> that RC2 Key Wrap keys MUST be used with 128 effective key bits

I do not see this -- I see that the input key length must be 128 bits, but
there is no indication about any particular value for the effective key
length. The language I see in RFC 3370, section 4.1:

<snip>
For key agreement of RC2 key-encryption keys, 128 bits MUST be
generated as input to the key expansion process used to compute the
RC2 effective key [RC2].
</snip>

This language appears to be compatible with the language in RFC 3217. If you
have another concern in mind, let me know.

> more easy to spot during testing and code review.

I'm not sure, but I'd say "be careful of default parameters". Like I'm not
sure what the default IV is also, for instance.

The good news is that the test vector caught the ambiguity.

Blake
-- 
Blake Ramsdell | Sendmail, Inc. | http://www.sendmail.com

---

From: Henrick Hellström <[email-masked]>
Date: Thu, 04 Oct 2007 01:42:04 +0200

> is not discussed, and it is an important input to the RC2 algorithm.
Thanks for confirming this.

> have another concern in mind, let me know.
Wrong section. You should be looking at RFC 3370, section 4.3.2:

<snip>
 RC2 128-bit keys MUST be used as key-encryption keys, and they MUST be 
used with the RC2ParameterVersion parameter set to 58.
</snip>

The RC2ParameterVersion parameter value of 58 is the encoding of 128 
Effective Key Bits. Hence, this is mandatory.

> The good news is that the test vector caught the ambiguity.
I strongly disagree. The test vectors did absolutely not catch the 
ambiguity. The test vectors increased the ambiguity because they didn't 
say that they would only work with implementations that used 40 
effective key bits by default. In fact, the only ones who have 
successfully implemented RC Key Wrap so far are likely to be developers 
who were programming against older versions of MS CryptoAPI and were 
blissfully oblivious about the EKBParameter of RC2.

Programmers like me and a bunch of others who were aware of all details 
of the RC2 algorithm, as well as the necessity of testing 
implementations against test vectors and reading RFCs to the letter, 
have not caught the ambiguity but simply left the RC2 Key Wrap algorithm 
unimplemented. You can't find it in our library. You can't find it in 
Crypto++. You can't find it in OpenSSL. You can however find it in some 
libraries that link to the MS CryptoAPI.

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 3 Oct 2007 17:51:07 -0700

At 1:42 AM +0200 10/4/07, Henrick Hellström wrote:
>ambiguity.

The term "test vectors" is incorrect here. That term is not used in 
the document. The section in question very clearly is labelled 
"example".

>The test vectors increased the ambiguity because they didn't

It is likely that some made this mistake, sure, but it is also likely 
that others figured it out by hand. None of us know what the 
percentage on each side is, so "are likely" seems to be a stretch.

>libraries that link to the MS CryptoAPI.

The problem you have found is not a weakness in the RC2 key wrap 
algorithm: it is (likely) a mistake by the person who generated the 
example, and (likely) the person who tested them.

This is worthy of an errata to RFC 3217 warning RC2 implementers 
about the problem, pointing to this example as how easy it is to miss 
it.

---

From: Henrick Hellström <[email-masked]>
Date: Thu, 04 Oct 2007 07:54:29 +0200

> percentage on each side is, so "are likely" seems to be a stretch.
Perhaps, and yes you are right it was an intentional hyperbole, but I 
have actually made an effort to download a number of open source 
implementations of S/MIME, as everyone else here can. Not even Mozilla 
implements RC2 Key Wrap. It isn't *completely* unreasonable to assume 
that the absence of well specified test vectors have made a number of 
independent implementors skip or postpone this feature, as well as made 
a number of other implementors simply use MS CryptoAPI for RC2 without 
setting the EKBParameter. I found examples of both.

> This is worthy of an errata to RFC 3217 warning RC2 implementers about 
> the problem, pointing to this example as how easy it is to miss it. 
I agree; my observations don't concern the algorithm itself, but only 
the effect the "example" in RFC 3217 might have on implementations of 
the algorithm.

---

From: Blake Ramsdell <[email-masked]>
Date: Mon, 15 Oct 2007 20:07:21 -0700

> the effect the "example" in RFC 3217 might have on implementations of 

I propose the following errata to RFC 3217:

Current first paragraph of section 4.4:

This section contains a RC2 Key Wrap example. Intermediate values
corresponding to the named items in section 4.1 are given in hexadecimal.

New:

This section contains a RC2 Key Wrap example. Intermediate values
corresponding to the named items in section 4.1 are given in hexadecimal. In
this example, the effective key length parameter for the RC2 algorithm should
be 40 bits.

Blake

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 16 Oct 2007 07:17:23 -0700

>this example, the effective key length parameter for the RC2 algorithm should

It is not "should be", it is "is".