Re: [Wireshark-dev] Remove our bundled crypto library (in favor of Libgcrypt)?

[Ed Beroset]

Bálint Réczey wrote:


+1 for going without a new layer of indirections.
Making libgcrypt mandatory is easy and every level of indirection make
understanding the code harder which is a source of bugs.

If we ever feel dropping libgcrypt necessary we can add the new layer.


FWIW, I heartily agree with this.  While I have no objection to nettle, 
I think that adding support for multiple libraries is unlikely to be 
worth the effort.


I also seem to recall that the reason QEMU has both is that it relied on 
gnutls and it's *that* package that had support for both.  Rather than 
linking yet another library, QEMU used to default to whatever had been 
selected for gnutls.  The change to allow an explicit choice when 
building QEMU is only a year or two old.


Ed
___
Sent via:Wireshark-dev mailing list 
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

Re: [Wireshark-dev] Remove our bundled crypto library (in favor of Libgcrypt)?

[João Valverde]

On 02/11/2017 09:44 PM, Peter Wu wrote:

On Sat, Feb 11, 2017 at 08:54:39PM +, João Valverde wrote:
[..]

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.


Disabling is an option if you want to make the crypto library optional,
but the vast majority of the files/functions are hash functions (md5 is
used for example in editcap.c for duplicate detection). Since you need a
crypto library for the hash functions, you get decryption algorithms
like AES for free. (Unless you want to keep the bundled algorithms... I
would rather not).


OK, I'm swayed by those arguments. I was already fine with making it 
mandatory anyway.

___
Sent via:Wireshark-dev mailing list 
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

Re: [Wireshark-dev] Remove our bundled crypto library (in favor of Libgcrypt)?

[Guy Harris]

On Feb 11, 2017, at 1:57 PM, Bálint Réczey  wrote:

> +1 for going without a new layer of indirections.
> Making libgcrypt mandatory is easy and every level of indirection make
> understanding the code harder which is a source of bugs.

+1

Enough places in Wireshark use it, and there will probably be, over time, 1) 
more encryption in protocols and 2) more calls for Wireshark to do decryption 
whenever possible, so I consider it worthy of deeming an essential support 
library for packet analysis.

If you want a small tool to run on devices, put a *capture* tool there and do 
the *analysis* on something big enough to do the job.
___
Sent via:Wireshark-dev mailing list 
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

Re: [Wireshark-dev] Remove our bundled crypto library (in favor of Libgcrypt)?

[Bálint Réczey]

Hi,

2017-02-11 22:44 GMT+01:00 Peter Wu :
> On Sat, Feb 11, 2017 at 08:54:39PM +, João Valverde wrote:
> [..]
>> 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.
>
> Disabling is an option if you want to make the crypto library optional,
> but the vast majority of the files/functions are hash functions (md5 is
> used for example in editcap.c for duplicate detection). Since you need a
> crypto library for the hash functions, you get decryption algorithms
> like AES for free. (Unless you want to keep the bundled algorithms... I
> would rather not).
>
> At this moment I don't know how the end result looks like. Maybe after
> actually looking at the files/functions, we'll see whether an extra
> abstraction is worth it or not.

+1 for going without a new layer of indirections.
Making libgcrypt mandatory is easy and every level of indirection make
understanding the code harder which is a source of bugs.

If we ever feel dropping libgcrypt necessary we can add the new layer.

Cheers,
Balint
___
Sent via:Wireshark-dev mailing list 
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

Re: [Wireshark-dev] Remove our bundled crypto library (in favor of Libgcrypt)?

[Peter Wu]

On Sat, Feb 11, 2017 at 08:54:39PM +, João Valverde wrote:
[..]
> 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.

Disabling is an option if you want to make the crypto library optional,
but the vast majority of the files/functions are hash functions (md5 is
used for example in editcap.c for duplicate detection). Since you need a
crypto library for the hash functions, you get decryption algorithms
like AES for free. (Unless you want to keep the bundled algorithms... I
would rather not).

At this moment I don't know how the end result looks like. Maybe after
actually looking at the files/functions, we'll see whether an extra
abstraction is worth it or not.
-- 
Kind regards,
Peter Wu
https://lekensteyn.nl
___
Sent via:Wireshark-dev mailing list 
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

Re: [Wireshark-dev] Remove our bundled crypto library (in favor of Libgcrypt)?

[Peter Wu]

(forgot to attach the file lists...)

On Sat, Feb 11, 2017 at 10:35:10PM +0100, Peter Wu wrote:
> On Sat, Feb 11, 2017 at 09:31:17PM +0100, Erik de Jong wrote:
> > On Sat, Feb 11, 2017 at 8:55 PM, Peter Wu  wrote:
> [..]
> > > 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.
> 
> Thanks!  The following files need to be modified / removed:
> 
> debian/libwsutil0.symbols
> wsutil/CMakeLists.txt
> wsutil/Makefile.am
> wsutil/aes.c
> wsutil/aes.h
> wsutil/des.c
> wsutil/des.h
> wsutil/md4.c
> wsutil/md4.h
> wsutil/md5.c
> wsutil/md5.h
> wsutil/rc4.c
> wsutil/rc4.h
> wsutil/sha1.c
> wsutil/sha1.h
> wsutil/sha2.c
> wsutil/sha2.h
> 
> The symbols to be removed are:
> 
> - aes_cmac_encrypt_finish@Base 2.1.0
> - aes_cmac_encrypt_starts@Base 2.1.0
> - aes_cmac_encrypt_update@Base 2.1.0
> - crypt_des_ecb@Base 1.12.0~rc1
> - crypt_md4@Base 1.12.0~rc1
> - crypt_rc4@Base 1.12.0~rc1
> - crypt_rc4_init@Base 1.12.0~rc1
> - md5_append@Base 1.12.0~rc1
> - md5_finish@Base 1.12.0~rc1
> - md5_hmac@Base 1.12.0~rc1
> - md5_hmac_append@Base 1.12.0~rc1
> - md5_hmac_finish@Base 1.12.0~rc1
> - md5_hmac_init@Base 1.12.0~rc1
> - md5_init@Base 1.12.0~rc1
> - sha1_finish@Base 1.12.0~rc1
> - sha1_hmac@Base 1.12.0~rc1
> - sha1_hmac_finish@Base 1.12.0~rc1
> - sha1_hmac_starts@Base 1.12.0~rc1
> - sha1_hmac_update@Base 1.12.0~rc1
> - sha1_starts@Base 1.12.0~rc1
> - sha1_update@Base 1.12.0~rc1
> - sha256_finish@Base 2.1.0
> - sha256_hmac@Base 2.1.0
> - sha256_hmac_finish@Base 2.1.0
> - sha256_hmac_starts@Base 2.1.0
> - sha256_hmac_update@Base 2.1.0
> - sha256_starts@Base 2.1.0
> - sha256_update@Base 2.1.0
> 
> Attached are the files that need to be modified (one list for any
> occurrence per file, one list with files grouped per function).
> 
> The first three functions were "recently" added (see git logs) and is
> only used in airpdcap code.
> 
> Looking at crypt_des_ecb, the users are packet-ntlmssp.c and
> packet-dcerpc-netlogin.c. These also use md5 a lot and crypt_rc4.
> Do you have any preference for a file/crypto function to tackle?
> 
> Note that the current minimum Libgcrypt version is 1.4.2. For CMAC you
> need Libgcrypt 1.6.0 or newer. All other functions have been available
> for longer time. References that might be helpful:
> https://wiki.wireshark.org/Development/Support_library_version_tracking#Libgcrypt
> https://git.gnupg.org/cgi-bin/gitweb.cgi?p=libgcrypt.git;a=blob;f=NEWS
> https://gnupg.org/documentation/manuals/gcrypt/
> 
> If it helps, an example of using Libgcrypt (see .c and _test.lua files):
> https://github.com/Lekensteyn/luagcrypt
> -- 
> Kind regards,
> Peter Wu
> https://lekensteyn.nl
epan/dissectors/packet-snmp.c:1681: md5_hmac(msg, msg_len, key, key_len, 
calc_auth);
epan/dissectors/packet-snmp.c:1745: sha1_hmac(key, key_len, msg, msg_len, 
calc_auth);
epan/dissectors/packet-snmp.c:3369: md5_init();   /* initialize MD5 */
epan/dissectors/packet-snmp.c:3387: md5_append(, password_buf, 
64);
epan/dissectors/packet-snmp.c:3390: md5_finish(, key1); /* tell MD5 
we're done */
epan/dissectors/packet-snmp.c:3399: md5_init();
epan/dissectors/packet-snmp.c:3400: md5_append(, key1, 16);
epan/dissectors/packet-snmp.c:3401: md5_append(, engineID, engineLength);
epan/dissectors/packet-snmp.c:3402: md5_append(, key1, 16);
epan/dissectors/packet-snmp.c:3403: md5_finish(, key);
epan/dissectors/packet-snmp.c:3425: sha1_starts(); /* initialize SHA */
epan/dissectors/packet-snmp.c:3443: sha1_update (, password_buf, 
64);
epan/dissectors/packet-snmp.c:3446: sha1_finish(, key);
epan/dissectors/packet-snmp.c:3455: sha1_starts();
epan/dissectors/packet-snmp.c:3456: sha1_update(, key, SHA1_DIGEST_LEN);
epan/dissectors/packet-snmp.c:3457: sha1_update(, engineID, 
engineLength);
epan/dissectors/packet-snmp.c:3458: sha1_update(, key, SHA1_DIGEST_LEN);
epan/dissectors/packet-snmp.c:3459: sha1_finish(, key);
epan/dissectors/packet-3com-njack.c:542:md5_init(_ctx);
epan/dissectors/packet-3com-njack.c:543:md5_append(_ctx, workbuffer, 
32);
epan/dissectors/packet-3com-njack.c:544:md5_finish(_ctx, digest);
epan/dissectors/packet-3com-njack.c:545:md5_init(_ctx);
epan/dissectors/packet-3com-njack.c:546:md5_append(_ctx, 

Re: [Wireshark-dev] Remove our bundled crypto library (in favor of Libgcrypt)?

[Peter Wu]

On Sat, Feb 11, 2017 at 09:31:17PM +0100, Erik de Jong wrote:
> On Sat, Feb 11, 2017 at 8:55 PM, Peter Wu  wrote:
[..]
> > 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.

Thanks!  The following files need to be modified / removed:

debian/libwsutil0.symbols
wsutil/CMakeLists.txt
wsutil/Makefile.am
wsutil/aes.c
wsutil/aes.h
wsutil/des.c
wsutil/des.h
wsutil/md4.c
wsutil/md4.h
wsutil/md5.c
wsutil/md5.h
wsutil/rc4.c
wsutil/rc4.h
wsutil/sha1.c
wsutil/sha1.h
wsutil/sha2.c
wsutil/sha2.h

The symbols to be removed are:

- aes_cmac_encrypt_finish@Base 2.1.0
- aes_cmac_encrypt_starts@Base 2.1.0
- aes_cmac_encrypt_update@Base 2.1.0
- crypt_des_ecb@Base 1.12.0~rc1
- crypt_md4@Base 1.12.0~rc1
- crypt_rc4@Base 1.12.0~rc1
- crypt_rc4_init@Base 1.12.0~rc1
- md5_append@Base 1.12.0~rc1
- md5_finish@Base 1.12.0~rc1
- md5_hmac@Base 1.12.0~rc1
- md5_hmac_append@Base 1.12.0~rc1
- md5_hmac_finish@Base 1.12.0~rc1
- md5_hmac_init@Base 1.12.0~rc1
- md5_init@Base 1.12.0~rc1
- sha1_finish@Base 1.12.0~rc1
- sha1_hmac@Base 1.12.0~rc1
- sha1_hmac_finish@Base 1.12.0~rc1
- sha1_hmac_starts@Base 1.12.0~rc1
- sha1_hmac_update@Base 1.12.0~rc1
- sha1_starts@Base 1.12.0~rc1
- sha1_update@Base 1.12.0~rc1
- sha256_finish@Base 2.1.0
- sha256_hmac@Base 2.1.0
- sha256_hmac_finish@Base 2.1.0
- sha256_hmac_starts@Base 2.1.0
- sha256_hmac_update@Base 2.1.0
- sha256_starts@Base 2.1.0
- sha256_update@Base 2.1.0

Attached are the files that need to be modified (one list for any
occurrence per file, one list with files grouped per function).

The first three functions were "recently" added (see git logs) and is
only used in airpdcap code.

Looking at crypt_des_ecb, the users are packet-ntlmssp.c and
packet-dcerpc-netlogin.c. These also use md5 a lot and crypt_rc4.
Do you have any preference for a file/crypto function to tackle?

Note that the current minimum Libgcrypt version is 1.4.2. For CMAC you
need Libgcrypt 1.6.0 or newer. All other functions have been available
for longer time. References that might be helpful:
https://wiki.wireshark.org/Development/Support_library_version_tracking#Libgcrypt
https://git.gnupg.org/cgi-bin/gitweb.cgi?p=libgcrypt.git;a=blob;f=NEWS
https://gnupg.org/documentation/manuals/gcrypt/

If it helps, an example of using Libgcrypt (see .c and _test.lua files):
https://github.com/Lekensteyn/luagcrypt
-- 
Kind regards,
Peter Wu
https://lekensteyn.nl
___
Sent via:Wireshark-dev mailing list 
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

Re: [Wireshark-dev] Remove our bundled crypto library (in favor of Libgcrypt)?

[João Valverde]

On 02/11/2017 07:55 PM, Peter Wu wrote:

On Sat, Feb 11, 2017 at 06:27:41PM +, João Valverde wrote:

On 02/11/2017 12:14 PM, Peter Wu wrote:

On Fri, Feb 10, 2017 at 12:59:46AM +, 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  
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.

___
Sent via:Wireshark-dev mailing list 
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

Re: [Wireshark-dev] Remove our bundled crypto library (in favor of Libgcrypt)?

[Guy Harris]

On Feb 8, 2017, at 3:18 PM, Peter Wu  wrote:

> On Wed, Feb 08, 2017 at 10:51:29AM -0800, Guy Harris wrote:
>> On Feb 8, 2017, at 5:40 AM, Peter Wu  wrote:
>> 
>>> I did not expect Libgcrypt to consume entropy when it is just doing
>>> decryption.
>> 
>> I'm concerned with consuming CPU and wall-clock time - i.e., slowing *shark 
>> startup - not entropy.
> 
> Could you clarify this concern? I did not observe an attempt by
> Libgcrypt to obtain entropy at startup

Good!  That means that libgcrypt won't cause this sort of problem that OpenSSL 
causes:

https://mta.openssl.org/pipermail/openssl-users/2015-January/000295.html

or that libgcrypt caused on Windows at one point:

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=3270

I remember some issue such as this coming up somewhere in Wireshark, but it 
might have been bug 3270.
___
Sent via:Wireshark-dev mailing list 
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

Re: [Wireshark-dev] Remove our bundled crypto library (in favor of Libgcrypt)?

[Peter Wu]

On Sat, Feb 11, 2017 at 06:27:41PM +, João Valverde wrote:
> On 02/11/2017 12:14 PM, Peter Wu wrote:
> > On Fri, Feb 10, 2017 at 12:59:46AM +, 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 
> > > > >  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 :-)
-- 
Kind regards,
Peter Wu
https://lekensteyn.nl
___
Sent via:Wireshark-dev mailing list 
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

Re: [Wireshark-dev] Remove our bundled crypto library (in favor of Libgcrypt)?

[João Valverde]

On 02/11/2017 12:14 PM, Peter Wu wrote:

On Fri, Feb 10, 2017 at 12:59:46AM +, 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  
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?

___
Sent via:Wireshark-dev mailing list 
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

Re: [Wireshark-dev] Submitting a fix to 2.2.4

[Jaap Keuter]

> On 10 Feb 2017, at 21:29, Guy Harris  wrote:
> 
> On Feb 10, 2017, at 11:58 AM, Michael Mann  wrote:
> 
>> (git review may work, but I've never tried it outside of master branch)
> 
> I have, and it works, at least for me.
> 

Me 2

___
Sent via:Wireshark-dev mailing list 
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