> 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.
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.
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.
Well, exactly. My point is that in a constrained use-case NaCl would be sufficient.
If you want to rotate keys, then simply delete your private key and since we trust Bluesky so much we can use the PDS to share new pubkeys once we rotate. In fact, this would work for signing keys too! Then the PDS wouldn't be able to write messages for you if it wanted to.
For group messaging you simply encrypt the message to each recipient.
If they want to upgrade to a Axolotl from this, great! But starting with plain text is not private messaging, it is group messaging with your PDS admins and whoever they want to share that data with.
I agree there are more layers you can add on top of TweetNaCl to improve security.
I'm going to personally add you to the list of people Bluesky should hire to get this implemented without the consent of the Bluesky employees. If they choose to hire both of us perhaps we can figure out how to implement this for them.
I will not commit to putting on a furry suit. But I've been known to try everything once. And bonus I live right next to the furry convention center and have always wondered what the heck is going on at the Hyatt while you guys are here.
I won't go out of my way to find out if you don't want it known. If you decide you want to know what's going on in the hotel, there's probably lots of video on YouTube from whichever convention it is.
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.