8 ms·

What kind of maniac would implement a crypto algorithm in production themselves, unless their last name is something like Schnier or Bernstein?

throwaway81523 5y ago
I've done it and feel ok about it. Others here have done it and done a good job. But yeah, there are different levels you can work at, you always have to be careful, and you have to know some theory in order to be able to even think clearly about the topic. I found Bellare and Rogaway's old lecture notes[0] demystified the subject for me a lot. There are some actual textbooks now that are more up to date and complete, though I don't happen to know of titles offhand. For ECC with NIST curves, Menezes, Vanstone, et al have a book that gives very explicit step by step implementation instructions. [0] https://web.cs.ucdavis.edu/~rogaway/classes/227/spring05/book/main.pdf https://web.cs.ucdavis.edu/~rogaway/classes/227/spring05/boo...
- eternityforest 5y ago
  Any particular reason you'd ever do this? Obviously it kinda makes sense as a hobby project never used for something important... but in production?
  - throwaway81523 5y ago
    I don't understand the question. Code has to come from somewhere, and there's not always a pre-written library you can use. That's what keeps programmers employed. Crypto primitives are actually not that dangerous to implement, since there will usually be test vectors and/or other implementations you can check against. You get in trouble if you try to develop your own protocols, make mistakes with parameter selection, and that sort of thing. Added: Here is some code that needs to be written, if it hasn't been already: * TLS stack written in Rust, so we don't have to keep using the legacy OpenSSL stack. Or similarly, in Ada. * SSH stack, same same. * High speed primitives in RISC-V assembly language, in multiple versions optimized for different architecture implementations * Lots of weird special primitives used in things like old fashioned payment protocols. I dealt with this somewhat when working on POS terminals. * Hardware implementations in VHDL and Verilog * Etc. I'd feel comfortable working on the first two of the above. Someone has to do it, and we can't always get DJB to do everything, so that leaves people like us.
    - eternityforest 5y ago
      The weird special primitives definitely makes sense. Not much you can do when you've got a legacy system. Still, as much as I think C/C++ are garbage languages, I'd rather have OpenSSL than any alternative that didn't have review by security specialists. Some fraction of general programmers may also have that kind of experience, but it's like handymen doing plumbing. Some unlicensed people have the skills, but if you yourself don't know the subtle pitfalls of plumbing, how can you evaluate their work? I don't know what side channel attacks are possible and what ones aren't. I don't know what instructions have hidden power analysis attack implications. I could study for months, and try to learn those things, but I could also just use OpenSSL, since it's free. Less effort AND probably safer. The specialists will get to the Rust redo eventually, I'd rather let them handle it, just like they'd probably rather let me fuss with boring web UI framework version upgrade issues.
      - throwaway81523 5y ago
        Obviously the Rust (etc.) stack would have to be reviewed in beta for a while before being declared ready for prime time (no pun intended). The OpenSSL primitives don't try to defeat power analysis as far as I know (that's more for smart cards and HSM's), and they mostly don't try to defeat timing analysis (e.g. the DES and AES implementations use lookup tables). On the other hand with DJB's primitives, it's harder to get that wrong. This is for symmetric crypto: public-key is more complicated. Part of the reason C programs need such intense review and shakedown is that C itself is so hazardous. When you write in better languages, issues tend to settle out faster. I don't claim to be a major crypto wizard like DJB, but I've been at it a while, have been in the industry, know other implementers shipping significant products and can see that they do the same type of stuff that I do. The big brains in the field are e.g. mathematicians designing primitives. Merely implementing them is just engineering and following specs and standards. It's much less big of a deal.
      - throwaway81523 5y ago
        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.
- CuriousCosmic 5y ago
  Why would you do such a thing? There's very few good reasons to. The only ones I can think of are: 1. Writing a HW crypto module in an HDL like Verilog or VHDL where one doesn't exist or you don't have access to it. 2. Adding support for a given algorithm on an architecture or platform where none of the other implementations will work (due to either arch differences, memory/cpu constraints, exotic HW, etc). I can't think of why you'd write such a thing and put it in production otherwise. It's just too expensive to get wrong IMHO however I'd love to be proven wrong.
morelisp 5y ago
All of modern cryptographic development is in the hands of just one political talking head and one enabler of a serial rapist? Man, we are doomed.
- eternityforest 5y ago
  I mean "We're doomed" does seem to be the main point of 80% of articles on security these days... I'm not sure what serial rapist thing you're referring to, I assume Appelbaum's connection to DJB? I hadn't heard of that one, and that is in fact highly disgusting. And especially disturbing considering the fact that anyone involved woth security or privacy tends to think of themselves as some kind of hero of global freedom... and then to do that... I still definitely wouldn't trust crypto done by a nonspecialist, but it does seem like the specialist community has problems.
  - morelisp 5y ago
    My point is, there's dozens and maybe hundreds of people responsible for implementing the cryptographic primitives across the software you use. Keep in mind e.g. Schneier was primarily a writer and teacher - and keep in mind most of the primitives he designed are not in common use! - and Bernstein was more practically-minded but... idiosyncratic about software development practices at best. You're probably not running much code directly from them, not even some kind of small-but-critical component. Then there's hundreds and maybe thousands responsible for implementing cryptographic systems and protocols using those primitives. Most of them could also implement such primitives correctly with a little more effort, and many of them will do a better job making these systems practically safe than the first group would have. And there's another large group who need to learn how to do this, because relying on a cadre of curmudgeonly aging white men, several already of extremely dubious moral character, isn't exactly a sustainable strategy for software development. You don't know most of their names. They do mostly fine work. Please, end this rockstar shit.
    - eternityforest 5y ago
      I'm not saying that only people like Bernstein can do software, and in fact I wouldn't touch his way-too-close-to-suckless application level stuff at all, but I am obviously going to trust security specialists more than anyone else. There are hundreds and thousands of them, sure, and I don't know their names, but they're still security professionals. You may well be every bit as good as them. But I have no way to verify this. If I used code from someone not well known I would have no way to justify it. Even if I taught myself crypto(Which I wouldn't really consider the best time investment), I could be lying just like you could. Someone else on the team would need to deeply understand it to review it. But in reality most people would probably either just rubber stamp it or say "Go use libnacl instead". Protestware has shown the social process of trust isn't perfect, but it's all we have unless we get a crypto expert on every team. I'm not particularly privacy conscious. I don't have a separate network for IoT. Using primitives developed by specialists is just a very easy low hanging fruit. People of dubious character is... just software development in general really. It's even worse in other areas of software. With crypto at least you have the option to implement it yourself, for better or worse, with large applications you just physically can't unless you want to spend years on it. But there's still people like Lenore Blum though, it's not all men, and I don't know of any nastiness she's perpetrated. Until people stop writing vulnerable code, it's pretty hard to believe anyone who says their code is safe without tons of auditing.

throwaway81523 5y ago

I've done it and feel ok about it. Others here have done it and done a good job. But yeah, there are different levels you can work at, you always have to be careful, and you have to know some theory in order to be able to even think clearly about the topic. I found Bellare and Rogaway's old lecture notes[0] demystified the subject for me a lot. There are some actual textbooks now that are more up to date and complete, though I don't happen to know of titles offhand. For ECC with NIST curves, Menezes, Vanstone, et al have a book that gives very explicit step by step implementation instructions. [0] https://web.cs.ucdavis.edu/~rogaway/classes/227/spring05/book/main.pdf https://web.cs.ucdavis.edu/~rogaway/classes/227/spring05/boo...

eternityforest 5y ago
Any particular reason you'd ever do this? Obviously it kinda makes sense as a hobby project never used for something important... but in production?
- throwaway81523 5y ago
  I don't understand the question. Code has to come from somewhere, and there's not always a pre-written library you can use. That's what keeps programmers employed. Crypto primitives are actually not that dangerous to implement, since there will usually be test vectors and/or other implementations you can check against. You get in trouble if you try to develop your own protocols, make mistakes with parameter selection, and that sort of thing. Added: Here is some code that needs to be written, if it hasn't been already: * TLS stack written in Rust, so we don't have to keep using the legacy OpenSSL stack. Or similarly, in Ada. * SSH stack, same same. * High speed primitives in RISC-V assembly language, in multiple versions optimized for different architecture implementations * Lots of weird special primitives used in things like old fashioned payment protocols. I dealt with this somewhat when working on POS terminals. * Hardware implementations in VHDL and Verilog * Etc. I'd feel comfortable working on the first two of the above. Someone has to do it, and we can't always get DJB to do everything, so that leaves people like us.
  - eternityforest 5y ago
    The weird special primitives definitely makes sense. Not much you can do when you've got a legacy system. Still, as much as I think C/C++ are garbage languages, I'd rather have OpenSSL than any alternative that didn't have review by security specialists. Some fraction of general programmers may also have that kind of experience, but it's like handymen doing plumbing. Some unlicensed people have the skills, but if you yourself don't know the subtle pitfalls of plumbing, how can you evaluate their work? I don't know what side channel attacks are possible and what ones aren't. I don't know what instructions have hidden power analysis attack implications. I could study for months, and try to learn those things, but I could also just use OpenSSL, since it's free. Less effort AND probably safer. The specialists will get to the Rust redo eventually, I'd rather let them handle it, just like they'd probably rather let me fuss with boring web UI framework version upgrade issues.
    - throwaway81523 5y ago
      Obviously the Rust (etc.) stack would have to be reviewed in beta for a while before being declared ready for prime time (no pun intended). The OpenSSL primitives don't try to defeat power analysis as far as I know (that's more for smart cards and HSM's), and they mostly don't try to defeat timing analysis (e.g. the DES and AES implementations use lookup tables). On the other hand with DJB's primitives, it's harder to get that wrong. This is for symmetric crypto: public-key is more complicated. Part of the reason C programs need such intense review and shakedown is that C itself is so hazardous. When you write in better languages, issues tend to settle out faster. I don't claim to be a major crypto wizard like DJB, but I've been at it a while, have been in the industry, know other implementers shipping significant products and can see that they do the same type of stuff that I do. The big brains in the field are e.g. mathematicians designing primitives. Merely implementing them is just engineering and following specs and standards. It's much less big of a deal.
    - throwaway81523 5y ago
      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.
CuriousCosmic 5y ago
Why would you do such a thing? There's very few good reasons to. The only ones I can think of are: 1. Writing a HW crypto module in an HDL like Verilog or VHDL where one doesn't exist or you don't have access to it. 2. Adding support for a given algorithm on an architecture or platform where none of the other implementations will work (due to either arch differences, memory/cpu constraints, exotic HW, etc). I can't think of why you'd write such a thing and put it in production otherwise. It's just too expensive to get wrong IMHO however I'd love to be proven wrong.

morelisp 5y ago

All of modern cryptographic development is in the hands of just one political talking head and one enabler of a serial rapist? Man, we are doomed.

eternityforest 5y ago
I mean "We're doomed" does seem to be the main point of 80% of articles on security these days... I'm not sure what serial rapist thing you're referring to, I assume Appelbaum's connection to DJB? I hadn't heard of that one, and that is in fact highly disgusting. And especially disturbing considering the fact that anyone involved woth security or privacy tends to think of themselves as some kind of hero of global freedom... and then to do that... I still definitely wouldn't trust crypto done by a nonspecialist, but it does seem like the specialist community has problems.
- morelisp 5y ago
  My point is, there's dozens and maybe hundreds of people responsible for implementing the cryptographic primitives across the software you use. Keep in mind e.g. Schneier was primarily a writer and teacher - and keep in mind most of the primitives he designed are not in common use! - and Bernstein was more practically-minded but... idiosyncratic about software development practices at best. You're probably not running much code directly from them, not even some kind of small-but-critical component. Then there's hundreds and maybe thousands responsible for implementing cryptographic systems and protocols using those primitives. Most of them could also implement such primitives correctly with a little more effort, and many of them will do a better job making these systems practically safe than the first group would have. And there's another large group who need to learn how to do this, because relying on a cadre of curmudgeonly aging white men, several already of extremely dubious moral character, isn't exactly a sustainable strategy for software development. You don't know most of their names. They do mostly fine work. Please, end this rockstar shit.
  - eternityforest 5y ago
    I'm not saying that only people like Bernstein can do software, and in fact I wouldn't touch his way-too-close-to-suckless application level stuff at all, but I am obviously going to trust security specialists more than anyone else. There are hundreds and thousands of them, sure, and I don't know their names, but they're still security professionals. You may well be every bit as good as them. But I have no way to verify this. If I used code from someone not well known I would have no way to justify it. Even if I taught myself crypto(Which I wouldn't really consider the best time investment), I could be lying just like you could. Someone else on the team would need to deeply understand it to review it. But in reality most people would probably either just rubber stamp it or say "Go use libnacl instead". Protestware has shown the social process of trust isn't perfect, but it's all we have unless we get a crypto expert on every team. I'm not particularly privacy conscious. I don't have a separate network for IoT. Using primitives developed by specialists is just a very easy low hanging fruit. People of dubious character is... just software development in general really. It's even worse in other areas of software. With crypto at least you have the option to implement it yourself, for better or worse, with large applications you just physically can't unless you want to spend years on it. But there's still people like Lenore Blum though, it's not all men, and I don't know of any nastiness she's perpetrated. Until people stop writing vulnerable code, it's pretty hard to believe anyone who says their code is safe without tons of auditing.