I think this would be a good starting point for what you are trying to achieve: https://libsodium.gitbook.io/doc/public-key_cryptography/aut...

The first example shows both sides of the communication. The public keys are shared (but you want to make sure that you have the correct one, for example by meeting the recipient in person and comparing the keys). The library defaults in libsodium are already chosen to be secure (using Curve25519 and secure algorithms).

That's really nice, thanks. I wonder how my Google fu failed me here. Bookmarking!

Maybe it's not your Googlefu. Maybe it's because the article isn't a video on YouTube, or some sort of social media post, nor is the page heavily weighted with ad. It is a web page full of useful/on-topic information, and the current algo at Google seems to make those types of pages lower ranked. At least that's how it feels

This might be a better starting point: https://paragonie.com/blog/2017/06/libsodium-quick-reference...

If I write something that uses libsodium, am I violating the near universal "don't roll your own crypto" admonishment, or does libsodium sufficiently hide all the scary dangerous cryptographic stuff so that mere mortals can safely use it?

Yes. However, it never hurts to test your code.

Assuming you're a C-programmer, read the libsodium docs first. https://download.libsodium.org/doc/public-key_cryptography/s...

If you're using higher level language, use a library that provides bindings for it https://download.libsodium.org/doc/bindings_for_other_langua...

By using libsodium, you're not rolling your own crypto. Rolling your own crypto would mean

-trying to find new one way functions for public key crypto -trying to implement RSA from textbook -trying to implement RSA-OAEP from papers, RFCs, books etc.

Using a library is not anywhere near those. There are other ways to fail cryptography too, from not doing public key authentication, to storing private keys in insecure places.

So it's highly recommended you take time to read a book on the topic. The best modern book currently availalbe is https://www.amazon.com/Serious-Cryptography-Practical-Introd...

> By using libsodium, you're not rolling your own crypto.

That's debatable. Libsodium does not have a proper authenticated key exchange. The key exchange does the job somewhat, but it has worse security properties than a properly crafted interactive protocol.

Problem is, designing your own key exchange protocol is more delicate than most construction. I know, I designed my own, and made several serious mistakes in the process (one of which voided an important security property).

Granted, rolling your own constructions is generally less error prone than rolling your own primitive. But it still shouldn't be done without at least having followed and fully understood an introductory course in cryptography (I recommend https://www.crypto101.io/). I mean, I did quite a bit more than that, and I still don't fully trust myself.

TL;DR - you're mostly avoiding the admonishment by using libsodium

There are still some dangerous things you can do (e.g. mismanage keys, reuse nonces).

I wrote a library called Halite for PHP developers that wraps libsodium and makes it even harder to misuse. My philosophy was, "You shouldn't even need to know what a nonce is to use it securely."

https://github.com/paragonie/halite

From elsewhere in the thread, PyNaCl takes a similar approach. So how dangerous "just using libsodium" is, with respect to the "don't roll your own crypto" guidance, depends a little bit on which binding you're using.

Also, a lot of tasks might require a specific protocol (PAKEs, VPN protocols, searchable encryption, etc.) that libsodium isn't suitable for.

Wow, your site is a goldmine! Really loving how you make this subject matter accessible for average nerds like me.

Thanks!

I wish I were a little better at SEO so average nerds would have an easy time finding it.

I just read the article a second time and I really like it. This is precisely the starting point that I was craving for and if I had known about it I might not have written this rant :-)

My only SEO advice is patience. Your articles are great, people will link to it increasingly often.

That said, why the sole PHP focus? The starting point you just linked to is pretty much independent from PHP, and there's libsodium bindings in plenty languages. If your goal is simply to make good crypto easier to do for "normal" developers then the PHP association may do more harm than good (particularly because PHP is not very hip right now)

I'm mostly to blame for PHP adopting libsodium in version 7.2. Focusing on PHP was pretty on-brand at the time that was written.

I'm going to need to update it (Argon2id is now the default), so I might generalize the code (or make a tab system to switch between examples).

Then have another developer or consultant handle that part of your project. It seems like you misread a non-existent imperative in the article that "anyone can crypto with these 3 easy steps". They made no such claim.

Where do those consultants/developers come from? Are they born from Crypto eggs with all the knowledge in their brain? Or how do those mighty people come to be?

There are good formal cryptography courses, though some of them focus on aspects that aren't relevant to what I'd call "cryptographic engineering". For example, differential cryptanalysis is very interesting, but basically nobody except the IOTA community is silly enough to try and implement their own primitives, so that's not a common problem.

I authored Crypto 101. One of my cofounders co-authored Cryptopals and founded the cryptographic practice at Matasano (as well as co-founding Matasano itself ;)). So for cryptographic engineering, I think the answer is "historically oral, and increasingly written, tradition"?