2048 or 4096 for new keys? aka defaults vs. Debian
wk at gnupg.org
Sat Oct 26 14:13:15 CEST 2013
On Sat, 26 Oct 2013 11:35, beuc at beuc.net said:
> Plus, following this principle, why doesn't gnupg default to 4096 if
> there isn't any reason not to? I would suppose that if gnupg defaults
4k primary RSA keys increase the size of the signatures and thus make
the keyrings longer and, worse, computing the web of trust takes much
longer. Yeah, not on your high end desktop machine but on old laptops
and my N900 phone. It also drains the battery faster.
There is no benefit of overly large keys on average computers. After
all the goal is not to have large key but to protect something. Now, if
you want to protect something you need to think like the attacker - what
will an attacker do to get the plaintext (or fake a signature)? Spend
millions on breaking a few 2k keys (assuming this is at all possible
within the next decade) or buy/develop/use a zero-day?
Instead of discussing these numbers the time could be much better use to
audit the used software (firmware, OS, libs, apps).
I would even consider bugs like below more serious than protecting
against break 2k RSA.
Author: Werner Koch <wk at gnupg.org>
Date: Sat Sep 7 10:06:46 2013 +0200
Fix bug in _gcry_mpi_tdiv_q_2exp.
* mpi/mpi-internal.h (MPN_COPY_INCR): Make it work.
This bug has been with us since the version 0.0.0 of GnuPG.
Fortunately it only affects an optimized code path which is rarely
used in practice: If the shift size matches the size of a
limb (i.e.. 32 or 64); this is is_prime in primegen.c. Over there the
Rabin-Miller test may fail with a probability of 2^-31 (that is if the
to be tested prime - 1 has the low 32 bits cleared). In practice the
probability is even much less because we first do a Fermat test on the
randomly generated candidates which sorts out the majority of
The bug in MPN_COPY_INCR was found by Sven Bjorn.
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.
More information about the Gnupg-users