What advice would you give to someone who did realistically want to work in, implement, and evaluate industrial-strength crypto?

Spend 6-8 years breaking it.

(I haven't spent that much time on crypto, and so as a general rule we don't do implementation projects).

I'm going to presume you also by that imply "read all the standard texts, seminal papers, and current state of the art papers".

You'll want to follow people in the industry as well (I've found Nate's blog in particular an enjoyable read). A lot of the practical knowledge accumulates in the brains of the guys who actually get hired to do crypto work. It's an interesting feedback loop to be sure.

Also, it's my impression that start of the art papers aren't really necessary to start off with. The implementation errors people make in their code are flaws that have long been published, sometimes for decades.

Crypto papers actually kind of suck; my experience is that roughly 2/3rds of the time, the complicated formula on the page works out to a "for" loop that would be trivially easy to understand if expressed in algol syntax.

Best advice: do deep research on TLS. For every feature, do a directed search of the literature and do experimentation to try to figure out why that feature is there. Most of the features in TLS exist as a countermeasure to some attack. Follow this tack all the way down the stack, starting with the high-level protocol features and working your way all the way down through the block cipher modes and configuration that it uses.

Yeah there definitely is a bit of an art to reading them. But we can't have cryptographers and security professionals merging too fast... that would just make too much sense. :P

Studying mathematics also helps. Gives you a framework for studying, and contacts to people who are interested in the same field.

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.

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.

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.

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...)

> My advice: don't trust crypto at all outside of TLS, GPG/PGP, and SSH. And know that of those three systems, two were broken relatively recently.

Good advice, but they weren't broken, just mistakes in their implementation.

That is first of all not true, and second of all not relevant. In both cases the cryptosystem itself had a design flaw. And in both cases the implementations of that cryptosystem, aside from the design flaws, had implementation flaws that made the design a moot point.

It is still a good point though. Even using proven protocols, you can still make mistakes in the implementation. Using proven implementations is best.

I took his point to be the opposite: that the worst that seems to happen with cryptosystems is that implementations are broken.

That bugged me on two levels: first, the idea that there haven't been terrible bugs in e.g. SSL3, and second that an implementation bug means "just upgrade OpenSSL", when it's more like "the discovery of buffer overflows and attendant years of chaos".

I am jumpy about this topic, though.

Which two?

All three have had flaws of one sort or another discovered since 2005 (TLS has had several; OpenSSH had the Debian keygen thing and an SSHv1 vulnerabiity, and possibly others; GPG apparently had a couple of problems back in 2006).

TLS has definitely had more severe issues, but then, it's also the most widely deployed (so undiscovered flaws are more likely to be discovered). On the other hand, it's also solving the most complicated problem of the three.

The number and nature of the flaws in TLS actually give me more confidence in it. It's not that other systems don't have similar or worse flaws; it's that these kinds of flaws are a cast iron bitch to find, and TLS is the protocol with the maximum incentive for study.

Give it time; we'll find something horrible out about ISAKMP.