Exponent 3 damage spreads...

[Leichter, Jerry]

| > Granted, one or more implementations got this wrong.  (Has anyone
| > looked to see if all the incorrect code all descends from a common
| > root, way back when?)
| 
| We have at least three independent widely used implementations that
| got things wrong: OpenSSL, Mozilla NSS, and GnuTLS.
| 
| However, note that this isn't a single problem; we are talking about
| at least two related problems.  Some implementations are vulnerable to
| only one of them.
| 
| The first problem was ignoring data _after_ the ASN.1 blob.
| Vulnerable: OpenSSL, NSS?
| 
| The second problem was ignoring data _in_ the ASN.1 blob, in
| particular, in the parameters field.  Vulnerable: OpenSSL, GnuTLS,
| NSS?
| 
| A several year old paper by Kaliski discussed using the ASN.1 OID to
| store data in.  It has slightly different properties, but the lesson
| in this context is that implementations must properly check the ASN.1
| OID field too.
| 
| > Until we know whether this is *one* mistake that was copied from
| > implementation to implementation, or the same mistake made by
| > multiple developers, it's really premature to draw any conclusions.
| 
| I hope that I convinced you that this isn't an open question.
I agree that there are two issues, and they need to be treated
properly.  The first - including data after the ASN.1 blob in the
signature computation but then ignoring it in determining the
semantics - is, I'll argue, an implementation error.  You list only
OpenSSL as definitely vulnerable, NSS as "?", so it sounds like
only one definitive example.  Even if NSS has the same problem, one
has to look at code provenance.  OSS efforts regularly share code,
and code to pick apart data fields is hardly kind of thing that
is going to inspire someone to go out and "do it better" - just
share.

The second - embedded parameter fields - is a much deeper issue.
That's a protocol and cryptographic error.  The implementations
appear to be correctly implementing the semantics implied by the
spec - ignore parameters you don't care about.  This is common
practice, and a fine idea in *most* situations, since it allows
for extensions without breaking existing implementations.  As
we've seen, it's a really bad idea for signed fields with small
exponent, since they have an unexpected malleability.  The
advice to avoid small exponents is fine, but in fact I think this
is a special case of another principle:  Don't act as a signing
oracle.  That was known to be a bad idea quite some time ago,
and it's one reason we sign cryptographic hashes, not raw data.
The curiosity of this bit of misdesign is that it hashes the raw
data, but then, on the way to signing it, turns the field back
into (mainly) raw data!
							-- Jerry


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