Wireshark-dev: Re: [Wireshark-dev] Remove our bundled crypto library (in favor of Libgcrypt)?
On 02/11/2017 07:55 PM, Peter Wu wrote:
On Sat, Feb 11, 2017 at 06:27:41PM +0000, João Valverde wrote:
On 02/11/2017 12:14 PM, Peter Wu wrote:
On Fri, Feb 10, 2017 at 12:59:46AM +0000, João Valverde wrote:
On 02/08/2017 01:40 PM, Peter Wu wrote:
On Mon, Feb 06, 2017 at 03:25:40PM -0800, Guy Harris wrote:
On Feb 6, 2017, at 3:17 PM, João Valverde <joao.valverde@xxxxxxxxxxxxxxxxxx> wrote:
None from me but can we use Nettle instead? Any reason not to? Word on the street is that it is more pleasant to work with than gcrypt.
I am only familiar with Libgcrypt which is not that hard to use. Have
you tried both libraries? What were your experiences?
License-wise they are similar. Based on development activity (commit
count), it seems that Nettle is mostly developed by one person while
Libgcrypt has more.
An actual look at the Nettle documentation shows that Nettle provides
direct access to crypto routines (aes128_encrypt, aes256_encrypt,
aes_decrypt, chacha_poly1305_set_key, etc.). Libgcrypt provides a more
generic interface (gcry_cipher_open, gcry_cipher_encrypt) which means it
is easier to use when multiple ciphers can be chosen (which is the case
for SSL/TLS, IPsec, IKE).
Thus, I think that it is better to stick to Libgcrypt than migrate to
Nettle.
I was not considering a migration from gcrypt to nettle, just choosing one
of the two libraries to replace our bundled crypto. Assuming the effort
required for that is similar (maybe an incorrect assumption).
The status quo is that Libgcrypt is already used in many places while
nettle is only an implicit dependency (needed for GnuTLS). Since
Libgcrypt and nettle are comparable in feature set, changing to nettle
would be more effort and it seems better to stick to Libgcrypt.
There are two things here: one is a bunch of Libgcrypt calls guarded by
#ifdefs. Those will stay, obviously, unless someone wants to step forward to
do the porting work and review to move to a different library.
The other is a bunch of of crypto files in wsutil that could be replaced by
any number of crypto libraries. For example wsutil/aes.c comes from FreeBSD
apparently. I hadn't even thought of Nettle before Gerald mentioned it but I
was just wondering if it would be a better option than Libgcrypt. No big
deal, just thought I would ask.
Your change set (20030) hasn't addressed the second case. All the wsutil
code is still there. Just out of curiosity are you planning to work on this?
My original goal was to replace wsutil by an existing crypto library
(case 2). Since we Libgcrypt is already used in a lot of places, it
seemed natural to replace wsutil by Libgcrypt.
When trying to do so, I noticed that having an optional Libgcrypt makes
it much harder and hence changeset 20030 was created first to make it
mandatory. Once that is in place, we can change the wsutil crypto users
to Libgcrypt. I plan to start working on that in the next days, let me
know if you want to join this effort :-)
I think a small abstraction layer above the lower-level crypto routines,
whatever those may be (libgcrypt, nettle, home-grown - yuck), would be a
useful thing to have. It would accomplish two things:
1. Easily change dependencies without having to change dissector code.
2. Disable crypto in a saner way and keep the dependency optional,
without having to use #ifdefs all over the place (just one place in
fact). Example:
int ws_aes_decrypt(...) {
#ifdef HAVE_AES_DEPENDENCY
err = aes_decrypt(...);
if (err == AES_OK) {
return WS_CRYPTO_OK;
} else {
...
}
#else
return WS_CRYPTO_DISABLED;
#endif
}
Then of course require crypto consumers (dissectors and whatever else)
to handle the WS_CRYPTO_DISABLED case as appropriate.
