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

[Bálint Réczey <balint@xxxxxxxxxxxxxxx>]

Hi,

2017-02-11 22:44 GMT+01:00 Peter Wu <peter@xxxxxxxxxxxxx>:
> On Sat, Feb 11, 2017 at 08:54:39PM +0000, 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