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

[Daniel Kahn Gillmor]

On 03/22/2014 01:27 PM, Robert de Bath wrote:
> On Fri, 21 Mar 2014, Daniel Kahn Gillmor wrote:
>> which keys are you talking about here?  where are these numbers from?
> I ran the one line script in this "bug report" against a current Debian
> testing install.
> 
> $ for i in /etc/ssl/certs/*; do certtool -i < $i; done|grep
> 'bits'|sort|uniq -c
> 
> The Modulus lines are:
>      76                 Modulus (bits 1024):
>     424                 Modulus (bits 2048):
>     136                 Modulus (bits 4096):


/etc/ssl/certs is a set of config files.  in general, it's supposed to
contain the certificates for root CAs that are "trusted" by the system
to certify other parties.  Usually, they certify intermediate CAs, who
in turn certify end-entities (EEs) such as web servers or e-mail users.

root CAs tend to have long-term keys -- they need to be valid for a
decade or longer.  And they are incredibly high-value targets, since
cracking a root CA's key means the ability to mint arbitrary
certificates, which lets the attacker MiTM any connection for which
they're on the network path (or just impersonate the server without MiTM).

actual EEs themselves might not use 4096-bit keys.  Indeed, an actual EE
might only have a key that's used for a year before it is superseded by
a new key.  cracking a single EE's key means getting access to their
previous non-PFS traffic and being able to MiTM (or impersonate) just
that EE.

The key strength requirements for these scenarios (root CA vs. EE) are
likely to be different.

> Yes, from the estimates above that may be a good idea. A 4K key would
> be overkill, but 3K as in their 'Future' suggestions might be right.
> What's more as this is often used once per connection (not per byte)
> your power/heat budget note isn't as applicable.

"once per connection" can potentially be very often depending on the
work pattern of your particular communications suite.

>> Please cite your sources explicitly.  Google does not return the same
>> answers for everyone, or over time.
> Sorry, on rechecking this seems to be the "drop dead" date for 3DES;
> I though 3DES was already dead ... oh well.

In the real world, 3DES is still very much alive (i think windows XP's
SChannel TLS implementation supports only RC4 and 3DES), though 3DES is
much slower than (and somewhat less secure than) AES 128.

Again, though, it would have been nice if you had cited your sources,
with a URL at least.  anyone stumbling across this discussion in the
future still won't know what you were referring to here.

Regards,

	--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/20140323/c64c0dba/attachment.sig>