Bug#464625: please support OpenSSL-compatible ciphher nammes

Nikos Mavrogiannopoulos nmav at gnutls.org
Fri Feb 4 11:15:14 UTC 2011


On Thu, Feb 3, 2011 at 11:15 PM, brian m. carlson
<sandals at crustytoothpaste.net> wrote:

> I am a system administrator and programmer and I do know what each
> ciphersuite does, offers, and costs.  I've implemented cryptographic
> algorithms, including the second-fastest non-assembly implementation of
> MD5 (according to my testing).  I'm well-versed in cryptography and have
> strong opinions about what algorithms I want and do not want; those
> opinions are based on research and fact, not a quick Google search.

This is quite nice, but you should understand that not all people are like
you. GnuTLS has to be usable by a variety of people with different backgrounds.
What we do is to offer simple options for everyone and more advanced ones
for everyone else.

> In fact, I happen to know that the documentation for GnuTLS is wrong
> when it claims that "[t]here are no known weaknesses of" MD2.  Such

You are right. We do not claim to be authorities. More mistakes might
be possibly existing in the documentation. It is a collaborate effort, so
we would appreciate if you report them.

> (AFAICT) GnuTLS has existed.  And that's to say nothing about it being
> dog-slow (14 times slower than SHA-256).

We don't support MD2 in gnutls. It is not even implemented in libgcrypt.

[...]
> This bug is discussing the use of OpenSSL-compatible cipher names.
> OpenSSL is *the* choice for cryptographic implementation in the
> GNU/Linux world.

That is your point of view alone. Others say NSS is "the" choice. We just
happen to be discussing gnutls. GnuTLS is not an openssl clone, nor we
are interested into making it one. However we accept patches that
other people find them useful (such as the limited openssl compatibility layer
by Andrew McDonald).

> And the OpenSSL names, besides being more common, are shorter, clearer,
> and more easily understood.

That is a personal opinion. My opinion is that GnuTLS priorities are simpler
to understand, because they apply on individual ciphers and algorithms
and not ciphersuites that are only known to TLS implementors. Anyway
this depends on the eye of the beholder.

> The GnuTLS priorities (which I am not
> proposing removing, only adding to) are defined only very vaguely in
> gnutls-cli(1).

They are described in the function gnutls_priority_init() at:
http://www.gnu.org/software/gnutls/manual/html_node/Core-functions.html#Core-functions
If it is about documentation, you can suggest what is not clear to
you, or what you think it is missing and we can improve the documentation.

> Not  Looking at the source, RC4 is defined in SECURE256, and
> due to major weaknesses in its key scheduling (which can be used very
> effectively against e.g. WEP), I would absolutely not want to use it if
> any other choice were available.

The known attacks on RC4 are not effective against the TLS' usage of
RC4. Having said that, you might be right that it might not deserve to be
on the secure set.

>  Had I not looked at the source, I
> would never have known this.  I would certainly not class it as
> "secure".  The OpenSSL syntax allows me to specify that it is to be the
> last possible choice: AES:CAMELLIA:3DES:@STRENGTH:+RC4:!EXPORT.

The gnutls syntax allows that as well. Just add it after the other
ciphers. However
you shouldn't rely on that since the client is the one that is
actually setting the
priority order.

> I think it's reasonable to allow OpenSSL-compatible ciphersuite names.
> In fact, I think it's a really good idea.  I would even implement it
> myself,
We are open to suggestions that will make the priority strings better. We
could even add such compatibility if you contribute it (in a way that
doesn't replace the existing strings of course).

> but I refuse to assign copyright[0], and I'm not going to waste
> time writing code that will be thrown away.  Nevertheless, I strongly
> urge you to support the OpenSSL syntax.
> [0] This is a blanket policy unless we've executed a consulting contract
> that says otherwise.  I think that when I make a contribution to a
> project that it's only fair to be attributed as the author of my work;
> my copyright notice ensures that I get credit for the work I've done.

I can live with that, eventhough in gnutls we acknowlege all authors with the
"author" field on every file. The copyright transfer is for FSF and ensures an
easier case if legal issues occur.

regards,
Nikos





More information about the Pkg-gnutls-maint mailing list