Okay, so first - I would say, “sorry to be so much with a double post.. on.. the same day..” but instead I’m going to say, “oh, bummer” because this a space for thoughts, and is just log of the shit that comes into my head that is interesting enough to me to write about.
So, I feel like I’m just really bad at explaining this idea, and the more I go back and try to edit and reframe the ideas in text (I hope to god some of you could at least read my code), it just makes it worse. So this is my attempt to draw it out…
(We’re gonna try with just one image and arrows and labels and shit, but if I still don’t feel s’gud about it, I’ll probably do a multi-image, more powerpoint-esq thing)
Jk, I kinda decided to do the multi-page thing. Sorry.
Right now this post is super inaccessible and I’m sorry for being an asshole - I do genuinely care about everyone being able to experience my shitty content, but I’m just spit-balling and I’m legit taking screen shots of the Notes app, so this is not very high production value already…
My handwriting is “meh” and my drawings are kinda shitty. If you can’t find content in it, stop trying.
1.
We have content. It lives in the content box. It needs to store stuff, and it needs to be encrypted.
So we encrypted it with the ChaCha20 cryptographic algorithm, and we are left with a key, a nonce and the encrypted content.
2.
The nonce is safe to share publicly. It plays a role in decryption but its secrecy is not necessary to preserve security.
Our private key which we used to encrypt the content above, however, cannot be shared publicly, as it is the key to decrypt our so newly encrypted content. But we must also find a way to securely distribute this key to all of the recipients who will need to decrypt the content.
3.
Just like with the nonce, we can also safely send around and store the encrypted content without having to further secure it.
4.
Back to the “content key” which will need to be accessible by all recipients of the message.
5.
Forward secrecy is cool. The private ChaCha20 key, used to encrypt the content, is created new, every time, for every message. (Same with the nonce, but duh.)
6.
Oh shit, we still haven’t planned out how to distribute this super secret key in a super secure manner.
7.
Answer? We e2ee the super secret, one-time, private, ChaCha20 key. And we do that using public key encryption, shared secrets and this sweet thing called elliptic-curve-cryptography, in the form of a algo called “x25519” (sorry for botching this in the image and referring to it as “Curve25519.” “x25519” depends on “Curve25519” but the pub/priv key stuff is born by x25519)
8.
Again, sorry for the flub on “Curve25519” and not “x25519”.
But basically, x25519 gives us the ability to create shared secrets, that we can use to encrypt the private ChaCha20 key we were trying to figure out how to securely distribute earlier.
9.
We good now for sending shit around and storing shit. Just need to manage client logic for distributed, anonymous, routing nonsense.
10.
Now we need to learn about goddamn key exchange and crap within the context of this (still imaginary) system.
11.
Gotta be able to generate the correct shared secrets, and store our private keys, securely, on the client.
How do?
12.
We do by drawing a nonsense diagram.
Basically what this means is “all the private keys are AES256 encrypted, and the only way to find them is with information that can already be safely stored in plaintext and shared about the universe.” So basically we are effort-ing really fucking hard on the anonymity front, while also making sure that the keys are cycled and protected, to ensure (at a minimum “batched”) forward secrecy and make it really hard to find anything meaningful without all of your log in credentials, being used properly, on a well-behaving client (and never discoverable within our system at any point in time other than when your currently live public keys have encrypted some content elsewhere in the system. In that case with a whole table scan and your 1 public key, we could find just the messages in that “batch” but still have absolutely no path to decrypting them).
13.
When a user wants to get new infos, they go to the pod where messages are pushed (all messages go to pods, remember?), and they say, here are the public recipient keys I’d like you to filter with, and here is the date range. All the messages for the date range on that pod are grabbed, if the user’s public recipient key is withing the message’s key set, it will send back only the data necessary for that particular user to decrypt the content. (This also means that if you attempt to request messages from a pod for which members are not using your public key to encrypt content, your public key will not appear in the messages, and thus, no messages can ever be sent to you from that pod).
14.
This is just explaining cryptographic signatures. I’m not explaining it again.
Caveats
I’ll make this more accessible later, add captions, and try to describe my terrible artwork in as much elegant detail as humanly possible.