gnutls-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [gnutls-dev] Time-based release schedule and GnuTLS v2.2 plans


From: Yoshisato YANAGISAWA
Subject: Re: [gnutls-dev] Time-based release schedule and GnuTLS v2.2 plans
Date: Wed, 19 Sep 2007 17:12:29 +0900
User-agent: Thunderbird 2.0.0.6 (Windows/20070728)

Simon Josefsson wrote:
Does somebody know an autoconf-option to check ciphers supported by
libgcrypt?

It would not be fool-proof, so I suggest that only a warning is given in
case the test fails, but the following test could work:

 libgcrypt-config --algorithms | grep -i camellia

What do you think?

It seems to be premature to directly write code adding support for camellia. I will insert "#ifdef USE_CAMELLIA" to the source code.

I don't think we can require libgcrypt 1.3.0+ yet.  Perhaps configure
could disable camellia support if a sufficient recent libgcrypt is not
detected?

OK, I will change the script to disable camellia when the result of "libgcrypt --algorithms" don't have camellia. Code in configure script will be:

    if test "`$LIBGCRYPT_CONFIG --algorithms | grep -i camellia`"; then
        CFLAGS += -DUSE_CAMELLIA
    else
        echo "$as_me: WARNING: camellia feature disabled" >& 2
    fi

Do you think switch on and off by #ifdef in source code is good idea?

Btw, in gnutls_priority.c, the cipher_priority array is intended to be
sorted by preference.  I believe it is too early to prefer Camellia over
AES and even 3DES by default today.  Preferring Camellia over Arcfour
may be a good idea though, we don't want to recommend arcfour to anyone.
So please move camellia down a bit in the cipher_priority array.
Opinions on this choice from others is very welcome.

I also move camellia down between 3DES and Arcfour. However, after camellia will have been diffused, it should be preferred over 3DES. According to the European NESSIE, 3DES is not recommended block cipher. Since camellia has a higher security margin than AES, it could be preferred over AES in the future.

Thank you,
Yoshisato YANAGISAWA.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]