6 ms·

I still believe it's a bad idea to roll your own crypto, interesting as an exercise, but I would never use it in a production environment.

merb 9y ago
well if you have enough people especially working with crypto, than why not? It's not like that the existing solutions came out of nowhere. some people actually wrote them. I mean libsodium is actually really simple to use. however before libsodium it was probably easier and mostly more correct to roll your own. there are so many things you can do wrong with other libraries that the chance to do it wrong is as high as in your own implementation.
timclark 9y ago
How will cryptography libraries ever develop if someone doesn't roll their own?
- rootlocus 9y ago
  Through sweat and blood. Don't expect crypto libraries to be secure the first few years after their release. That's why people favor the mature, battle-tested libraries.
  - jwl 9y ago
    But then again, we still got Heartbleed.
    - bananaboy 9y ago
      Yeah and imagine the kind of exciting bugs that exist in new and immature libraries! :)
      - jwl 9y ago
        Yes, but are hackers going after common used libraries to get more vulnerable systems to attack or are they going to spend time on some unknown homebuilt crypto? In some cases, security through obscurity works well in practice.
        ZoFreX 9y ago
        > In some cases, security through obscurity works well in practice. This is not one of those cases. Absolutely not. I'm moderately competent at finding security bugs in things, but I doubt I could find any in OpenSSL. I am confident I could find some in your average hand-rolled code. The thing is people make the same mistakes. There's a set of well-known mistakes that are very easy to make, especially if you're not versed with the entire history of implementing crypto - which is the case for the majority of people rolling their own. This makes it very, very easy to guess what mistakes they will make, and if you know what you're looking for it's easy to find it. My "personal best" for finding a crypto bug in a project is 50 seconds. I doubt anyone has found a bug in OpenSSL (or any established crypto project) anywhere near that fast.
        jwl 9y ago
        You got to consider your most likely risk for attack. Targeted or at random by a botnet? For example, you are most likely more secure in practice by writing your own website than using Wordpress, simply because you are more likely to get hit by a botnet targeting every Wordpress site than someone going directly for you.
        ZoFreX 9y ago
        This is off-topic. We are talking about security vs obscurity in the context of cryptography libraries.
        palunon 9y ago
        Replace WordPress with OpenSSL and website with crypto.
- baby 9y ago
  tbh, they do develop like this. Some guy come up with a library, a lot of critics arise, but the guy pushes through and many years later it becomes somehow a reference when someone big on twitter mentions it as his/her favorite crypto library.
cyphar 9y ago
Interestingly it looks like there was a bug in every Argon2 implementation specifically because everyone just used the reference implementation. Personally, I think the intention of the phrase "don't roll your own crypto" was lost over time. It was advice to companies to use standard cryptographic algorithms rather than everyone coming up with their own thing for no good reason. It doesn't mean that only some blessed individuals should be allowed to write cryptographic software. I think OpenSSL has taught us that not rolling your own crypto results in a monoculture of self-professed experts that didn't follow that advice.
- laumars 9y ago
  Those are two separate arguments. Of course there should be competition in crypto libraries. However the "don't roll your own" advice is to prevent people who don't have sufficient experience, education nor resources to write their own library that can compete - effectively leaving their systems vulnerable. The thing about the "don't roll your own" advice is it's aimed at people who don't competently know what they're doing rather than those who do.
  - cyphar 9y ago
    How do you expect people to become competent if you constantly tell them to not do something? All that will happen is that people who don't listen to warnings will write crypto libraries and everyone will be forced to use them because nobody else wrote one. The fact that there was no independent implementation of Argon2 that found there was a bug in the reference implementation shows that the "don't roll your own" advice is discouraging competition in crypto libraries to the point where the reference implementation wasn't sufficiently verified to produce correct output.
    - laumars 9y ago
      Again I feel the need to reiterate that the rule only needs to apply to those it needs explaining to. Ie nobody who is smart enough to roll their library would not do so for a production system without it having undergone rigorous testing first. Sure we might write hobby projects (I've written my own encryption ciphers for fun) but that's very different from actually using said cipher on live and/or business critical systems. Simply put, the rule is there to remind people that rolling your own crypto libraries is dangerous. It's not meant to be taken literally to the daft extremes that yourself and a few others on here have. It's just meant to stop those lacking common sense from leaving themselves vulnerable.
baby 9y ago
There is a difference between rolling your own crypto and rolling your own crypto. There is Monocypher, then there is this company that is trying to do some weird protocol using CRC, DES in CBC mode and MD5. The sentence was targeting the latter case.
- ewanm89 9y ago
  No, it is targeting both. I see no mention of how monocypher implementation does anything 5o prevent side channel timing attacks, I haven't looked to see if there is any sensitive memory scrubbing. Of the bugs listed most are performance bugs by someone who doesn't know C very well yet have they done the things actually!my required in a crypto library like attempting to make sure all branches are the same instruction length for all implemented algorithms?
  - loup-vaillant 9y ago
    > I see no mention of how monocypher implementation does anything 5o prevent side channel timing attacks, Oh come on, the chosen primitives are all designed for easy immunity against timing attacks. I haven't verified this formally, but I basically ripped off safe designs, and I tried to be careful about avoiding secret dependant branches and indices. > I haven't looked to see if there is any sensitive memory scrubbing. There's a whole test suite for that. Look at the makefile, then select whatever sanitiser it lists (comment/uncomment the relevant CC line at the begining). Then run `./test.sh`. You can also run the relevant executables under Valgrind. Finally, there's a way to run it under the TIS-Interpreter, though that is veeery slow. > by someone who doesn't know C very well Could you tell me how you inferred that? That could help me improve.
    - cryptonector 9y ago
      The chosen primitives can still be implemented such that there are timing side channels.
      - loup-vaillant 9y ago
JohnStrange 9y ago
If you know enough cryptography and are a good programmer, then you can do it; otherwise better not. The advice to not roll your own crypto used to mean that you shouldn't invent your own cryptographic algorithm. That's true, unless you're an experienced cryptanalist you're likely going to come up with something bad. (Or slow, as e.g. a moderately secure Feistel cipher is easy to invent if you don't care about speed.) As for your own implementation of standard algorithms, there are some things that can go wrong, mostly with key derivation padding and chaining modes, but it's not a secret art that only few chosen cryptographers could master. You have test vectors for the algorithms itself, and have to be extra careful about the rest. You have to get someone to audit the code. That's about it. The fact that people no longer roll their own crypto has two major disadvantages. First, modern ciphers like AES have been designed for ridiculously low security margins. You could claim that security was subordinated to speed in NIST competitions. You can see that in the decision to choose Rijndael over Serpent and Twofish. AES ahs the lowest security margins. Second, it presumably makes life much easier for intelligence agencies all over the world. Instead of having to reverse engineer and analyze thousands of different implementations, they can focus on attacking a dozen popular crypto libraries. This saves them a lot of time and money and also makes it much easier to attack individual developers or binary distribution. (Most attacks nowadays are probably side-channel attacks anyway, but who knows...)
loup-vaillant 9y ago
I would probably have the same perspective if our roles were reversed. I assume I'm a random dude on the internet to you, and trusting crypto code from a random dude is… unwise to say the least. Nevertheless, Monocypher is pretty thoroughly tested by now. I wouldn't be surprised if Monocypher starts getting serious vetting a few months from now.

merb 9y ago

well if you have enough people especially working with crypto, than why not? It's not like that the existing solutions came out of nowhere. some people actually wrote them. I mean libsodium is actually really simple to use. however before libsodium it was probably easier and mostly more correct to roll your own. there are so many things you can do wrong with other libraries that the chance to do it wrong is as high as in your own implementation.

timclark 9y ago

How will cryptography libraries ever develop if someone doesn't roll their own?

rootlocus 9y ago
Through sweat and blood. Don't expect crypto libraries to be secure the first few years after their release. That's why people favor the mature, battle-tested libraries.
- jwl 9y ago
  But then again, we still got Heartbleed.
  - bananaboy 9y ago
    Yeah and imagine the kind of exciting bugs that exist in new and immature libraries! :)
    - jwl 9y ago
      Yes, but are hackers going after common used libraries to get more vulnerable systems to attack or are they going to spend time on some unknown homebuilt crypto? In some cases, security through obscurity works well in practice.
      - ZoFreX 9y ago
        > In some cases, security through obscurity works well in practice. This is not one of those cases. Absolutely not. I'm moderately competent at finding security bugs in things, but I doubt I could find any in OpenSSL. I am confident I could find some in your average hand-rolled code. The thing is people make the same mistakes. There's a set of well-known mistakes that are very easy to make, especially if you're not versed with the entire history of implementing crypto - which is the case for the majority of people rolling their own. This makes it very, very easy to guess what mistakes they will make, and if you know what you're looking for it's easy to find it. My "personal best" for finding a crypto bug in a project is 50 seconds. I doubt anyone has found a bug in OpenSSL (or any established crypto project) anywhere near that fast.
        jwl 9y ago
        You got to consider your most likely risk for attack. Targeted or at random by a botnet? For example, you are most likely more secure in practice by writing your own website than using Wordpress, simply because you are more likely to get hit by a botnet targeting every Wordpress site than someone going directly for you.
        ZoFreX 9y ago
        This is off-topic. We are talking about security vs obscurity in the context of cryptography libraries.
        palunon 9y ago
        Replace WordPress with OpenSSL and website with crypto.
baby 9y ago
tbh, they do develop like this. Some guy come up with a library, a lot of critics arise, but the guy pushes through and many years later it becomes somehow a reference when someone big on twitter mentions it as his/her favorite crypto library.

cyphar 9y ago

Interestingly it looks like there was a bug in every Argon2 implementation specifically because everyone just used the reference implementation. Personally, I think the intention of the phrase "don't roll your own crypto" was lost over time. It was advice to companies to use standard cryptographic algorithms rather than everyone coming up with their own thing for no good reason. It doesn't mean that only some blessed individuals should be allowed to write cryptographic software. I think OpenSSL has taught us that not rolling your own crypto results in a monoculture of self-professed experts that didn't follow that advice.

laumars 9y ago
Those are two separate arguments. Of course there should be competition in crypto libraries. However the "don't roll your own" advice is to prevent people who don't have sufficient experience, education nor resources to write their own library that can compete - effectively leaving their systems vulnerable. The thing about the "don't roll your own" advice is it's aimed at people who don't competently know what they're doing rather than those who do.
- cyphar 9y ago
  How do you expect people to become competent if you constantly tell them to not do something? All that will happen is that people who don't listen to warnings will write crypto libraries and everyone will be forced to use them because nobody else wrote one. The fact that there was no independent implementation of Argon2 that found there was a bug in the reference implementation shows that the "don't roll your own" advice is discouraging competition in crypto libraries to the point where the reference implementation wasn't sufficiently verified to produce correct output.
  - laumars 9y ago
    Again I feel the need to reiterate that the rule only needs to apply to those it needs explaining to. Ie nobody who is smart enough to roll their library would not do so for a production system without it having undergone rigorous testing first. Sure we might write hobby projects (I've written my own encryption ciphers for fun) but that's very different from actually using said cipher on live and/or business critical systems. Simply put, the rule is there to remind people that rolling your own crypto libraries is dangerous. It's not meant to be taken literally to the daft extremes that yourself and a few others on here have. It's just meant to stop those lacking common sense from leaving themselves vulnerable.

baby 9y ago

There is a difference between rolling your own crypto and rolling your own crypto. There is Monocypher, then there is this company that is trying to do some weird protocol using CRC, DES in CBC mode and MD5. The sentence was targeting the latter case.

ewanm89 9y ago
No, it is targeting both. I see no mention of how monocypher implementation does anything 5o prevent side channel timing attacks, I haven't looked to see if there is any sensitive memory scrubbing. Of the bugs listed most are performance bugs by someone who doesn't know C very well yet have they done the things actually!my required in a crypto library like attempting to make sure all branches are the same instruction length for all implemented algorithms?
- loup-vaillant 9y ago
  > I see no mention of how monocypher implementation does anything 5o prevent side channel timing attacks, Oh come on, the chosen primitives are all designed for easy immunity against timing attacks. I haven't verified this formally, but I basically ripped off safe designs, and I tried to be careful about avoiding secret dependant branches and indices. > I haven't looked to see if there is any sensitive memory scrubbing. There's a whole test suite for that. Look at the makefile, then select whatever sanitiser it lists (comment/uncomment the relevant CC line at the begining). Then run `./test.sh`. You can also run the relevant executables under Valgrind. Finally, there's a way to run it under the TIS-Interpreter, though that is veeery slow. > by someone who doesn't know C very well Could you tell me how you inferred that? That could help me improve.
  - cryptonector 9y ago
    The chosen primitives can still be implemented such that there are timing side channels.
    - loup-vaillant 9y ago

JohnStrange 9y ago

If you know enough cryptography and are a good programmer, then you can do it; otherwise better not. The advice to not roll your own crypto used to mean that you shouldn't invent your own cryptographic algorithm. That's true, unless you're an experienced cryptanalist you're likely going to come up with something bad. (Or slow, as e.g. a moderately secure Feistel cipher is easy to invent if you don't care about speed.) As for your own implementation of standard algorithms, there are some things that can go wrong, mostly with key derivation padding and chaining modes, but it's not a secret art that only few chosen cryptographers could master. You have test vectors for the algorithms itself, and have to be extra careful about the rest. You have to get someone to audit the code. That's about it. The fact that people no longer roll their own crypto has two major disadvantages. First, modern ciphers like AES have been designed for ridiculously low security margins. You could claim that security was subordinated to speed in NIST competitions. You can see that in the decision to choose Rijndael over Serpent and Twofish. AES ahs the lowest security margins. Second, it presumably makes life much easier for intelligence agencies all over the world. Instead of having to reverse engineer and analyze thousands of different implementations, they can focus on attacking a dozen popular crypto libraries. This saves them a lot of time and money and also makes it much easier to attack individual developers or binary distribution. (Most attacks nowadays are probably side-channel attacks anyway, but who knows...)

loup-vaillant 9y ago

I would probably have the same perspective if our roles were reversed. I assume I'm a random dude on the internet to you, and trusting crypto code from a random dude is… unwise to say the least. Nevertheless, Monocypher is pretty thoroughly tested by now. I wouldn't be surprised if Monocypher starts getting serious vetting a few months from now.