Why the exponent 3 error happened:

[James A. Donald]

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 majordomo at metzdowd.com