Wireshark mailing list archives
Re: Remove our bundled crypto library (in favor of Libgcrypt)?
From: Peter Wu <peter () lekensteyn nl>
Date: Wed, 8 Feb 2017 14:40:27 +0100
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.
Which, if any, of those libraries can be prevented from wasting Wireshark's time by telling them not to bother gathering entropy unless they're doing it on behalf of some library called by Wireshark? We only care about decryption.
I did not expect Libgcrypt to consume entropy when it is just doing decryption. Ran `strace -k -e open,getrandom tshark -r ...` with TLS decryption enabled and found that the only consumers of randomness (/dev/urandom) at runtime are: wmem_init_hashing (g_random_int), init_dissection (ares_init_options), host_name_lookup_init (ares_init_options) At startup we have a getrandom syscall from GnuTLS (constructor?): getrandom("\336", 1, GRND_NONBLOCK) _dsa_validate_dss_pq gnutls_supplemental_send gnutls_global_set_log_level So it seems that Libgcrypt is not unnecessarily draining entropy. -- 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
Current thread:
- Remove our bundled crypto library (in favor of Libgcrypt)? Peter Wu (Feb 05)
- Re: Remove our bundled crypto library (in favor of Libgcrypt)? Erik de Jong (Feb 05)
- Re: Remove our bundled crypto library (in favor of Libgcrypt)? João Valverde (Feb 05)
- Re: Remove our bundled crypto library (in favor of Libgcrypt)? Gerald Combs (Feb 06)
- Re: Remove our bundled crypto library (in favor of Libgcrypt)? Peter Wu (Feb 06)
- Re: Remove our bundled crypto library (in favor of Libgcrypt)? João Valverde (Feb 06)
- Re: Remove our bundled crypto library (in favor of Libgcrypt)? Guy Harris (Feb 06)
- Re: Remove our bundled crypto library (in favor of Libgcrypt)? Peter Wu (Feb 08)
- Re: Remove our bundled crypto library (in favor of Libgcrypt)? Guy Harris (Feb 08)
- Re: Remove our bundled crypto library (in favor of Libgcrypt)? Peter Wu (Feb 08)
- Re: Remove our bundled crypto library (in favor of Libgcrypt)? Guy Harris (Feb 11)
- Re: Remove our bundled crypto library (in favor of Libgcrypt)? Bálint Réczey (Feb 09)
- Re: Remove our bundled crypto library (in favor of Libgcrypt)? Bálint Réczey (Feb 09)
- Re: Remove our bundled crypto library (in favor of Libgcrypt)? Gerald Combs (Feb 06)
- Re: Remove our bundled crypto library (in favor of Libgcrypt)? João Valverde (Feb 09)
- Re: Remove our bundled crypto library (in favor of Libgcrypt)? Peter Wu (Feb 11)
- Re: Remove our bundled crypto library (in favor of Libgcrypt)? João Valverde (Feb 11)
- Re: Remove our bundled crypto library (in favor of Libgcrypt)? Peter Wu (Feb 11)
- Re: Remove our bundled crypto library (in favor of Libgcrypt)? Erik de Jong (Feb 11)