Paul Hoffman wrote:
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.
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.
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.
I agree; my observations don't concern the algorithm itself, but only
the effect the "example" in RFC 3217 might have on implementations of