views:

285

answers:

6

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?
+6  A: 

Your question shows one of the more common ones: poor sources of randomness. It doesn't matter if you use a 256 bit key if they bits aren't random enough.

Number 2 is probably assuming that you can design a system better than the experts. This is an area where a quality implementation of a standard is almost certainly going to be better than innovation. Remember, it took 3 major versions before SSL was really secure. We think.

Darron
+1 "we think". The number of systems that are are proven secure is vanishing small. Even Systems using One-Time-Pads can be broken if there's some design fault (such as a bad PRNG).
Joachim Sauer
+18  A: 

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.

Tai Squared
Seconded. Cryptography Is _Hard_, Captial H.
Robert P
Yea, I agree. Not hard as in it is a good learning experience... but hard as in it is easy to get wrong and by wrong I mean vulnerable.
Simucal
Programming is hard, let's go shopping?
+1: do not roll your own crypto
Michael Haren
+2  A: 

What are the most common security problems, specific to cryptography, that I need to understand?

Easy - you(1) are not smart enough to come up with your own algorithm.

(1) And by you, I mean you, me and everyone else reading this site...except for possibly Alan Kay and Jon Skeet.

Mark Brackett
+11  A: 

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.
Tom Ritter
Good overview. I also gave another good reference to Prudent Protocol Engineering Practices in my answer bellow.
+1  A: 

I'm not a crypto guy either, but S-boxes can be troublesome when messed with (and they do make a difference). You also need a real source of entropy, not just a PRNG (no matter how random it looks). PRNGs are useless. Next, you should ensure the entropy source isn't deterministic and that it can't be tampered with.

My humble advice is: stick with known crypto algorithms, unless you're an expert and understand the risks. You could be better off using some tested, publicly-available open source / public domain code.

Eduard - Gabriel Munteanu
"If you need to ask the question, then don't mess with it!"
Joachim Sauer
Let me reformulate your advice: "If you are an expert and understand the risks then you stick with known crypto algorithms." :-)
Accipitridae
+3  A: 

IMHO, there are four levels of attacks you should be aware of:

  1. social engineering attacks. You should train your users not to do stupid things and write your software such that it is difficult for users to do stupid things. I don't know of any good reference about this stuff.

  2. don't execute arbitrary code (buffer overflows, xss exploits, sql injection are all grouped here). The minimal thing to do in order to learn about this is to read Writing Secure Code from someone at MS and watching the How to Break Web Software google tech talk. This should also teach you a bit about defense in depth.

  3. logical attacks. If your code is manipulating plain-text, certificates, signatures, cipher-texts, public keys or any other cryptographic objects, you should be aware that handling them in bad ways can lead to bad things. Minimal things you should be aware about include offline&online dictionary attacks, replay attacks, man-in-the-middle attacks. The starting point to learning about this and generally a very good reference for you is http://www.soe.ucsc.edu/~abadi/Papers/gep-ieee.ps

  4. cryptographic attacks. Cryptographic vulnerabilities include:

    • stuff you can avoid: bad random number generation, usage of a broken hash function, broken implementation of security primitive (e.g. engineer forgets a -1 somewhere in the code, which renders the encryption function reversible)
    • stuff you cannot avoid except by being as up-to-date as possible: new attack against a hash function or an encryption function (see e.g. recent MD5 talk), new attack technique (see e.g. recent attacks against protocols that send encrypted voice over the network)

A good reference in general should be Applied Cryptography.

Also, it is very worrying to me that stuff that goes on a mobile device which is probably locked and difficult to update is written by someone who is asking about security on stackoverflow. I believe your case would one of the few cases where you need an external (good) consultant that helps you get the details right. Even if you hire a security consultant, which I recommend you to do, please also read the above (minimalistic) references.