Why the exponent 3 error happened: The signature consists of a number that when cubed, is equal modulo N to the padded hash of the quantity to be signed.
Part of the padding is the ASN.1 encoding of the hash. Now suppose we had not ASN.1 encoded the hash. Suppose the padding was simply 010101010101010 ... 10101010101010000 hash with all leading zeros in the hash omitted, and four zero bits showing where the actual hash begins. Then the error would never have been possible. ASN.1 provided additional redundant information, making possible unexpected data layouts that should not normally happen. It had too much expressive power, too much flexibility. It could express cases that one does not expect to deal with, could flex in more ways than one's software is likely to be written for. XML has even greater redundancy and flexibility, but has the advantage that one can constrain it with a DTD that guarantees that it will have the form, and only the form, that one's software expects. Still, usually the simplest way of dealing with data that may be hostile and malicious is to use a data format that is entirely free from redundancy, thus can *only* have the expected form. If there is no redundancy in ones data, then one never has to deal with cases where the data is inconsistent. One is not always able to eliminate all redundancy, but one always has to check that the data is of the expected form, and the fewer forms it can has the easier that is. ASN.1's crowning virtue is its flexibility, and we do not want flexibility in possibly hostile data. --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
