-- David Wagner wrote: > It seems to me that e=3 is a distraction. I think > that these security holes have revealed some more > fundamental issues here that are independent of the > value of e you use. > > It seems to me that the problems can be attributed to > two problems: (a) implementation bugs (failures to > implement the spec faithfully); and (b) ad hoc > signatures schemes that have never been adequately > validated. In more detail: > > (a) Any implementation that doesn't check whether > there is extra junk left over after the hash digest > isn't implementing the PKCS#1.5 standard correctly. > That's a bug in the implementation. Of course, as > we know, if you use buggy implementations that fail > to implement the specification faithfully, all bets > are off > > (b) The discussion of "parameter fields" in PKCS#1.5 > signatures illustrates a second, orthogonal problem. > If your implementation supports appending additional > parameter fields of some general structure, then you > have not implemented conventional PKCS#1.5 > signatures as they are usually understood; instead, > you have implemented some extension. That raises a > natural question: Why should we think that the > extended scheme is still secure?
When a protocol is successful, pretty soon it comes in a large number of variants, all of which have to coexist - the original version, several upgraded versions, different interpretations of the spec, buggy interpretations of the spec and Microsoft style "embrace and extend" interpretations of the spec designed to deliberately hamstring interoperability. Therefore one generally makes provisions for future expansion - for additional fields in a record, additional types of records. ASN.1, S-expressions, and XML permit essentially limitless future fields. That is dangerously great flexibility. On the other hand, TCP format turned out to permit too little flexibility. GPG's concept of "records" seems to me are reasonable way of providing future expansion, without requiring the programmer to handle potentially limitless future expansion of every possible bit of organized data, a task at which the programmer is likely to fail. In general, a communication should tell what program and version the communication is coming from, so that future programs can say "oh, I am talking to someone old fashioned, so must talk in the old fashioned dialect." (Though for conciseness, this probably should not be in human readable form, but in some cryptic set of bytes that are agreed to stand for some particular program.) It should also be able to specify that it is like some other program, some program that became a de facto standard that everyone has to be able to interoperate with, saying "If you don't recognize me, assume I am this other program, and it will work well enough". The communication should also identify that it is in accord with some particular standards document (again, probably with a cryptic set of bytes rather than a verbose url), so that the recipient knows that this communication version 1.0 format, or version 1.1, or the emergency fixed version of version 1.1, though if the standards document was good enough, which it seldom is, it would not be necessary for the program to identify itself, or to reference particular concrete implementations. But still, we likely need programs that only understand 1.0 format to have some success when they receive 1.1 format, and this is where the expandability of ASN.1 and the rest is useful - and dangerous. I would suggest that communication occurs in records that correspond to database records and to C++ objects, and that some records be defined with provision for future expansion, and other records not so defined, according to the judgment of the people defining the original protocol. With ASN.1, XML, and S-expressions, *everything* has provision for future expansion, which I suggest is dangerously excessive. If the 1.0 protocol contains an error, they find that the 1.1 protocol needs some more fields in the record, and no provision has been made for future expansion, then they either define a new type of record replacing the old, (thereby guaranteeing that 1.0 programs will fail to interoperate when this new record is used) or define an additional record supplementing the old, which the 1.0 programs will ignore, handling only the records they recognize. Coming back to the case at hand, we should have had a signature record that only allowed a one particular kind of hash, and nothing but the hash, and no future expansion, then when people realized that was a problem, that unforeseen new hashes would need to be introduced over time, they should have then introduced an incompatible signature record that defined the hash type, and the hash, and allowed for no future expansion. --digsig James A. Donald 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG /zedskWwjM7YJCe3zo2C7y0GDwUQjP+BN9ayEeww 4Y0kilizvKF0KpOu7fT86djxwW1ghxrvqfCKm1sKc --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]