| > 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 [EMAIL PROTECTED]