I of course agree with all of this, but as someone pretty much at the bottom of the food chain who just wants to encrypt some data, there's often no libraries that safely glue the primitives together in the way that I require.

Granted, this is getting better, for example NaCl's crypto_box[0] is awesome and very hard to misuse. But say you want forward secrecy now. chirp, tumbleweed.

I hope this doesn't come off as entitled, but I feel like the best way to get people to stop rolling their own crypto is to provide more/better libraries.

Say you have a requirement to build some chat somewhere, and it sais somewhere that it needs to be encrypted, which I think is a reasonably realistic example. So you use crypto_box, but then you realize you don't have forward secrecy. Ok, no problem, you remember libotr[1] just use that. Now you realize that OTR can't do group chats, so figure ok, most group chats are small everyone can just have an OTR session with everyone else and send their messages to everyone (which of course means you can give different people different messages, but let's ignore that). Next you realize people aren't always online at the same time and you can't send offline messages. So you remember Signal's double ratchet[2]. But libsignal was just built for signal and doesn't look easily integratable. Then I guess there's also (Meg)Olm[3] but that looks like the same story as signal.

[0] https://nacl.cr.yp.to/box.html

[1] https://otr.cypherpunks.ca/

[2] https://en.wikipedia.org/wiki/Double_Ratchet_Algorithm

[3] https://gitlab.matrix.org/matrix-org/olm/-/tree/master

>I of course agree with all of this, but as someone pretty much at the bottom of the food chain who just wants to encrypt some data, there's often no libraries that safely glue the primitives together in the way that I require.

>I hope this doesn't come off as entitled, but I feel like the best way to get people to stop rolling their own crypto is to provide more/better libraries.

Author here. I mentioned libsodium [1] and Tink [2]. We started Tink because we want to provide more/better libraries.

>Granted, this is getting better, for example NaCl's crypto_box[0] is awesome and very hard to misuse. But say you want forward secrecy now. chirp, tumbleweed.

It looks like you want to build an interactive protocol. I'm not sure if libsodium has a solution, but Tink doesn't. So far we've been focusing on encryption at rest. Can you tell me more about your use case?

[1] https://github.com/jedisct1/libsodium

[2] https://github.com/google/tink