|
|
|
|
|
|
by pvg
2942 days ago
|
|
|
Maybe I'm not following something but it seems to me you're saying an understanding of the mathematical properties of the primitives invariably leads to their secure implementation, combination and deployment. On its face, this is demonstrably untrue. From there, I just have to make sure a number of mathematical properties are followed, and voilà I have a secure system Or, et voilà, you have SSL. |
|
|
Then all I have to do is weed out the bugs. It's not trivial, but it is pretty simple. Thanks to all primitives being constant time, the memory access patterns are identical for every input of the same length. Test all the lengths from zero to some threshold, and you pretty much test all the code paths. Then you sanitise the hell out of the code, because this is Unsafe™ C we're talking about, and then you have a secure crypto library. Extend that philosophy to the entire system, and you're good to go.
Now let's say I did invent something. I was close to such invention when I implemented XChacha20 from first principles (that is, from reading the XSalsa20 paper, and doing the same to Chacha20). Making sure the "invention" was sound just required I understood the relevant maths, which in this case wasn't complicated at all (it's basically "reveal only the bytes the attacker could have guessed anyway").
The same apply when one designs a protocol. One must be aware of the relevant properties the protocol must achieve, and understand the maths required to ensure those properties. Once that's figured out, it's just a matter of not screwing up the implementation.
Crypto is often underestimated, leading to horrible security issues. But I think it is also often overestimated, that with "don't touch it unless Bruce Shneier said you could" or something. Really, applying crypto is not hard. A couple weeks of full time learning is more than enough.
[1]: https://monocypher.org