On 12/17/2013 01:22 PM, Robert J. Hansen wrote: > With respect to 2048-bit crypto, don't believe the hype. Most users and > most purposes will still be well-served with even a 1024-bit key. No > one with half a brain is going to bother trying to break RSA-1024; they > will instead come up with more effective ways of recovering your message.
Sure, and so-called export ciphers for TLS are probably effective against the overwhelming majority of attackers too. But we recommend people disable export ciphers and prefer stronger algorithms, because the goal of cryptographic tools is to help as many people as possible, even when attacks are rare. so strong algorithms by default is a good idea. > But there are some people and some users who have a true need for > long-term security in their messages. The current recommendations of > NIST, ENISA, RSADSI and others is that RSA-2048 will be safe for the > next thirty years. I'm not sure how you get this claim from these reports, but that's not what it looks like to me. For example, ECRYPT 2012's report sees 2432-bit RSA as equivalent of 112 bit symmetric cipher, which it claims is acceptable for ≈20 years. Please see section 7.2: http://www.ecrypt.eu.org/documents/D.SPA.20.pdf For ≈30-year protection, the ECRYPT authors recommend the equivalent of 128-bit symmetric ciphers, which they say corresponds to 3248 bit RSA (see the table on page 30). So according to ECRYPT's recommendations from two years ago, the current GnuPG default RSA key size is above the "legacy standard level" (≈10 years) but below "Medium Term protectsion" (≈ 20 years). > Further, 2048-bit keys are small > enough that they may be used in smart cards, mobile devices and embedded > markets. If you are generating a key whose private key will be stored on a smart card, you should clearly generate a key that will fit your smartcard. The smartcard does secret key work (decryption, signing). None of the public key operations (signature verification, encryption) will be done on the smartcard, so smartcard constraints need not be a concern there. So users of constrained devices can choose their own tradeoffs for secret-key operations (decryption, signing). What about public-key operations? For signature verification, an implementation on a constrained device that interacts with a human could simply defer signature validation until a human decides the tradeoff of verifying the signature is worth the computation cost. For encryption, users would need to be made aware of the costs of any additional message recipient. So I don't think constrained devices are a good argument for weaker default keys, though clearly the smartcard case is a good argument for gpg still being able to create and handle those keys. > But don't believe people who preach doom and gloom if you use RSA-1024. > Although it's not sufficient for long-term security, it's plenty > sufficient to dissuade anyone who doesn't have the resources of a First > World government behind them. According to ECRYPT 2012 (same report referenced above), RSA 1024 falls in at the equivalent of about 73 bits of symmetric cipher. According to the authors, this is "Short-term protection against medium organizations, medium-term protection against small organizations", not "a First World government". While i don't agree with adrelanos' entire draft, i do agree that the default key size for gpg should be larger. A default key size of 3072 or 4096 bits for RSA keys sounds reasonable to me. I also think that the default certificate digest algorithm should be SHA-256 instead of SHA-1 (see section 10.2 of the ECRYPT document above for reasons why we should deprecate the issuance of signatures over SHA-1). Users stuck with OpenPGP implementations unable to process SHA-256 that also rely critically on the network of identity certifications known as the "web of trust" (do such users actually exist? That intersection seems likely to be vanishingly small) may need to upgrade. Users who can't process SHA-256 certifications but willing to manually indicate which keys are valid manually/locally (or who manage a "trusted" keyring) should still be able to carry on as before. We do not do the users of GnuPG any favors by continuing to generate weaker-than-expected keys and certifications by default. Regards, --dkg
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
