Generalized Crypto Interfaces and OpenSSL
KentYoder 270001NFM8 Visits (3274)
One often repeated piece of advice with respect to adding crypto to your app is to never roll your own crypto. That is, never reimplement a crypto algorithm from scratch. This is very good advice. There are already several different libraries to choose from that presumably will get the details right. Keeping the total number of crypto providers low also has benefits. This will allow all the security scrutiny (a scarce resource) to be focused on these few packages. Also, if FIPS certification is a goal, paying to certify one provider that everyone then uses on the system is cost effective, too.
So when its time to write your crypto app, you're likely going to be faced with writing general crypto interfaces for these external libraries. Since you don't know exactly which crypto provider will be available on which platform ahead of time, general interfaces will allow the implementation to change underneath without requiring a recompile of your app. So what are the gotchas when writing a generalized interface?
Three of these snippets work like you might guess. If zero is the return code from the first call, the signature check passes, otherwise we can assume either that the signature is invalid, or some other error occurred. But there is one exception, OpenSSL. From the docs:
So the correct signature check for OpenSSL's EVP_VerifyFinal():
I'm sure this seems obvious. Whenever you write code that allows implementations to be plugged underneath, you need to abstract all the details of those APIs in the same way. But in the wild, this sort of thing stil
If you plan on implementing an OpenSSL plugin, take a look at references  and  on common mistakes when using OpenSSL. Some diverge into bad uses of the SSL protocol, but depending on the scope of your plugin, there's some helpful advice there.