Pitfalls of cryptographic code

Question

I'm modifying existing security code. The specifications are pretty clear, there is example code, but I'm no cryptographic expert. In fact, the example code has a disclaimer saying, in effect, "Don't use this code verbatim."

While auditing the code I'm to modify (which is supposedly feature complete) I ran across this little gem which is used in generating the challenge:

static uint16 randomSeed;

...

uint16 GetRandomValue(void)
{
  return randomSeed++;/* This is not a good example of very random generation :o) */
}

Of course, the first thing I immediately did was pass it around the office so we could all get a laugh.

The programmer who produced this code knew it wasn't a good algorithm (as indicated by the comment), but I don't think they understood the security implications. They didn't even bother to call it in the main loop so it would at least turn into a free running counter - still not ideal, but worlds beyond this.

However, I know that the code I produce is going to similarly cause a real security guru to chuckle or quake.

• What are the most common security problems, specific to cryptography, that I need to understand?
• What are some good resources that will give me suitable knowledge about what I should know beyond common mistakes?

-Adam

Answer 1

Don't try to roll your own - use a standard library if at all possible. Subtle changes to security code can have a huge impact that aren't easy to spot, but can open security holes. For example, two modified lines to one library opened a hole that wasn't readily apparent for quite some time.

Answer 2

Applied Cryptography is an excellent book to help you understand crypto and code. It goes over a lot of fundamentals, like how block ciphers work, and why choosing a poor cipher mode will make your code useless even if you're using a perfectly implemented version of AES.

Some things to watch out for:

• Poor Sources of Randomness
• Trying to design your own algorithm or protocol - don't do it, ever.
• Not getting it code reviewed. Preferably by publishing it online.
• Not using a well established library and trying to write it yourself.
• Crypto as a panacea - encrypting data does not magically make it safe
• Key Management. These days it's often easier to steal the key with a side-channel attack than to attack the crypto.