Why the exponent 3 error happened:

>  > > > 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.

William

------------------------------------------------------------
---------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe
cryptography" to majordomometzdowd.com

"Whyte, William" <WWhytentru.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 h
ttp://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 majordomometzdowd.com

     --
imon Josefsson wrote:
 > 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.

But why did several people independently implement the
same or similar flaws?

The answer is in Jack Lloyd's post:
 > I wrote a decoder for PKCS#1 v1.5, realized it
 > probably had bugs I wouldn't figure out until too
 > late, [...] my PSS verification code is probably
 > around twice the length of the PSS generation code,
 > due to the need to check every stupid little thing.

     --digsig
          James A. Donald
      6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG
      kcayKvWlPFXTPP9oNsxdS/f7Cu706I0sQMBSZJUj
      4578L9TLcVLPN7c++p1/Un4LFV6ugOy6Pb/SpWw2u




------------------------------------------------------------
---------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe
cryptography" to majordomometzdowd.com