Bug#476441: Please revist this choice. AES128 vs AES256 (for gnutls)

[Daniel Kahn Gillmor]

[re: GnuTLS default ciphers]

On 03/21/2014 06:15 AM, Robert de Bath wrote:
> I notice that the distribution of RSA key sizes distributed with Debian
> has changed.
> 
> The 2048 bit keys are still the most common but 20% of the keys are now
> 4096 bit with only 12% still being 1024 bit. (The 4k and 1k keys have
> basically changed places)

which keys are you talking about here?  where are these numbers from?

> Based on the (now rather dated IMO) papers you cite the 4k keysize exceeds
> the strength of AES-128 by a large margin.

Here is a modern report from ENISA, which includes a survey of a bunch
of other literature:

http://www.enisa.europa.eu/activities/identity-and-trust/library/deliverables/algorithms-key-sizes-and-parameters-report

in this report, AES-128 is considered roughly equivalent to RSA-3Kbit;
to be equivalent to AES-256, an RSA key would need to be ~15Kbit.
4Kbit RSA is not a "large margin" more than AES-128 by these metrics.

The report also notes that AES-256 is 40% slower than AES-128, which has
real operational consequences (battery drain on mobile devices, extra
load on busy servers, etc).

GnuTLS provides a priority string option to allow users of applications
to specify their cipher preferences; if you are willing to pay the cost
of the stronger cipher despite the weaker keys, you should be able to
indicate that in a priority string, e.g. with SECURE256:+NORMAL  (omit
the :+NORMAL if you are unwilling to communicate with any server that
does not make AES-256 available)

> As the RSA key is usually the
> "headline" strength indicator for the algorithms other keysizes IMO should
> equal or exceed this value; AES-128 appears not to for 4k RSA keys.

I agree that it's slightly below, but i think it's in the same ballpark
-- if we're balancing crypto, it's roughly balanced.  If anything, i'd
argue that the default RSA key generation size (2432-bit RSA, which is
~112-bit equivalent) should be raised to match AES-128, e.g. certtool
--sec-param high --generate-privkey.

> In addition a quick "Google" around appears to imply that at current rates
> AES-128 will be considered unsafe by around 2030. 

Please cite your sources explicitly.  Google does not return the same
answers for everyone, or over time.

I agree we need to be conservative about our default algorithm choices,
but i don't think a move to AES-256 by default is the the right place to
push right now.

	--dkg

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1010 bytes
Desc: OpenPGP digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-gnutls-maint/attachments/20140321/e2ff3135/attachment.sig>