ietf-smime
[Top] [All Lists]

RE: Key size security considerations

2008-08-20 06:57:57
Given what we know about the state of factoring algorithms I think that we 
could state that if your security needs demand higher security than you get 
from 2048 bit RSA you should consider a different algorithm and certainly at 
4096.
 
 

________________________________

From: owner-ietf-smime(_at_)mail(_dot_)imc(_dot_)org on behalf of Paul Hoffman
Sent: Sat 8/9/2008 9:15 PM
To: ietf-smime(_at_)imc(_dot_)org
Subject: Key size security considerations




Earlier, I proposed  a replacement for part of the security
considerations in 3851bis (S/MIME message). The current text reads:

    Larger keys are not necessarily better keys.  Larger keys take more
    computational resources, and this can quickly become impractical.  In
    fact, support for an excessively large key offers a denial of service
    opportunity if the attacker can cause excessive cryptographic
    processing by providing such a public key.  One mitigation approach
    would require that the corresponding public key certificate be
    validated to a trust anchor prior to use, thus ensuring that only
    trusted public keys are used.  However, some implementations may
    choose to perform signature verification (or key establishment for
    encryption) in parallel with certificate validation, even if
    certificate validation fails.  In such cases, measures should be
    included to limit the impact, for example by limiting cryptographic
    processing time or requiring certificate validation prior to the use
    of large keys.

There is no parallel text in 3850bis.

There has been some good discussion, and I now propose different,
more general wording that should be included in both documents. This
would replace the above paragraph in 3851bis and be added to 3850bis.

Sending and receiving agents need to be cautious of CPU usage and
other resources when handling public keys larger than those mandated
in this specification (that is, larger than 2048 bits). For example,
an attacker can send very large, bogus signatures in order to swamp
the CPU of the receiving party. Another example is that an attacker
can try to cause a sender to try to encrypt with a very large key.
One mitigation approach would require that the corresponding public
key certificate be validated to a trust anchor prior to use, thus
ensuring that only trusted public keys are used.  However, some
implementations may choose to perform signature verification (or key
establishment for encryption) in parallel with certificate
validation, even if certificate validation fails. Sending and
receiving parties are advised to have some sort of resource
management system to prevent such attacks.



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