[Top] [All Lists]

Re: S/MIME v3.2 IDs key size text

2008-03-31 05:45:30

Peter Gutmann wrote:
Blake Ramsdell <blake(_at_)sendmail(_dot_)com> writes:

Unfortunately, this opens up a new can of worms for the security
considerations -- how do you specify the right combination of exponent and
modulus values for RSA that are a problem? Are there a similar set of giant
parameters that might be used with DSA?

I know that someone else on this list has looked at DoS-enabling parameters in
the past so maybe they'll want to comment, I've looked at this too and (for
example) feeding a DLP-based key exchange that expects g = 2 a value of g
that's something much, much larger than 2 (like 2^256 times larger), or an RSA
key where e is a bignum, can lead to disappointing effects at the other end.
(that is, you can trivially knock a server off the net with this... apologies
if I tried this on your server :-).  Taking out an S/MIME gateway shouldn't be
much more difficult.

The study was a small and didn't look in a huge amount of detail but the results agree with the above paragraph pretty well.

16K keys with 16K e can lock up modern systems (or what counted for modern systems a when I checked a couple of years back) for several minutes and 8K keys with 8K e tens of seconds. So embedding large numbers of requests with such keys could easily cause problems.

Some implementations (by accident or design) restrict e to 32 bits in size.

A separate issue was where such verification of keys might take place.

If a CA issues a trusted EE certificate with such a key then an implementation will check the signature if it doesn't reject large parameters. But it would be a less useful attack since the certificate should reveal some details of the attacker's identity.

In practice an attempt might be made using untrusted certificates.

The signature using the EE certificate key may be checked either before the certificate chain is validated or performed even if the chain validation fails as useful debugging information.

A separate attack could be performed during chain validation itself. This depends on the order certificate signatures are checked.

Consider a forged chain from trust anchor TA to end entity certificate EE...


Where the signature of CA1 is bogus but all others are valid. An implementation might check signatures from TA to EE and reject the chain on the first invalid signature.

If an implementation checks from EE to TA it will only reject the chain after checking several CA signatures along the way. If the bogus CAn certificates have such keys this could itself be a DoS attack.

Alternatively it might check all signature for debugging purposes even after a failure.

Dr Stephen N. Henson.
Core developer of the   OpenSSL project:
Freelance consultant see:
Email: shenson(_at_)drh-consultancy(_dot_)co(_dot_)uk, PGP key: via homepage.

<Prev in Thread] Current Thread [Next in Thread>