gnutls-3.0.9, PSK and SECURE256

[Nikos Mavrogiannopoulos]

On 12/18/2011 11:04 PM, Michael Weiser wrote:

>>> I don't want to debate the reason for removing AES128 from SECURE256.
>>> Obviously the security level with SECURE128 is just as high (or low)
>>> as before. Rather I wonder, why PSK isn't used in conjunction with
>>> AES256?
>> There is very little point to use SECURE256. This is really an insane
>> security level that has to be supported by public keys of equivalent
>> level (e.g. for DHE in your case) that are of a size that probably 
>> would make the handshake extremely slow.
> 
>> However, for the situation you describe the issue isn't AES-256 but the 
>> fact that the PSK ciphersuites (in rfc4279) are defined using SHA-1, which 
>> isn't available any more in the 256-bit security level.
> Will this be the case for the foreseeable future or is something
> better/more secure/fancier/faster already coming?


There are ciphersuites for PSK with AES-GCM support in rfc5487 that were 
not included/enabled in gnutls. I've enabled them in the repository
so this may suit your needs. AES-GCM might be slower than SHA1 though,
unless you have certain CPUs that optimize it.

> Should I contemplate moving away from PSK in favour of public key
> authentication in order to get a stronger hashing algorithm?


No. Although gnutls tries to keep a uniform security level with the
SECUREXXX priority strings, the security of the MAC is only significant
for the period of the connection (as opposed to the security of the
cipher which is significant for the period that the data need to be
kept secure). That's why their security level shouldn't be treated
the same. Maybe we should introduce asymmetric SECUREXXX variants
to reflect that.

> BTW: My program currently ends up using ECDHE_PSK_AES_128_CBC_SHA256.
> Isn't SHA256 actually SHA-2, not SHA-1?

Thanks for letting me know. It seems that ECDHE_PSK_AES_256_CBC_SHA256 
should also have been available, but due to a bug it wasn't. I've fixed that.

regards,
Nikos