Re: Scare tactic?

Peter Gutmann wrote:
> "Nash Foster" <leafgoogle.com> writes:
> 
>> http://labs.musecurity.com/2007/09/1
8/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-pa
rt-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 majordomometzdowd.com

Nate Lawson <nateroot.org> writes:

>All this attack allows is for one side of a DH exchange
to intentionally
>downgrade the security,

You've forgotten Hanlon's razor, "Never attribute to
malice that which can be
adequately explained by stupidity".  So the comment
should really be:

  All this attack allows is for one side of a DH exchange to
inadvertently
  downgrade the security,

This sort of thing has happened several times in the past
(with RSA, not DH in
this case), one example being the CA-issued exponent-one
certs that I
mentioned previously, the other being an implementation that
shall go unnamed
that sent out plaintext because the developers didn't do key
paramter
validation.  So the problem isn't a deliberate attack, it's
screwups by people
implementing or deploying the crypto.

Peter.

------------------------------------------------------------
---------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography"
to majordomometzdowd.com