Hacker News Reader

Comment by rdl | Hacker News Reader

Even using those, people will mess up key management and other security critical aspects.

I'm a little allergic to allusions to the risk of "key management", because Applied Cryptography (not a good book) calls that out specifically as the riskiest thing about implementing crypto, and it is most definitely not the riskiest thing about implementing crypto.

So let me just say that while key management is hard, even if you stipulate that your key management is perfect, you are probably still boned. The simple task of exchanging real time messages between two parties with secure keys is treacherously hard to implement.

Hi, what book would you recommend in alternative to e Applied Cryptography?

Practical Cryptography (also known as Cryptography Engineering).

But read them to learn how to break cryptosystems, and then go do that. Don't read them and then try to build something. They're missing details too.

Yup. Just to give the uninitiated some examples of things you have to watch out for:

1) don't do the modern day equivalent of an Enigma-style 'cillies', ie doing something that reduces the entropy of your key generator (not using the full range of possible values, not having a random distribution of values, etc)

2) Make sure that the decryption time does not vary with the number of correctly guessed bits of the key, ie don't stop a decryption attempt in the real system if you discover that the decryption must be wrong part way through.

3) Make sure that your randomly generated keys don't ever generate keys that create a degenerate crypto text

4) Make sure that you don't use a key for longer than it's cryptoperiod

that's just a small sample of the gotchas that can ping you. And in that list, I'm only worrying about plain decryption of the message, without worrying about 'minor' details such as identifying that a party is who they say they are, man-in-the-middle attacks, replay attacks (resending a recorded encrypted message later on, to open access to something), injecting messages into the communication and so on.

I think AC is, like Zimmerman above, talking mostly about the data-at-rest case when it refers to key management being the riskiest part. This is reasonable, because in the data-at-rest case, all cryptography does is replace a large secret (the plaintext you want to protect) with a small secret (the key you need to protect instead). If you already had a keeping-something-a-secret problem, then it's reasonable to presume that you will have almost as much of a problem keeping the key a secret.

First, _Applied_ is totally not just talking about data at rest. It's chock full of archaic challenge-response protocols and half-specified descriptions of asy key exchange schemes.

Second, even for data at rest problems, _Applied_ is a terrible resource.

Just get _Practical Cryptography_ and burn your copy of _Applied_. Schneier co-authored _Practical_. It's a great book.

Agreed - I have both already, I haven't burnt AC yet though (I find it occasionally useful for identifying which oddball 90s cipher a developer has gotten it into their head to use - yes, I have actually seen "3-Way" used in anger...)

Reply on news.ycombinator.com