Why the exponent 3 error happened:

[Simon Josefsson]

"Whyte, William" <WWhyte at ntru.com> writes:

>>  > > > This is incorrect. The simple form of the attack
>>  > > > is exactly as described above - implementations
>>  > > > ignore extraneous data after the hash. This
>>  > > > extraneous data is _not_ part of the ASN.1 data.
>> 
>> James A. Donald wrote:
>>  > > But it is only extraneous because ASN.1 *says* it is
>>  > > extraneous.
>
> No. It's not the ASN.1 that says it's extraneous, it's the
> PKCS#1 standard. The problem is that the PKCS#1 standard
> didn't require that the implementation check for the
> correct number of ff bytes that precede the BER-encoded
> hash. The attack would still be possible if the hash
> wasn't preceded by the BER-encoded header.

That's not true -- PKCS#1 implicitly require that check.  PKCS#1 says
the verification algorithm should generating a new signature and then
compare them.  See RFC 3447 section 8.2.2.  That solves the problem.

Again, there is no problem in ASN.1 or PKCS#1 that is being exploited
here, only an implementation flaw, even if it is an interesting one.

After reading http://www.rsasecurity.com/rsalabs/node.asp?id=2020 it
occurred to me that section 4.2 of it describes a somewhat related
problem, where the hash OID is modified instead.  That attack require
changes in specifications and implementations, to have the
implementation support the new hash OID.  But it suggests a potential
new problem too: if implementation don't verify that the parsed hash
OID length is correct.  E.g., an implementation that uses

memcmp (parsed-hash-oid, sha1-hash-oid,
         MIN (length (parsed-hash-oid), length (sha1-hash-oid)))

to recognize the hash algorithm used in the ASN.1 structure, it may
also be vulnerable: the parsed-hash-oid may contain "garbage", that
can be used to "forge" signatures against broken implementations,
similar to the two attacks discussed so far.  I don't know of any
implementations that do this, though.

/Simon

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com