>  > If so, I fear we are learning the wrong lesson, which
>  > while valid in other contexts is not pertinent here.
>  > TLS must be flexible enough to accommodate new
>  > algorithms, this means that the data structures being
>  > exchanged are malleable, and that implementations must
>  > validate strict adherence to a specifically defined
>  > form for the agreed algorithm, but the ability to
>  > express other forms cannot be designed out.
> There is no need, ever, for the RSA signature to encrypt
> anything other than a hash, nor will their ever be such
> a need.  In this case the use of ASN.1 serves absolutely
> no purpose whatsoever, other than to create complexity,
> bugs, and opportunities for attack.  It is sheer
> pointless stupidity, complexity for the sake of
> complexity, an indication that the standards process is
> broken.

I think this is a bit unfair.

PKCS#1 signatures were originally designed to include a hash 
identifier to address a specific concern, arising from the
fact that RSA signers can freely choose the hash algorithm
to use.

Say that Alice uses SHA-1 to generate her signature on m,
and SHA-1(m) = h.

Then the concern is that Bob can find a broken hash function
BASH such that BASH(m') = h. If he can do that and format a
message that claims to be signed with RSA and BASH, then he
can present Alice's signature as a valid signature on m'.

There are a number of different protections against this.
For example, Alice's cert could identify her key as only 
to be used with SHA-1 (this is effectively what happens with
DSA public keys). However, the convention has been to mark an
RSA key in an X.509 cert as rsaEncryption and not specify
in the AlgorithmIdentifier that it's only to be used with a
certain hash function (or signature scheme).

So PKCS#1 incorporated the hash identifier, which prevents
a signature generated with one hash algorithm from being
used with a different hash algorithm. (Since then, Burt
Kaliski's done some research on the use of hash "firewalls"
of this type: see
His conclusion is that by and large they aren't necessary,
but that isn't relevant to the discussion here).

At the time, ASN.1 was in widespread use, so it was an 
obvious decision (rather than pointless stupidity) to use 
it to encode the hash function identifier. In practice, 
the ASN.1 doesn't introduce complexity because most implementations 
(certainly ones I've worked on) simply treated it as a memcmp 
rather than wheeling out the heavy ASN.1 machinery.

The real problem isn't ASN.1; the problem is that an
encoding method was used for the rest of the signature
that didn't specify the length of the signature block
and it didn't occur to anyone to check it.



The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Reply via email to