4

I would like to know how one goes about analyzing and picking a cryptography related library. For example, today we have many TLS implementations, that use cryptographic primitives, for example: GnuTLS, OpenSSL, LibreSSL, etc... So how do we pick one?

  • How do you analyze the library? Do you check the source code?
  • What if I am not a crypto expert? Should I rely on the organizations behind those libraries?

I've been recently using crypto related libraries provided by GNU, basically because their are open source (which makes it possible for anyone to review the code), have a good documentation and because GNU's projects are in general trustworthy and reliable. What other parameters, besides the lib's track record should I take into account?

Falcon
  • 43
  • 3
  • 1
    It's a broad question but essentially use something which fills you needs, is trusted by others and is well supported, i.e. check capabilities, how much used by others, security record (amount and handling of past vulnerabilities), still developed, maybe commercial support available, how many developers you find knowing this library ... – Steffen Ullrich Aug 23 '17 at 06:28
  • 1
    One good point that has not been mentioned yet is to make sure that it was written with [resistance to side channel attacks in mind](https://www.bearssl.org/constanttime.html). This might seem unnecessary, but side channels can easily turn an otherwise unbreakable algorithm/protocol into something that offers no real security against people who are motivated to try and break it. – Ella Rose Aug 23 '17 at 18:08
  • @EllaRose That's a very good point. So far, haven't seen any lib documentation mentioning that and having only taken introductory classes in cryptography/security I am far from being capable of checking that by myself. – Falcon Aug 23 '17 at 22:09

2 Answers2

5

Evaluating external libraries is always a difficult balancing act. In many cases, the people performing the evaluation are not specialists of the library's primary functions (otherwise, they often wouldn't need to use a 3rd party library). This is even more true of crypto because expertise in the crypto implementation is rare, hard to acquire and hard to access.

Therefore, I'd give the following advises:

  • Do not bother with attempting to audit the code for security. Audit it for clarity, ease of use, capability and fitness to you needs.
  • Make sure that the people how will be using it will understand how to use the API properly. Most application developers have little or no understanding of crypto. Many do not even properly understand how much they don't know about the subject (hence the alarmingly common habit of writing "custom spaghetti code" as "encryption" function or hard-coding keys inside the source code). Make sure you're not going to require them to make decisions that they aren't equipped to make (like picking a bloc cypher mode of operation or selecting an IV).
  • Make sure the code is properly maintained, now and in the future. This is probably the most important point.
  • What is the library reputation and, perhaps more important, track record in dealing with past flaws ? If you can't find any such track record, stay away: the code is too new (or too obscure) to have been properly tested or the people maintaining it are actively discouraging such external testing (or even worse: they aren't doing much maintenance).
  • Try to avoid hard dependencies as much as possible: write your own interfaces to the code that you will program against instead of coding against the API directly. Hopefully, that should make it easier to switch library if it becomes desirable or necessary.

In the end, you're going to have to put some trust in the hands of some stranger. Best is to treat that as any other business relationship: trust but verify and always have a backup plan.

Stephane
  • 18,607
  • 3
  • 62
  • 70
  • Great answer but some security specific auditing can be performed with relative ease. Consider projects such as the Google linked project Wycheproof for at least some automated assurance of third party libraries https://github.com/google/wycheproof – Joe Aug 23 '17 at 23:03
  • I don't think automated testing is that useful here: it's very dependent on what toolset (and environment) you're using and it's usually not trivial to use properly and interpret the result in a useful manner if you're not well-versed in the subject. Overall, I'd rather suggest that kind of check be left to others and simply falling back to my "reputation" point. – Stephane Aug 24 '17 at 07:51
0

For folks (including those who are technically very capable) who don't specialize in crypto, the only practical way to select a good crypto library is to read up about it and decide.

In general, trusting the advice of reputed orgs / specialists who openly recommend a particular library is not a bad idea. Of course they could make mistakes but that would still be better than an uninformed decision.

Additional factors: I would look for libs under active development, support for recent algorithms & protocols (e.g., argon2*), and support for my favorite programming language.

Sas3
  • 2,648
  • 9
  • 20