On Tue, 14 Sep 2010 16:56:50 +0000 "brian m. carlson" <sand...@crustytoothpaste.net> wrote: > On Tue, Sep 14, 2010 at 09:59:16AM +0200, Marco d'Itri wrote: > > On Sep 14, Gunnar Wolf <gw...@debian.org> wrote: > > > > > pushing Debian towards adopting stronger RSA keys - We have > > > accepted some 2048R keys, but if you don't have a real reason > > > to keep your key at that size (i.e. you very often build on > > > underpowered machines where a 4096R key takes forever, or > > > something like that), we really prefer to go with 4096R keys. > > I would like to know the process which lead to selecting these > > figures. > > I suspect that those figures are because 2048 bits is the default > size for RSA keys and 4096 bits is the largest size that GnuPG > supports. Some specially patched versions of PGP can support keys > of up to 16384 bits, but IIRC those are all v3 RSA keys, which > aren't allowed anymore. > > Personally, I can't see a reason that using an RSA 4096 bit key > should be that painful even on very slow machines. You're > performing a *single RSA encrypt operation* per signature.
The selected key length seems unreasonably long to most people who have been discussing this on the cryptography mailing list I run. In fairness, some call it harmless, but no one has defended it as appropriate. I will remind everyone that RSA key lengths do not provide linear increases in security -- a 2N length is not twice as hard to brute force as an N length, but rather many orders of magnitude harder. A 2N key is also much slower to use than a key of length N, and although this might seem like a small cost, it is not completely ignorable. It is also harder to generate twice as many random bits reliably, the hash functions used to defend the signed material may no longer be of appropriate strength, etc. It is telling that the DNSSEC trust anchor only uses a 2048 bit key, and is far better defended than the keys Debian is using and arguably a far more valuable key to steal. Generally speaking, selecting a key length requires a threat model. One must ask how people are likely to attack the security system the keys are defending. The keys are being stored on people's personal computers or on media in their homes without armed guards, safes, tamper-resistant signing hardware, etc. There are very large numbers of these keys. The keys are being used to sign software that comes from upstreams with a variety of security policies, many of which are fairly poor. The weak point is thus clearly not the keys. Given that factoring even a 1024 bit number is difficult (and a 1200 or so bit number is probably beyond the financial capabilities of any organization I can name, including major governments) no one is going to be attacking the system by factoring. For a fraction of the cost of doing detailed engineering studies to factor a 2048 bit key (not even the actual factoring) I can conduct targeted hacking attacks, have someone spend a few months gaining the confidence of an upstream project so they can insert a subtle bug into their code, hire a small army of skilled burglars to break in to the physical locations where keys are stored or even conduct a supply chain attack or dozens of other things. 4096 goes far beyond 2048. I'm reminded of a rumored conversation that happened after Biham discovered attacks on the NSA's Skipjack algorithm that limited its security to around 80 bits. It was very noticeable that the designers of the algorithm had picked an 80 bit key length as well. Reportedly, this was described by someone in the know as an example of proper engineering rather than as a coincidence. The professionals don't reinforce a cardboard bridge with steel trusses. Rather than recommend an increase to a key size that many will find inconvenient, I would suggest worrying more about the process that assures that what is being signed is in fact safe, and that keys are not being misused. Several attacks against Windows recently have involved stolen keys (note, stolen, not cracked) and I doubt Debian's average key is better defended. Attackers look for weak points in systems -- defenders must do the same. Perry -- Perry E. Metzger pe...@piermont.com -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100915103530.439a2...@jabberwock.cb.piermont.com
