5 ms·

I apologize if that sounds dismissive (it's not intended to) but your post is not more than the usual vague FUD. Take a look at so-called 'professional' cryptog

I apologize if that sounds dismissive (it's not intended to) but your post is not more than the usual vague FUD. Take a look at so-called 'professional' cryptographers and their libraries, and you'll find that practically all of their code had severe bugs. Professionals make errors like everyone else, 'professional' just means you're being paid for it. You will have a hard time finding a professional and widely used crypto library that wasn't essentially compromised in one of its functions at one time or another. Not only that, professionals from the closed-source department have a long history of coming up with compromised or bogus, sometimes even ridiculous cryptographic algorithms and implementations. Two typical examples: CMEA cell phone encryption, and the Crypto AG backdoor debacle. Surely people who invent and implement cryptographic algorithms for a living can be expected to be better than your run-off-the-mill programmer, but as I've said elsewhere implementing crypto is also not a black art. It requires about the same level of skill as e.g. implementing a production-ready low-level network protocol or a file system. That rules out many programmers but not all. That concerns implementations. As for algorithms, their development requires extensive experience in cryptanalysis (not just applied cryptography!). Some pros have that, others don't. Last but not least, many popular and widely used crypto libraries started as a side hobby. For example, libtomcrypt started that way. In fact, many widely respected cryptographers started as hobbyists. For example, Bruce Schneier. Of course, the ones who are widely accepted as peers are also those who are in the 'hire me as a consultant, not the other guy' business, and they will naturally advise everyone to not roll their own crypto but to rely on their expertise...

dsacco 9y ago
So I have two points for you: > Take a look at so-called 'professional' cryptographers and their libraries, and you'll find that practically all of their code had severe bugs. Professionals make errors like everyone else, 'professional' just means you're being paid for it. You will have a hard time finding a professional and widely used crypto library that wasn't essentially compromised in one of its functions at one time or another. Not only that, professionals from the closed-source department have a long history of coming up with compromised or bogus, sometimes even ridiculous cryptographic algorithms and implementations. Two typical examples: CMEA cell phone encryption, and the Crypto AG backdoor debacle. This doesn't diminish the claim that the modal individual should not attempt to "roll their own crypto." You're pointing out that professionals make mistakes, but of course they do - that indicates nothing about the propensity for amateurs to make mistakes. > It requires about the same level of skill as e.g. implementing a production-ready low-level network protocol or a file system. I have never implemented a low level network protocol or a file system (although at least the former sounds like a fun project) - so I cannot claim you're wrong here. However, I will point out that a network protocol is not designed to be error-proof in an intentionally antagonistic environment, which is a difficulty unique to cryptographic software. There are incentives involved in breaking crypto code that do not present themselves in other areas of software development, even if the programming difficulty itself is not entirely dissimilar. > Last but not least, many popular and widely used crypto libraries started as a side hobby. For example, libtomcrypt started that way. In fact, many widely respected cryptographers started as hobbyists. For example, Bruce Schneier. Of course, the ones who are widely accepted as peers are also those who are in the 'hire me as a consultant, not the other guy' business, and they will naturally advise everyone to not roll their own crypto but to rely on their expertise... They can start as side hobbies, but they are not going to remain that way for any meaningful amount of time if they are to be widely deployed and safe. You can only choose two out of those three. More importantly, there is no cabal of cryptographers spreading FUD to line their own pockets with consulting fees. The cryptography consulting industry is very small compared to the actual security consulting industry. In the application security consulting industry I do believe there are firms that try to secure business this way, but that industry is much larger (and has firms which try to misrepresent cryptographic competency). I have had significant interactions with engineers at Riscure and NCC Crypto, which is a sizable portion of all the "real" cryptanalytic consulting work that occurs (at least in the United States) - they never struck me as being the sort to suggest what you're saying. That leaves Rambus/CR and a select few other firms doing real crypto consulting, which leads me to believe the industry is, on the whole, very legitimate.
- BlackFingolfin 9y ago
  While I actually mostly agree with you, I feel I need to point this out... You write: > I will point out that a network protocol is not designed to be error-proof in an intentionally antagonistic environment, which is a difficulty unique to cryptographic software. But that's actually not true, at least not anymore. People attack protocols on the internet all the time, and it's a difficult task to harden them against that. That said, it doesn't really take aware from your point, I think; but rather confirms it: Think twice before rolling your own network protocols (at least if they are meant to be used in large scale on the open internet), be aware of all the complicated pitfalls.
- jancsika 9y ago
  > This doesn't diminish the claim that the modal individual should not attempt to "roll their own crypto." Just wanted to point out that "individual-should-not-attempt-to-roll-their-own-crypto" is ambiguous and unnecessarily antagonistic while the paragraph quoted above from Schneier is clear and difficult to argue with. "As simple as possible but no simpler" applies quite well to summaries, esp. when they regard cryptography.
  - dsacco 9y ago
    Okay, what exactly is the claim you'd like me to argue with? That Bruce Schneier was a hobbyist when he developed any of his cryptographic algorithms? He wasn't, and more importantly that misses the point since those algorithms were widely reviewed in competition settings. I'm not sure what you're getting at here. Yes, someone has to develop cryptography, just like someone has to work on designing rockets. Theoretically everyone begins an aspiration as a hobby, but that's pedantic. A cryptographic design or implementation is not going to survive as a side hobby regardless of how it begins.
- loup-vaillant 9y ago
  > a network protocol is not designed to be error-proof in an intentionally antagonistic environment Err, really? That may be the case sometimes. Also these days many things can be antagonistic: anything online is exposed to adversaries. So is anything that routinely reads untrusted input on everyone's computer (like a video player, or a pdf reader). Thinking of the sheer amount of potentially vulnerable code out there makes me a little scared.
ZoFreX 9y ago
As I said I'm not a fan of the phrase "don't roll your own crypto". I don't disagree that that (obviously!) prevents new crypto libraries being written. But if you're going to do it, you damn well do it right, and these days that means an amount of work that would likely total millions of dollars. If you aren't going to do it right, don't cut a 1.0 and use it in production. Sidenote: how we started these things historically is not relevant anymore. We have learned a lot since then. Failing to "stand on the shoulders of giants" and learn from history is one the biggest factors that makes home-rolled crypto so easy to break - they are doomed to repeat the mistakes of history. Mistakes that are nowadays well documented and well known.
marcosdumay 9y ago
The thing that normally nobody says, yet most the people telling you to not roll your own crypto assume you will understand is that you should rely only on well vetted libraries. Rolling a usable crypto library is not a single person endeavor. Your own crypto won't be peer reviewed, thus you should not trust it.
curun1r 9y ago
Having implemented crypto algorithms for educational and enjoyment purposes, I've always looked at "don't roll your own crypto" as less having to do with the actual writing of code which, as you state, isn't really that hard. Instead, what that statement is saying is that when you write your own code, you'll almost never get enough attention from the white-hat community to have any confidence that the code can be used in production. You're right that the code written by professionals has lots of bugs. Bug is a term that describes a problem in code that has been found. With crypto software, the danger isn't the problems that get found (and then addressed), it's the problems that aren't found. "Roll your own" solutions have problems that never get found. That's the danger and it has nothing to do with the skill of the programmer.

dsacco 9y ago

So I have two points for you: > Take a look at so-called 'professional' cryptographers and their libraries, and you'll find that practically all of their code had severe bugs. Professionals make errors like everyone else, 'professional' just means you're being paid for it. You will have a hard time finding a professional and widely used crypto library that wasn't essentially compromised in one of its functions at one time or another. Not only that, professionals from the closed-source department have a long history of coming up with compromised or bogus, sometimes even ridiculous cryptographic algorithms and implementations. Two typical examples: CMEA cell phone encryption, and the Crypto AG backdoor debacle. This doesn't diminish the claim that the modal individual should not attempt to "roll their own crypto." You're pointing out that professionals make mistakes, but of course they do - that indicates nothing about the propensity for amateurs to make mistakes. > It requires about the same level of skill as e.g. implementing a production-ready low-level network protocol or a file system. I have never implemented a low level network protocol or a file system (although at least the former sounds like a fun project) - so I cannot claim you're wrong here. However, I will point out that a network protocol is not designed to be error-proof in an intentionally antagonistic environment, which is a difficulty unique to cryptographic software. There are incentives involved in breaking crypto code that do not present themselves in other areas of software development, even if the programming difficulty itself is not entirely dissimilar. > Last but not least, many popular and widely used crypto libraries started as a side hobby. For example, libtomcrypt started that way. In fact, many widely respected cryptographers started as hobbyists. For example, Bruce Schneier. Of course, the ones who are widely accepted as peers are also those who are in the 'hire me as a consultant, not the other guy' business, and they will naturally advise everyone to not roll their own crypto but to rely on their expertise... They can start as side hobbies, but they are not going to remain that way for any meaningful amount of time if they are to be widely deployed and safe. You can only choose two out of those three. More importantly, there is no cabal of cryptographers spreading FUD to line their own pockets with consulting fees. The cryptography consulting industry is very small compared to the actual security consulting industry. In the application security consulting industry I do believe there are firms that try to secure business this way, but that industry is much larger (and has firms which try to misrepresent cryptographic competency). I have had significant interactions with engineers at Riscure and NCC Crypto, which is a sizable portion of all the "real" cryptanalytic consulting work that occurs (at least in the United States) - they never struck me as being the sort to suggest what you're saying. That leaves Rambus/CR and a select few other firms doing real crypto consulting, which leads me to believe the industry is, on the whole, very legitimate.

BlackFingolfin 9y ago
While I actually mostly agree with you, I feel I need to point this out... You write: > I will point out that a network protocol is not designed to be error-proof in an intentionally antagonistic environment, which is a difficulty unique to cryptographic software. But that's actually not true, at least not anymore. People attack protocols on the internet all the time, and it's a difficult task to harden them against that. That said, it doesn't really take aware from your point, I think; but rather confirms it: Think twice before rolling your own network protocols (at least if they are meant to be used in large scale on the open internet), be aware of all the complicated pitfalls.
jancsika 9y ago
> This doesn't diminish the claim that the modal individual should not attempt to "roll their own crypto." Just wanted to point out that "individual-should-not-attempt-to-roll-their-own-crypto" is ambiguous and unnecessarily antagonistic while the paragraph quoted above from Schneier is clear and difficult to argue with. "As simple as possible but no simpler" applies quite well to summaries, esp. when they regard cryptography.
- dsacco 9y ago
  Okay, what exactly is the claim you'd like me to argue with? That Bruce Schneier was a hobbyist when he developed any of his cryptographic algorithms? He wasn't, and more importantly that misses the point since those algorithms were widely reviewed in competition settings. I'm not sure what you're getting at here. Yes, someone has to develop cryptography, just like someone has to work on designing rockets. Theoretically everyone begins an aspiration as a hobby, but that's pedantic. A cryptographic design or implementation is not going to survive as a side hobby regardless of how it begins.
loup-vaillant 9y ago
> a network protocol is not designed to be error-proof in an intentionally antagonistic environment Err, really? That may be the case sometimes. Also these days many things can be antagonistic: anything online is exposed to adversaries. So is anything that routinely reads untrusted input on everyone's computer (like a video player, or a pdf reader). Thinking of the sheer amount of potentially vulnerable code out there makes me a little scared.

ZoFreX 9y ago

As I said I'm not a fan of the phrase "don't roll your own crypto". I don't disagree that that (obviously!) prevents new crypto libraries being written. But if you're going to do it, you damn well do it right, and these days that means an amount of work that would likely total millions of dollars. If you aren't going to do it right, don't cut a 1.0 and use it in production. Sidenote: how we started these things historically is not relevant anymore. We have learned a lot since then. Failing to "stand on the shoulders of giants" and learn from history is one the biggest factors that makes home-rolled crypto so easy to break - they are doomed to repeat the mistakes of history. Mistakes that are nowadays well documented and well known.

marcosdumay 9y ago

The thing that normally nobody says, yet most the people telling you to not roll your own crypto assume you will understand is that you should rely only on well vetted libraries. Rolling a usable crypto library is not a single person endeavor. Your own crypto won't be peer reviewed, thus you should not trust it.

curun1r 9y ago

Having implemented crypto algorithms for educational and enjoyment purposes, I've always looked at "don't roll your own crypto" as less having to do with the actual writing of code which, as you state, isn't really that hard. Instead, what that statement is saying is that when you write your own code, you'll almost never get enough attention from the white-hat community to have any confidence that the code can be used in production. You're right that the code written by professionals has lots of bugs. Bug is a term that describes a problem in code that has been found. With crypto software, the danger isn't the problems that get found (and then addressed), it's the problems that aren't found. "Roll your own" solutions have problems that never get found. That's the danger and it has nothing to do with the skill of the programmer.