Scare tactic?

[Nate Lawson]

Peter Gutmann wrote:
> "Nash Foster" <leaf at google.com> writes:
> 
>> http://labs.musecurity.com/2007/09/18/widespread-dh-implementation-weakness/
>>
>> Any actual cryptographers care to comment on this? I don't feel qualified to
>> judge.
> 
> It's quite possible that many implementations do this.  When the Mozilla folks
> changed their code a year or two back to reject RSA keys with an exponent of
> one (which in itself means that they'd been accepting those keys for years), a
> number of certs broke because CAs were issuing exponent-one keys, which in
> turn means that many other implementations that never complained about these
> certs were freely accepting them.  Windows CryptoAPI, for example, still
> allows exponent-one keys as a by-design feature to allow the export of
> "wrapped" keys in plaintext form.  So it's quite believable that a number of
> DH implementations allow bad key parameter values, and that this has been
> going on for years.
> 
> (Even the level of validation discussed on the web page doesn't help entirely,
> FIPS 186 provides extra parameters that you can use for checking the key
> (p,q,g) while the still widely-used PKCS #3 doesn't (p,g), so even just using
> PKCS #3 rather than FIPS 186 is a problem).

I wrote a series of articles on the problem of not verifying padding
with small-exponent RSA.  In the conclusion, it listed a number of
well-known attacks against other public key systems, including small
subgroup confinement.

http://www.matasano.com/log/528/rsa-signature-forgery-explained-with-nate-lawson-part-vi/

The author of the Mu article does not list all the verification steps
needed, and even seems to infer that the values g and p are negotiated
between the two parties.  This would be a bad idea, versus choosing a
set of values that were pre-verified.

This type of attack was even discussed in the realm of IPSEC back in 1997:
http://www.vpnc.org/ietf-ipsec/97.ipsec/msg00629.html

All this attack allows is for one side of a DH exchange to intentionally
downgrade the security, but there's no reason one of them couldn't just
publish the "secure" derived value AFTER completing the entire exchange.
 Or, publish their secret exponent.

If this is not authenticated DH, then you have other problems.

-- 
Nate

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com