[EMAIL PROTECTED] (Peter Gutmann) writes:

> Simon Josefsson <[EMAIL PROTECTED]> writes:
>>The second problem is that the "parameters" field can ALSO be used to store
>>data that may be used to manipulate the signature value into being a cube.
>>To my knowledge, this was discovered by Yutaka Oiwa, Kazukuni Kobara, Hajime
>>Watanabe.  I didn't attend Crypto 06, but as far as I understand from Hal's
>>post, this aspect was not discussed. Their analysis isn't public yet, as far
>>as I know.
> Can you make a guess at what it is?  Is it the fact that you can have NULL
> parameters for algorithms or optionally non-NULL parameters?

Yes.  Implementations that didn't validate the parameters field are
potentially vulnerable; the attacker can put garbage in the parameters
field to make the signature value a cube.  Look at the certificates I

> Changing this could be tricky because there are all sorts of
> inconsistencies both in standards and implementations, the standard
> practice has been to skip the parameters field because if you don't,
> things break.

I don't think so.  The contents of the parameters field depends on the
hash algorithm.  As far as I know (but I didn't read the scriptures),
for normal hashes like SHA-1 the parameters field should not be used.
Checking that it is empty shouldn't be a problem.

Or do you know of real certificates with a non-NULL parameters field
in the signature?

It is important to keep in mind that this only applies to incorrect
implementations that handle keys with e=3.  Using Debian's
/etc/ssl/certs/ CA list, which on my system contains around 100 CAs, I
extracted the issuer name of the CAs with e=3:

Issuer: C=US,O=Digital Signature Trust Co.,OU=DSTCA E1
Issuer: C=US,O=Digital Signature Trust Co.,OU=DSTCA E2
Issuer: C=US,O=Entrust.net,OU=www.entrust.net/Client_CA_Info/CPS incorp. by 
ref. limits liab.,OU=(c) 1999 Entrust.net Limited,CN=Entrust.net Client 
Certification Authority
Issuer: C=US,O=Entrust.net,OU=www.entrust.net/CPS incorp. by ref. (limits 
liab.),OU=(c) 1999 Entrust.net Limited,CN=Entrust.net Secure Server 
Certification Authority

I'm not familiar with DST, so I wonder whether those two are widely
used.  https://secure.digsigtrust.com/ doesn't use it.

That leaves two Entrust certificates.  At least
https://www.entrust.com/ is protected by the second certificate above,
so it may be in wide use.


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

Reply via email to