The infoanarchist guide to evaluating crypto products

From InfoAnarchy
Jump to: navigation, search

The goal of this guide is to give people a kind of checklist in order to evaluate the security of a cryptographic product.

Evaluating the reviews

When you try to know whether to trust someone's evaluation of some crypto product, you have to weight the person's credential against the probability of the person having a hidden agenda. Good credentials could be a PhD in cryptography with papers published and cited, huge hidden agenda would be NSA spokesperson. When you evaluate someone credentials always keep in mind that their could be an hidden agenda behind what they say. Even scientists can be involved in business ventures and be biased against competing products or protocols. Beware also of the pure theoretician that may miss small implementation details that are really the devil in a cryptosystem. The biggest credentials for evaluating a random cryptosystems are from people who have both implemented and broken real world cryptosystems (and didn't have their systems broken). Some examples would be Paul Kocher, Bruce Schneier...

Evaluating individual components of a cryptosystem

Evaluating symmetric algorithms

Evaluating key size adequacy

Evaluating design

Is the design proven to resist known attacks such as linear cryptanalysis and differential cryptanalysis? What is the best attack on a reduced round version of the algorithm? The later can give you an idea of the security margin an algorithm got, but the for example Skipjack got 32 rounds, it has been years that an attack on a version reduced to 31 rounds exists but no one have been able to extend it to the full algorithm yet.

Miscellaneous points to check

  • Algorithm output shouldn't be distinguishable from white noise, if it is not the case do not use!
  • If the algorithm uses S-boxes how have they been generated? (e.g. Blowfish uses decimals of Π, a number unlikely to have been tainted by the NSA).

Evaluating asymmetric algorithms

Evaluating key size adequacy

Evaluating design

Evaluating cryptographic hashes

Evaluating output length adequacy

The birthday paradox consequence is that for finding a collision for a cryptographic hash with a n-bit output you only have to do an amount of work in the order of O(2^(n/2)) with a brute force attack. Compare this to a symmetric encryption algorithm where when using a n-bit key the brute force attack has a cost in the order of O(2^n). This means that in a well designed product when symmetric key cryptography and cryptographic hashes are used together (very common, the encryption ensuring confidentiality and the cryptographic hash ensuring authentication used in a MAC) one should choose matched crypto key size/hash output size. e.g. coupling AES-128 with SHA-256 or 3DES (112 bits effective key-size) with SHA-224.

Evaluating design

Evaluating cryptographic PRNG

A computer, being deterministic, cannot generate random bits. This state of the affairs combined with crypto products hungriness for random bits (used as IV, padding, ephemeral key...) leads to the use of Pseudo Random Number Generator.

Evaluating cryptographic constructs

Initialization vectors

Chaining mode

An application that uses AES-256 as its cryptographic algorithm may look very secure, but it may very well not be if the wrong chaining mode is used. The worst that can be used is Electronic Code Book (ECB) but others can be pretty bad too. The best chaining mode depends on the algorithm used and the application so one should really check the state of the art to know if an algorithm and a chaining mode are a good match.

Message authentication code

Workarounding known weaknesses

e.g. if the application uses RC4 does it correctly discard the beginning of the random stream as not doing so expose some vulnerabilities? Does the application makes effort to avoid weak keys when some are known for the algorithm used?

Evaluating products

Other factors

Further readings