[gnutls-devel] cipher suites

[Nikos Mavrogiannopoulos]

On 10/20/2013 08:15 PM, Stefan Bühler wrote:
> Hi,
> I was wrong; although nettle supports GCM with all 128-bit block
> ciphers, the Camellia-{128,256}-GCM ciphers are not listed in the
> supported cipher list in GnuTLS yet.

I have added most, if not all of the missing ciphersuites. Unfortunately
for several of them there are no test servers I can test against (e.g.,
camellia-gcm). Hence, I have not enabled them by default.

> As I recently learned that GnuTLS (sometimes) does its own AES/GCM stuff
> due to AES-NI, I'm not sure how hard it would be to combine the AES-NI
> GCM implementation with the Camellia implementation from nettle.
> (Also it'd be really nice to have AES-NI accelerated AES/GCM in
> nettle instead - I think it belongs there :) )

gnutls overrides the nettle implementation's only if per-cpu
optimizations such as aes-ni/padlock are detected. I also think it would
be nicer if nettle could accommodate these (in fact this is what I miss
most from nettle).

> Also I wanted to ask about the state of the (ESTREAM)-Salsa20
> ciphersuites.
> The draft at http://tools.ietf.org/html/draft-josefsson-salsa20-tls-02
> expired some days ago, and the numbers GnuTLS is using for them (0xE4,
> 0x10-0x39) are not actually private - they are just unassigned.
> (According to
> http://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml
> only (0xFF,0x00-0xFF) is reserved for private use).

It is high likely that private use would clash with other private
extensions in other ciphersuites. I used the "Specification required
range" in hope that they will be assigned these numbers soon. If the
draft is not approved (or approved with major changes), I may consider
moving them to private range or dropping them completely.

http://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-4

regards,
Nikos