Re: Remove our bundled crypto library (in favor of Libgcrypt)?

[Erik de Jong <erikdejong () gmail com>]

On Sat, Feb 11, 2017 at 8:55 PM, Peter Wu <peter () lekensteyn nl> 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 () tecnico ulisboa pt> 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'd like to help out, please tell me how I can assist in a way that won't
be counterproductive.


> --
> Kind regards,
> Peter Wu
> https://lekensteyn.nl
> ____________________________________________________________
> _______________
> Sent via:    Wireshark-dev mailing list <wireshark-dev () wireshark org>
> Archives:    https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
>              mailto:wireshark-dev-request () wireshark org?subject=
> unsubscribe
___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev () wireshark org>
Archives:    https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request () wireshark org?subject=unsubscribe