Why I don't touch crypto

...a system for which there is no security definition, no security proof, a known polynomial time attack (for some vague notion of "attack"), etc. I do not think this is the best example you can come up with.

One of the problems here is that cryptography cannot just be cobbled together from component pieces. Things do not always compose securely. Bitcoin is not a signature system, so even if the ECDSA implementation is perfect it does not guarantee that Bitcoin is secure. One of the things that makes cryptography, especially in the public-key setting, difficult is the very precise assumptions and very precise definitions of security; it is easy to make an assumption that is not implied by a security definition, and very easy to violate a key assumption without even realizing it. Worse, cryptosystems must be composed with other software, and such compositions can be insecure (which is basically what happened with Skype).

It's not that people should be scared away. Rather, we need to develop better tools that help programmers catch or avoid these kinds of bugs.

Don't get me wrong I am a huge Debian fanboy, but how much crypto code do Debian developers write?

The methods described in _Applied Cryptography_ are unfortunately well-tried, but few of them are true. _Applied_ is an almanac of cryptographic concepts. Where _Practical_ tries hard to present best practices at every point in the book, _Applied_ instead strives for the broadest coverage; it's a survey, not an instruction guide. Unfortunately for all of us, ~20 years of _Applied_ readers have tried to put directly into practice the material in that book, much of which is (relevant to modern standards) half-baked.

It's also important to know that _Practical_ is also showing its age. There are very common, very serious vulnerabilities that _Practical_ does very little to prevent. For instance, "Design Rule 4" in _Practical_, "The Horton Principle", implies that message authentication should precede encryption. This construction is now disfavored; protocols that use mac-then-encrypt have been broken with side channels abetted by attacker chosen ciphertext.

Other concepts missing from _Practical_: elliptic curve --- particularly given endangered status of RSA, which would be a nit if not for the extremely detailed coverage Schneier gives to more theoretical threats to AES, (EC)DSA parameter tampering, the notion of minimizing randomness from cryptosystems, the modern AE modes, an in-depth treatment of side channels (where "in-depth" might mean "at least as much coverage as is given to the question of what block cipher mode to use") --- particularly error oracles, applications of hash collisions, RSA message formatting (it doesn't even cover OAEP), and secure key derivation.

I write this from a place of love; _Practical Cryptography_ is one of my all-time favorite software security books. It's one of those books you can "read backwards" to learn how to break systems in addition to learning how to build them. With age, though, _Practical_ is becoming more useful as a breaker's guide and less and a builder's guide.

There is no book anywhere that a generalist developer can read to learn how to build a secure cryptosystem from scratch, and generalist developers should be relying instead on high-level libraries like Keyczar and Nacl.

I don't know a think about Satoshi's competence (I couldn't, because nobody knows who he is), but Moxie Marlinspike has spent over 15 years building his competence. If you're Moxie, build whatever you want.

Really important to know how to be safe and what to look out for. I wasn't getting the feeling that many infosec professionals on HN were able/willing to outline reasonable guidelines for experienced devs/admins to follow.

It is possible to learn it but learn it first and ship it to the public later or if you must with great big experiment/insecure warnings all over it.

Result is SHA3 full disk for Android. Its certainly not foolproof or nor do I claim its secure but a lot of people are digging through the source and forensics hackers are interested in seeing what they can do with it. I realize I broke cardinal rule of using something that hasn't been proven for decades first (like AES 256) but its been a good learning experience thats for sure.

I'm a reasonably competent home mechanic. I happily rebuild engines and gearboxes for cars and motorcycles at home. I can modify and tune engines. I easily do all my households vehicle maintenance. And I happily help friends out with their repairs and maintenance. One thing I won't do though, is fix a friends brakes. I'm happy working on my own brakes, and happy to accept the responsibility for my actions. I won't take hat responsibility on for friends though. If you're not happy/capable of fixing your own brakes, take it to someone qualified and insured.

I think crypto is the same. There's nothing wrong with learning about and writing your own crypto as a curious amateur. But deploying that crypto where it can get other people killed is a bigger deal. Don't be "the cryptocat guy", "Oh yeah, I just found out you can't use water for brake fluid, turns out it boils when it gets hot! Who knew? Anyway, I just put brake fluid in my brakes, you should probably upgrade yours too sometime…"

I think if you want to _deploy_ crypto to other people, you owe it to yourself to have at least as much "professional training" as an auto mechanic gets before they're allowed to repair your brakes. And to further stretch the analogy - I'll point out tha most mechanics these days don't "repair" much in brake systems, they'll just replace large components - its becoming more common to not be able to buy seals and pistons any more - you're expected to just replace entire calipers or master cylinders. In my head that's the same approach as saying "I'll choose to use GPG or OpenSSL, but I won't 'do my own crypto'" - for someone who's _not_ prepared to put in a few hundred hours of proper crypto training, I think "rolling your own crypto software" is something best left to personal/educational projects, and never deployed I a way that other people might rely upon it.

The problem I think the author is highlighting is that the mistake risk distribution is hard to understand. Some kinds of off by one errors may cause relatively small reductions in security margins. Some kinds may cause complete loss of system integrity. It's hard to distinguish between the two without extensive testing and expertise. Furthermore, the kind of user who would never tell you about your error is exactly the kind who will find it.

Finally, loss of your security infrastructure is unlikely to cause just small visual discomfort to your users—it's likely to hurt them materially.

The problem with crypto is that it's a specialist profession that generalists think they can do. In reality, crypto is more like law than software engineering: You can't just reason it from first principles, and you can't write any tests that will tell you that it's working. You have to know the specific attacks that people are capable of, and come up with a strategy that will avoid not only the current attacks that you know about, but future attacks that haven't been discovered yet. You're tasked with building a system of obstacles that nobody will be able to find any clever workarounds for, and your adversaries are smarter than you, more numerous than you, more well-funded than you, they're experts in breaking crypto, and they're all from the future.

That's not something a handful of engineers working in isolation can do. It takes the whole community years to even come close.

Saying that software engineers can design crypto protocols is like saying that software engineers can be their own lawyers. A few can, but almost all engineers who think they know the law are wrong. Even lawyers routinely lose cases. The best we can do is to try to give them better tools to handle the common cases (e.g. Creative Commons, SSH, better APIs), and remind them to talk to the specialists before getting too creative.

Compare and contrast.

We shouldn't, but we should provide tools that allow software engineers to securely design applications without having to be crypto experts, in much the same way I can write python code without being a kernel hacker. Two examples spring to mind: Authenticated https api calls and bcrypt. These both work securely without requiring deep knowledge and they are so easy to setup it is unlikely someone will roll their own.

One of the problems is with security and crypto is that the people who really understand it make fairly weak promises such as that it is "Pretty Good Privacy" but the incompetent, greedy or malicious make strong marketing claims about the security that they are offering. Emphasis on incompetent in the Cryptocat case.

Crypto is an area where the Dunning Kruger effect[1] seems both especially strong and especially dangerous.

[1] http://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect

It does not follow from that sentiment that anyone should be able to jump into the cockpit of a Cessna and just figure things out for themselves.

Not if 'nothing' is "don't send the message", rather than the "send the message in the clear" that you're assuming.

Bad crypto gives end users false confidence in the security of their messages. They then send messages they normally wouldn't, and suffer the consequences when those messages end up being read by others.

Amateurs can play with crypto all they like for fun, but they have no business releasing a product to end users.

I'm not an expert, but I wouldn't look at an OTP implementation either. Key management is already hard enough. It's hard to imagine a useful system you could build on a one-time pad.

If we were talking instead about people operating their own pharmacies, or doing their own home electrical work, nobody would bat an eyelash.

Actually, most problems are at the security protocol level. Implementing those is the hardest.

I'm reminded of Yeats:

        The best lack all conviction, while the worst
        Are full of passionate intensity.

So we're in a situation where we have to make imperfect choices. Is there any reliable guide that discusses the current best practices in securing things like ssh, VPN, etc?

I get the feeling that the preference of many of the infosec professionals on HN is that a properly configured SSH tunnel is the only secure way to communicate between machines on the Internet. ( IPSec VPN connections I guess are weaker?) So just use stunnel or autotunnel? Tunneling traffic imo seems like an inelegant hack, but are there any crypto libraries that are reliable?

Crypto is hard, but to be fair it's also not easy to figure out what crypto to use if you want to rely on external libraries or systems like SSH.

At least with cryptocat everyone know knows about the security issues now and take precautions as if their entire encrypted communications have been compromised. With proprietary solutions you have to rely on an honor system where you hope the vendor tells you there is an issue.

The problem is that it's really hard to write unit tests to determine if you've gotten the crypto right. For one, the unit tests would have to have a standardized interface to your cryptographic protocol. But if you're using a standard cryptographic protocol, why would you be rolling your own implementation instead of using an existing, well tested and vetted one?

Second, it's quite difficult, in an automated way, to look for the kinds of security vulnerabilities you would need to audit. Timing attacks may show up in different places for different software. Poorly seeded entropy is quite hard to detect; Debian systems were generating keys with only about 16 bits of entropy for years, which is enough that it's hard to detect in an automated way unless you are really looking for that specific breakage but is a devastating security hole. You may have bugs that are not crypto related at all but simple buffer overflows or the like. And so on.

You could probably automate some of it. But on the whole, you need many good, experienced people regularly auditing the code. And it's a lot easier to get that by using an existing, widely used and widely audited library than by rolling your own.

However these are just statistical tests; they tell you nothing about how much actual entropy you're actually getting (cf. Debian). That said, it probably would have caught the Cryptocat bias.

Also, a lot of the time the vulnerabilities are not in primitives like PRNGs, but in how application programmers combine the primitives in their application, and there's no way to unit test the security of that. The way to mitigate this is by developing and using high level library interfaces that make it very difficult to screw up.

At the moment, the only "correct" test I know of is hilariously impractical: enumerate all possible programs up to a reasonable length, run those programs against output from the random number generator for a few minutes each, and see if they're better than chance at recovering the seed you used.

Spend a long time in the community. Listen closely to the people who have a good reputation. Have your code publicly vetted before it's ever used. Expect your code to be torn apart.

Even if it was -- how do you unit-test a PRNG to ensure the output is uniformly random? How do you ensure you don't have collisions in a hash function? How can you ensure that there's no replay attack on your protocol? How can you use unit-testing to demonstrate that there is no hole in your protocol like, say, when the Germans repeated the key twice at the beginning of the message while using Enigma?

These are all very real and valid cryptography concerns. Sorry if this sounds snarky, but in all seriousness -- I'm very curious as to how you would unit-test these.