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

[Peter Wu <peter () lekensteyn nl>]

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.
-- 
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