[Pkg-gnutls-maint] Bug#476441: libgnutls26: chooses AES128 over AES256 (again)

[Simon Josefsson]

"brian m. carlson" <sandals at crustytoothpaste.ath.cx> writes:

> On Fri, May 16, 2008 at 10:41:20AM +0200, Simon Josefsson wrote:
>>Given the discussion so far at:
>>
>>http://thread.gmane.org/gmane.comp.encryption.gpg.gnutls.devel/2792
>
> I think it's silly to intentionally weaken part of the cryptosystem.
> The weakest part of the cryptosystem is currently the symmetric
> cipher.

We disagree rather fundamentally, it seems.  With AES-128, I believe the
weakest part in practice will be implementation bugs and insecure usage
of the library, insufficient protection of the private keys combined
with insecurity in other applications, and random human errors.  After
that I believe use of too small public key sizes and weakness in
MD5/SHA1 comes.  Remember, MD5 is rather broken and SHA-1 has been
broken to 2^69, even though the HMAC and non-standard way they are used
in TLS helps to mitigate this.  Only after this do I believe AES-128
will be a problem, given what we know about AES-128 today.

> You said that "to match a 256 bit symmetric key size, you need a ~15kb
> large RSA key or a ~500b large DSA key."

Actually that is what RFC 3766 says, not me.

> 500 bits is not a large key.  I can generate keys that are much larger
> than that, depending on the protocol.  1024 bits is the standard, and
> some applications allow much larger keys (OpenPGP and P.1363, for
> example).  If I used a 8192-bit p, then I could even make q a 512-bit
> prime.  8000-bit keys are not that far off in the future for high
> security applications.

jas at mocca:~$ for i in /etc/ssl/certs/*; do certtool -i < $i; done|grep 'bits'|sort|uniq -c
      4 		Modulus (bits 1000):
    191 		Modulus (bits 1024):
    298 		Modulus (bits 2048):
     60 		Modulus (bits 4096):
jas at mocca:~$ 

Thus, the majority of CAs that Debian distribute uses 2048 bit keys,
followed by 1024 bit keys.  The table in RFC 3766 isn't clear where the
limit for 128 bit is, but it is on par with 4096 bits:

   | System      |           |              |              |
   | requirement | Symmetric | RSA or DH    | DSA subgroup |
   | for attack  | key size  | modulus size | size         |
   | resistance  | (bits)    | (bits)       | (bits)       |
   | (bits)      |           |              |              |
   +-------------+-----------+--------------+--------------+
   |    100      |    100    |     1926     |     186      |
   |    150      |    150    |     4575     |     284      |

Given this selection of CA key sizes, I think AES-128 is a reasonable
default choice.  It won't be the weakest part for any of the CAs that
Debian distributes.

>>I'm inclined to close this as a wontfix report.
>
> Please don't close it.  If you don't want to implement it, you may tag
> it as wontfix.

Agreed, it shouldn't be closed, just stay as wontfix until/unless better
arguments can be made for changing the default.

>>That table is based on research in:
>>
>>http://citeseer.ist.psu.edu/lenstra99selecting.html
>
> I take exception to this data.  The lower bound for 2008 is 1279 bits,
> which is way, way too low.  An appropriate minimum key size for
> anything that will last more than a year is 2048.  I wouldn't even
> dream of using anything symmetric with less than 128 bits these days,
> unless it was 3DES-EDE3 (which is equivalent to 112 bits).

To change the default, I believe we need something more solid than just
your opinion.  Our current choice is based on reading two widely cited
references in this area, written by widely known people in this area.
If you know of other similar material with different conclusions, please
cite them.

>>We are open for discussion if you can provide better justification why
>>changing to AES-256 is warranted.
>>
>>Note that changing the default for all programs is different from
>>_allowing_ AES-256 to be used in each program.  I believe you should be
>>able to use AES-256 with all programs that use GnuTLS.  If a program
>>using GnuTLS doesn't allow you to use AES-256, please file a bug on that
>>program.
>
> Unfortunately mutt doesn't have that knob, and even if it did, it would
> be hard to use, since GnuTLS doesn't have the same names for ciphers and
> doesn't have the same categories either.  I think this solution is only
> acceptable if the names are the same, because otherwise, the config
> files break, depending on how the programs are compiled.
>
> Note that this happens with OpenLDAP, too.

Right, those are separate problems, and I agree with them.  I see that
you created separate bug reports for them.  Many thanks for separating
these issues.

/Simon