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.

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.

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.

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.

I agree with what you're saying in general, that people should not write a crypto library unless they have a strong need to and are going to have it thoroughly audited.

> 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.

My problem is that this nuance is not present in the statement "don't roll your own crypto". And that lack of nuance leads to no competing Argon2 implementation, and having OpenSSL control the future of TLS.

It's not just a few people who have taken it "literally to the daft extremes". Nobody in the entire crypto community re-implemented Argon2, not even as a hobby project. The message "don't roll your own crypto" is too strong because it results in nobody implementing their own crypto for any reason (which should not be surprising given the mantra).

I think it's a bit of a stretch to say nobody implemented Argon2 because of the aforementioned rule when it's also been pointed out in this thread the vast number of times that people have rolled their own crypto libraries. That would suggest to me that there are other factors at play with your example. Possibly due to the relatively young age of that specific KDF, or perhaps it's lesser known compared to many of the others? I don't really know enough about Argon2 to make any specific comments there but in the more general sense it has been proven on here already that many people do make hobby projects of rolling their own libraries.

I used Argon2 as an example because it was mentioned in TFA, as the author discovered that the test vectors were wrong because the reference implementation was wrong. That author noted that if someone else had implemented it from scratch they would've noticed this immediately when testing the test vectors.

I got why you used that as a reference. I was just saying it's a bit of a stretch to say your arguments about the aforementioned rule are the reason nobody else attempted to implement Argon2 when we already have a long list of examples of people who do roll their own ciphers.

The point of the rule is to discourage those who don't know what they're doing from compromising live systems. The kinds of people interested in Argon2 are the kind who are already security minded so will understand the point behind the rule and will understand it's fine to ignore that rule if you understand the caveats that rule implies.

The fact Argon2 hadn't been reimplemented can easily be explained for a number of other reasons too.

Most people with even a casual interest in security do understand that point behind the "don't roll your own" rule so I think it's odd to suggest that we are all too literally minded. As evidenced by the fact that a great many people do write their own hobby libraries.

I believe it should read "Don't roll your own crypto for use in a production environment", but that doesn't sound very catchy.

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...)

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.

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.

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

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.

But then again, we still got Heartbleed.

Yeah and imagine the kind of exciting bugs that exist in new and immature libraries! :)

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.

> 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.

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.

This is off-topic. We are talking about security vs obscurity in the context of cryptography libraries.

Replace WordPress with OpenSSL and website with crypto.

Both are vectors. On one hand, you have automated systems trying to hack low-hanging fruit (unpatched, well-known-to-be-insecure libraries), while simultaneously, you could become a specific target - where security by obscurity doesn't get you much. Saying "one of these is not worth considering, as it's less probable" is security through handwaving: one day, someone might discover a bug in your obscure library, and suddenly you're right back in range of automated attacks.

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.

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.

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?

> 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.

The chosen primitives can still be implemented such that there are timing side channels.

This doesn't happen naturally, except for Poly105 and curve25519 (for those one indeed has to be careful). A naive implementation of Chacha20 for instance is pretty much guaranteed to be immune to timing attacks.

> I see no mention of how monocypher implementation does anything 5o prevent side channel timing attacks

He actually talked about avoiding side-channel attacks in his two previous articles about Chacha20 and Poly1305.