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...
TA->CA1->CA2->CA3....->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.
Steve.
--
Dr Stephen N. Henson.
Core developer of the OpenSSL project: http://www.openssl.org/
Freelance consultant see: http://www.drh-consultancy.co.uk/
Email: shenson(_at_)drh-consultancy(_dot_)co(_dot_)uk, PGP key: via homepage.