At 1:42 AM +0200 10/4/07, Henrick Hellström wrote:
Blake Ramsdell wrote:
> The good news is that the test vector caught the ambiguity.
I strongly disagree. The test vectors did absolutely not catch the
The term "test vectors" is incorrect here. That term is not used in
the document. The section in question very clearly is labelled
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.
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.
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.
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