[dom0]

> I really have no way of verifying if I'm learning the correct DHE, and I know that it's easy to get wrong. Perhaps I can do some testing in code, but I may test it incorrectly too, and those small errors can be exploited.

Well this is step 0 in cryptography engineering: You don't implement primitives. Use reviewed components providing primitives and implement your protocol on top of that. Step -1 is to not design your protocol, but use a reviewed protocol and implement that. Finally, step -2 is to not implement a protocol, but rather use a reviewed implementation of a fitting protocol.

This isn't sarcasm and I don't mean to attack you.

[eponeponepon]

There's a difficult rabbithole here - eventually you have to draw a line and decide to trust someone. Otherwise it's just layer after layer of paranoia until you implode in a puff of Philip Dick :)

[dom0]

Of course; my point is (and I assume that's also the point of other people who assert similar stances on the topic) that the average programmer or software engineer should leave these things to recognized cryptographers. This also highlights a peculiarity with cryptography, in that it is very hard to understand for laymen (assuming laymen are ppl with some CS or math education), so most arguments in discussions of laymen will be appeals to authority (eg. djb said ..., Schneier wrote ..., Rogaway wrote ...), and that very subtle mistakes can have very large consequences (on the other hand SE is full of these things; your entire software can be great and bug-free, yet a single off-by-one could get it 0wned anyway).

[daenney]

> Of course; my point is (and I assume that's also the point of other people who assert similar stances on the topic) that the average programmer or software engineer should leave these things to recognized cryptographers.

If "crypto is for cryptographers" is your stance I think you're doing yourself a disservice. Understanding crypto, as in learning the foundations of it, is important for everyone. Having a good grasp of cryptography helps with making decisions in your code base w.r.t to how you use cryptography primitives and tends to help you in identifying places where it's gone wrong.

I agree that it's easy to get these things wrong but I don't think that's a very good reason not to try to write or read up on the subject. And yes, it's possible that what you get taught might have holes too. But it's easier to fix these holes, for example by having discussions around the topic with others and validating what you're being taught, than acquiring the knowledge to begin with.

Now the author in question (lvh) is also known for their contributions to caesium (Clojure implementation of libsodium/NaCl) and Python Cryptographic Authority's cryptography library. They've got some solid chops in the area but make of it what you will.

That said, rolling your own crypto should be left to cryptographers with extensive peer reviewing and so on.

[__jal]

I agree that everyone should learn more about crypto. It helps people understand what is actually going on, and what they can count on and not count on.

Engineers working around crypto that will be responsible for anything important, even doing seemingly simple things like feeding the entry point a password, need to either have their code audited by someone with experience here, or be a person who could audit it. This is because there are so very many ways that seemingly inconsequential things (function timing, hardware behavior in the face of voltage manipulation, nonzero-ed memory in deallocated buffers... and these are the more obvious things) that can lead to a break.

And that's really only a starting point... this stuff is hard. I won't try to write it other than for my own amusement.

[tracker1]

I think it's important to have a decent understanding of types of crypto (including salt/hashing) as well as where to apply what. IMHO it gets harder when it comes down to protocols used for communications, sync/async, etc.

Also, if you're ever interested in something.. find a protocol in a language, and try to refactor it, but first create a bunch of test cases, and make SURE to include unicode characters, etc in any strings you're testing, high byte characters are often missed as a use case, and it gets weird.

Getting multiple systems in multiple languages talking can sometimes be frustrating to say the least.

[Cyph0n]

Look at DES or MD5. Were they not designed by cryptographers?

Or how about the whole Dual_EC_RBG backdoor fiasco? Yes, there was criticism right from the start, but it was adopted and used widely as far as I know. Heck, Dual_EC_RBG was only ousted in 2013:

"The ANSI X9F1 Tool Standards and Guidelines Group which discussed the backdoor also included three employees from the prominent security company RSA Security.[6] In 2004, RSA Security made an implementation of Dual_EC_DRBG which contained the NSA backdoor the default CSPRNG in their RSA BSAFE as a result of a secret $10 million deal with NSA. In 2013, after the New York Times reported that Dual_EC_DRBG contained a backdoor by the NSA, RSA Security said they had not been aware of any backdoor when they made the deal with NSA, and told their customers to switch CSPRNG."

Besides, I think it's a good learning exercise to try to implement cryptographic primitives based on existing implementations. My opinion is that such language would dissuade people from even trying to design one for fun.

Disclaimer: do not design your own crypto primitive for production use.

[Ar-Curunir]

Nitpick: DUAL_EC was adopted despite cryptographer's complaints; I don't think there any cryptographers vociferously supporting it.

I do agree that learning crypto is a good thing, because it gives you an idea of what your primitives should do, and when it is appropriate to use them. People should always refrain from using their own home-grown crypto, however.

[john_reel]

Cryptographers were not fond of DUAL_EC. They also recommended against DES and MD5 long before attacks really appeared.

[serge2k]

> that the average programmer or software engineer should leave these things to recognized cryptographers

Study and experimentation are how you end up with recognized cryptographers.

This very sensible attitude of "Use the recommended library with recommended settings" seems to get pushed to the point where it becomes "Don't bother learning". I don't think it's intentional of course.

[dom0]

To clarify: I didn't mean that people shouldn't learn or read about the topic, or try designing their own block or stream ciphers, hashes, KDFs and of course protocols (which are great fun!), not at all. Both my original comment and this one are directed at production use of cryptography.

[lvh]

Hi! I'm the author of Crypto 101.

I couldn't agree more. I think the fact that we have so much crypto foot guns available is a UX issue that we should address. Ideally, Crypto 101 would only be to satisfy one's own curiosity; not mandatory reading for anyone who wants to do something cryptographic. Alas, that's also not the world we live in right now. Realistically, plenty of crypto libraries will offer up e.g. unauthenticated AES-CBC. Then you probably want to know about some of the attacks on that, why you want a MAC, and where that MAC should live; if only to convince your coworkers that the concerns you have are real.

[FullyFunctional]

Isn't this the point of [Twitter]NaCl (Bernstein et al)? To provide a library which, when used correctly, makes it harder to make the obvious mistakes?

I think it's great, but it doesn't solve the protocol issue.

[lvh]

Sure! But folks don't always use NaCl; they can have all sorts of stuff currently in play.

[PeterisP]

It's not really a rabbithole in most cases - unless you have exceptional expertise (and you'd know), you should trust someone else right away, not eventually, because you should trust yourself even less.

Even if you have good reason to believe that all available third party systems are vulnerable to one or another intelligence agency, using that would still be more secure than doing everything yourself, which you can't do properly (noone can do that without extensive review from a large community, so you definitely can't as well), and thus making a system that's vulnerable to everyone.

[htrp]

The only problem with that is that at some point you get into outright (justified or not) paranoia. Is your computer the victim of a supply chain attack? Did someone intercept your switch/router in delivery?