[44166] in cryptography@c2.net mail archive
Re: Why the exponent 3 error happened:
daemon@ATHENA.MIT.EDU (Simon Josefsson)
Mon Sep 18 07:31:48 2006
X-Original-To: cryptography@metzdowd.com
X-Original-To: cryptography@metzdowd.com
From: Simon Josefsson <jas@extundo.com>
To: "Whyte, William" <WWhyte@ntru.com>
Cc: "James A. Donald" <jamesd@echeque.com>,
"Ben Laurie" <ben@algroup.co.uk>,
"Cryptography" <cryptography@metzdowd.com>
Date: Mon, 18 Sep 2006 10:39:14 +0200
In-Reply-To: <9DC3EBEFB87A97498A7D25F130DE27E4983EE3@ohthree.jjj-i.com>
(William Whyte's message of "Sat\, 16 Sep 2006 18\:43\:10 -0400")
"Whyte, William" <WWhyte@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@metzdowd.com
