encryption algorithm

[Daniel Kahn Gillmor]

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


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1027 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20131217/4dabf3c9/attachment.sig>