QCon London: How I Learned to Stop Worrying and Trust Crypto Again

Mother and Infant Bond a CC NC image by Steve Corey
By Graham Steel

The year 2013 is the year we found out that the tinfoil hat people were right and the NSA was actually listening to all our conversations.

However, even Snowden stated that properly implemented strong cryptographic systems will actually safe you.

In reality developers seldom design their own cryptographic engines and implementing your own based on a book like 'Applied cryptography ' is not recommended, so people are going to use existing existing APIs.

There are a few lessons to be learned when making these choices:

Lesson 1: Beware of Proprietary APIs

The Dual EC DRNG episode has shown this.

What makes a good API?
  1. Open and subject to review
  2. Support modern cryptographic primitives
  3. Support flexible, secure key management
  4. Is mistake resistant
  5. Will inter operate with other stuff

So lets look at different APIs...


Is the most ubiquitous for crypto hardware. Originally it was a RSA standard, moved to OASIS in 2013. The current version 2.20 dates back to 2004, v.240 is due RSN. It is defined as a C header files and 400 pages of documentation that describe what the functions should do and the standard is quite loose: every implementation is different.

The age of the API e.g. means that SHA1 is the only algorithm that can be used for password based key derivation.

  1. Open since 2013, but your implementation may be comes
  2. v2.40 will have some modern crypto but still logs of legacy stuff
  3. Key management is provided, but has many pitfalls
  4. Not very mistake resistant (low level API)
  5. Good interoperability across platforms


The standard Java crypto interface. It consists of APIs and providers that implement those interfaces. It is widespread and adopted in enterprise Java world. There is limited hardware support because some of the typical hardware functions are not a native part of the API.

  1. API is under Oracle control, some providers are open
  2. API is extensible, providers support some modern crypto but also lots of legacy stuff
  3. Some key management via Keystore, but there is little public information on how secure it is
  4. Not especially mistake resistant
  5. There is good inter operability between providers, e.g. PKCS#11

Originally an open source implementation of TLS/SSL, now used for almost anything.

  1. Source available, but decision process murky
  2. Contains legacy crypto (as does SSL!) as  well as some modern etensions
  3. Minimal key-management facilities
  4. Very easy to get wrong (see references)
  5. Compiled everywhere, TLS interoperability ok


CNG slowly replacing CAPI on MS platforms
  1. Closed API
  2. CNG contains some modern crypto, CAPI not
  3. No management of persistent symmetric keys
  4. Plenty of things to get wrong (e.g. contains the NSA backdoored Dual EC DRNG)
  5. Not very interoperable

W3C Crypto API
  1. A new W3C project tomake crypto available in the browser to HTML5 apps.
  2. Contains modern crypto, but despite fresh start, also contains legacy crypto
  3. Has some key management
  4. Some effort to make it easier to use
  5. Interoperability is unknown yet.


Nice high level design but favours Dan Berstein's primitives (which did not get as much review as e.g. RSA)


Supports many standard protocols with nice high level interface, but no OAEP, no SHA-2  

Even if you have chose a "good" API, a sound implementation, what could possibly go wrong?

Everything can go wrong...

Here is a list of common mistakes that have been makde in the past, however, addressing these mistakes does not mean you implementation is secure...
  1. Using legacy algorithm (e.g. using ECB because it doesn't require an initialization factor)
  2. Getting the initialization vector wrong: leaving the initialization factor to the API,
  3. Unauthenticated encryption (Yes, you really need to use authenticated encryption)
  4. Incorrect initialization of random number generators (are they really random?)
  5. Errors in protocols:
    1. Don't roll your own protocol
    2. Even mature protocols have flaws (e.g. TLS had new vulnerability just two days ago)
    3. But, you are still better of using a standard protocol then rolling your own


To maximize your changes of producing "strong crypto properly implemented"
  • Favour open API standards over proprietary
  • Look out for legacy
  • Check out the well-known pitfalls, avoid then
  • Review, review, review!


Not Published

0/1000 characters
Go Top