> Crypto is hard, but it's no harder than a lot of other hard things.
Crypto is a LOT harder than some other things.
3d graphics programmers don't have to worry about side channel attacks through timing disclosures through random numbers returned over an HTTP GET.
Physics simulations don't have to worry about tens to hundreds of millions of dollars of losses because Intel changed the L2 cache slightly in some revision of a processor and now it is possible to glean a couple bits of information about the entropy one uses.
Of all the projects I have worked on, maybe the C/C++ compiler had a set of worries close to what an encryption suite has.
You could toss me into almost any field of software engineering and after a few months I'd feel good. Some of them would have a longer ramp up time (order of months). Some of them might require me to go take a few online courses to learn the field (3D, physics sims, etc).
Encryption requires an entire life of devotion. New attacks are coming out all the time. There is so much financial incentive in the field that the competition is insanely fierce.
3D graphic techniques get pushed forward by publishers wanting the latest AAA game title.
Encryption gets pushed forward because they are trying to outrun either large international criminal organizations or entire governments.
You're right, though there are some things that are about as hard: compilers, language design, machine learning, databases with strong ACID guarantees, etc.
The problem I have with the "crypto should be a forbidden zone" line of reasoning is that the real world evidence shows that the old battle tested systems manifest flaws at least as often as competently designed newer systems do. Crypto, it turns out, is so hard that the probability of lurking issues with mature systems approaches or exceeds the probability of mistakes in new ones.
When I say competently designed, I mean a newer system that passes the sniff tests of experienced crypto engineers. An incomplete list: they're using a cipher that's been peer reviewed and is considered strong by modern standards, they're using that cipher correctly, they're authenticating before doing anything, they are using an IV (if needed), they are not sending anything secret in the clear, they're not branching on secret data, etc.
It's also important to refrain from criticizing people for claims they are not making. As far as I know, Weave is not claiming to implement the entire feature set of IPSec. They're just claiming to offer basic but strong crypto and authentication. If you want more, you are likely using other algorithms like SSL and SSH over the overlay network.
Yes, that comes with a performance penalty, but it's also defense in depth. It's better to trust multiple layers of crypto with independent implementations at each layer so that a compromise of one does not destroy your entire security posture.
It all comes down to the question of how paranoid you are. No encryption will give you the best performance, but no security. If you want maximums security you can run SSL over IPSec over Weave with different sets of keys and different ciphers at each level. Bonus points for generating those keys on different air-gapped hardware, etc.
> compilers, language design, machine learning, databases with strong ACID guarantees, etc.
Compiler design isn't that hard. A perfect optimizing compiler is damn nearly impossible, but good enough is easy. LLVM makes good enough compilers pretty easy, see the number of new languages that get posted to HN every month!
Machine Learning is hard to do right for non-trivial cases, but the only risk is you waste your investor's money and your customer's time, you don't risk identity theft (unless you are using machine learning to write crypto code maybe? :) )
Databases, yeah, everyone screws those up.
The real key is how many people are trying to break your system though. Crypto is exposed, your DB layer can have protections put on it to sanitize your data and rate limit how fast stuff comes in. You can clean up the data that goes into your machine learning algorithm (or use one that is resilient to x% of malicious data).
None of those defenses depend upon defending attacks of context switch timing in the CPU leaking data from a CPU that was releases 2 years after your code shipped through QA!
(and yes new CPU designs can cause problems in any code! But Intel and AMD work hard to avoid the major cases!)
Crypto is a LOT harder than some other things.
3d graphics programmers don't have to worry about side channel attacks through timing disclosures through random numbers returned over an HTTP GET.
Physics simulations don't have to worry about tens to hundreds of millions of dollars of losses because Intel changed the L2 cache slightly in some revision of a processor and now it is possible to glean a couple bits of information about the entropy one uses.
Of all the projects I have worked on, maybe the C/C++ compiler had a set of worries close to what an encryption suite has.
You could toss me into almost any field of software engineering and after a few months I'd feel good. Some of them would have a longer ramp up time (order of months). Some of them might require me to go take a few online courses to learn the field (3D, physics sims, etc).
Encryption requires an entire life of devotion. New attacks are coming out all the time. There is so much financial incentive in the field that the competition is insanely fierce.
3D graphic techniques get pushed forward by publishers wanting the latest AAA game title.
Encryption gets pushed forward because they are trying to outrun either large international criminal organizations or entire governments.