On Sat, Feb 11, 2017 at 8:55 PM, Peter Wu <pe...@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.valve...@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-requ...@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-requ...@wireshark.org?subject=unsubscribe
