4 ms·

I want to add one other remark: I sympathize with the anxiety you're conveying about implementing this stuff. I used to feel the same way. The Bellare/Rogaway

I want to add one other remark: I sympathize with the anxiety you're conveying about implementing this stuff. I used to feel the same way. The Bellare/Rogaway notes I linked above boosted my confidence a ton. I know perfectly well that protocol XYZ was designed by someone smarter and more experienced than me, whose engineering judgment is better than mine. So what makes me think I have any chance? If you study those notes, you'll understand how cryptographers think, how security proofs work, and how modern protocols (though usually not older ones) are designed so that the proofs come along with them. Instead of having to rely on impossible-to-capture shades of finely tuned judgment, you get actual theorems that are bulletproof. So if you have a reasonable math background, you know what proofs are, you know that if your thing is done right then (against the designed-for threat model) your stuff is secure, and you know what it means for your thing to be done right. So that just leaves executing the latter, which is still the usual error-prone engineering. But good languages and software (look e.g. at Cryptol on galois.com) can help with that too. Most OpenSSL CVE's lately are things like heap overflows rather than crypto misdesign. Coding in Rust is supposed to eliminate those (idk if it always does in practice). I can't prove in a few sentences that this isn't false confidence but I think there is something to it. At the very least, understanding some theory brings a great improvement to one's clarity of thought.

eternityforest 5y ago
Rust is probably a bazillion times safer, but there's always a way to sneak in bugs if you try, and programmers are good at that. It's definitely possible for an individual do this stuff, if it can be mathematically proven(My math level is a bit below grade school algebra so I can't really evaluate it there), proofs don't lie, regardless of who proved them, they are in themselves a way better authority than any human. But anyone who truly does learn all that IS one of those rare crypto experts, and there aren't that many. Who can code review? If someone leaves the team, does anyone else have that level of skill to be able to maintain it? It might be worth learning crypto for the same reason as any of the other random things they say coders should know, like Haskell and LISP or the dreaded FORTH though.
- throwaway81523 5y ago
  Fair enough, it's a specialized area, just like compilers, numerics, machine learning, web front ends, or any amount of other stuff. It's not for everyone. But you don't have to be DJB or Einstein to study it and gain some ability. For that matter, thousands of people every year go to medical school, complete a residency, and become board certified brain surgeons. They're not Einstein either. Crypto implementation isn't nearly as difficult I'm sure. And machine learning is far more mathematically demanding than basic crypto. As for threat models, NaCl and OpenSSL don't magically mitigate against currently unknown threats. Really paranoid crypto is usually wrapped in HSM's (electromagnetically shielded, tamper resistant etc.) in the hope of blocking some of that.
morelisp 5y ago
> (against the designed-for threat model) Yeah, this is the really scary part. It's also the part not amenable proofs. I had to implement some crypto primitives at one point in my career (for a boring combination of legal and technical reasons). Yes, I was nervous, but you pay attention to details and take careful stock of the tools you available (e.g. what's my environment's constant-time comparison function? what's my CSPRNG?) and it's not really harder in the end than implementing lots of other algorithms, you just feel like it is because the stakes are higher. As mentioned many times in this thread, some of the primitives today are also really hard to mis-implement! But those were also part of a system that had to be secure. That was the terrifying part, because our threat models were relatively unique. But this is also the part that developers do all the time without thinking about it - any time you roll a middleware that looks directly at a JWT, or your own web session bootstrapping, or read a regexp from a user, you're committing the same kind of sin. Having a PhD in lattice reduction on-board for that isn't any help. Having security experts helps a lot for this, but when you have them they're not applying any complex math, they're just exceptionally good at getting into a Red Team mindset. tl;dr: If you're debating implementing your own ed25519, you're probably already way too far down the rabbit hole to instead grab libnacl and claim some pride that you didn't "roll your own crypto"; even if you take libnacl at that point you've already made most of the security decisions that will make or break you.
semi 5y ago
Most programmers haven't studied those notes, may not have a reasonable math background, etc. I say that just to point out that your confidence is probably not false, and neither is everyone elses lack of confidence in touching crypto.

eternityforest 5y ago

Rust is probably a bazillion times safer, but there's always a way to sneak in bugs if you try, and programmers are good at that. It's definitely possible for an individual do this stuff, if it can be mathematically proven(My math level is a bit below grade school algebra so I can't really evaluate it there), proofs don't lie, regardless of who proved them, they are in themselves a way better authority than any human. But anyone who truly does learn all that IS one of those rare crypto experts, and there aren't that many. Who can code review? If someone leaves the team, does anyone else have that level of skill to be able to maintain it? It might be worth learning crypto for the same reason as any of the other random things they say coders should know, like Haskell and LISP or the dreaded FORTH though.

throwaway81523 5y ago
Fair enough, it's a specialized area, just like compilers, numerics, machine learning, web front ends, or any amount of other stuff. It's not for everyone. But you don't have to be DJB or Einstein to study it and gain some ability. For that matter, thousands of people every year go to medical school, complete a residency, and become board certified brain surgeons. They're not Einstein either. Crypto implementation isn't nearly as difficult I'm sure. And machine learning is far more mathematically demanding than basic crypto. As for threat models, NaCl and OpenSSL don't magically mitigate against currently unknown threats. Really paranoid crypto is usually wrapped in HSM's (electromagnetically shielded, tamper resistant etc.) in the hope of blocking some of that.

morelisp 5y ago

> (against the designed-for threat model) Yeah, this is the really scary part. It's also the part not amenable proofs. I had to implement some crypto primitives at one point in my career (for a boring combination of legal and technical reasons). Yes, I was nervous, but you pay attention to details and take careful stock of the tools you available (e.g. what's my environment's constant-time comparison function? what's my CSPRNG?) and it's not really harder in the end than implementing lots of other algorithms, you just feel like it is because the stakes are higher. As mentioned many times in this thread, some of the primitives today are also really hard to mis-implement! But those were also part of a system that had to be secure. That was the terrifying part, because our threat models were relatively unique. But this is also the part that developers do all the time without thinking about it - any time you roll a middleware that looks directly at a JWT, or your own web session bootstrapping, or read a regexp from a user, you're committing the same kind of sin. Having a PhD in lattice reduction on-board for that isn't any help. Having security experts helps a lot for this, but when you have them they're not applying any complex math, they're just exceptionally good at getting into a Red Team mindset. tl;dr: If you're debating implementing your own ed25519, you're probably already way too far down the rabbit hole to instead grab libnacl and claim some pride that you didn't "roll your own crypto"; even if you take libnacl at that point you've already made most of the security decisions that will make or break you.

semi 5y ago

Most programmers haven't studied those notes, may not have a reasonable math background, etc. I say that just to point out that your confidence is probably not false, and neither is everyone elses lack of confidence in touching crypto.