> but at the very least I think Bluesky could start with generating a private key on each client device, and then using a simple box algorithm to encrypt messages towards the user they want to talk to.
Furry cryptography nerd here.
No. This is inadequate.
> I don't think https://tweetnacl.cr.yp.to/ is hard to mess up.
Yes it is! If you're doing to encrypt some things in a constrained use-case, sure, NaCl is better than hand-rolling it yourself. But it's not sufficient for end-to-end encryption. Here's a few things that TweetNaCl (and other NaCl variants) is, without further protocol design, inadequate to protect against:
1. Invisible Salamanders. NaCl uses xsalsa20poly1305, which is not key-committing.
2. Forward Secrecy. NaCl's crypto_box doesn't give you this at all.
3. Key Compromise Impersonation. See also, Toxcore, which built atop NaCl: https://github.com/TokTok/c-toxcore/issues/426
4. How do you do group messaging? If you do it as just pairwise, do you use the same public key as your p2p messaging? There's a lot of ways that can subtly go wrong.
There is a damn reason end-to-end encryption involves authenticated key exchanges and forward-secure double ratchets.
