[gnutls-devel] what should be the actual security level of SECURE128?
tim.ruehsen at gmx.de
Fri Feb 7 15:50:50 CET 2014
On Friday 07 February 2014 08:51:43 Nikos Mavrogiannopoulos wrote:
> In the 3.3.0 branch one of the new features is the enforcement of the
> security level in certificate verification. That would be that with the
> SECURE-128 priority string one would expect a minimum security level of
> 128-bits. However, that would mean that today one couldn't connect on
> any major website on the internet as their certificates are signed using
> SHA1 (that provides 80-bits of security in theory - less in practice).
> So the question is what should we do in gnutls. Make SECURE128 just a
> string that provides better security than NORMAL, or enforce the 128-bit
> level when this string is specified? The latter will have quite some
> implications as a lot of software seems to specify SECURE128 as the
> default priority string for no particular reason (and often with no way
> to change it). Any ideas?
As I understood, SECURE128 right now combines two different things, which in
the docs (http://gnutls.org/manual/html_node/Priority-Strings.html) are named
1) message authenticity security level
2) security level (i guess that means 'data encryption security level')
You could add new keywords for 1) e.g. AUTH128 etc.
Old software (recompiled or not) could still work with newer libraries.
Adapted software will/can check for newer libraries available (at compile
and/or run time) and may use the set of keywords at will.
Another option would be to have a new function to enable the new behavior at
Maybe with some kind of non-fatal warning during handshake if the function
hasn't been called and SECURE128 has been given without AUTH...?
Just enforcing the new security level sounds like breaking lot's of software
(as you say). If you really want enforcement, there should at least be some
kind of external control mechanism for users and packagers (maybe a ENV
Just ideas that popped up.
More information about the Gnutls-devel