What happens when you send a message to a friend? In most cases, the messaging app uses the same approach: the client (your Android App or your browser) sends the encrypted data to a server, where it waits for delivery. When the friend’s App checks for new messages, the server delivers your message. And voilà.
The problem is: the server knows who sent the message (because you are logged in), and knows who fetches it (because it has to deliver the message to your friend and no one else). From a privacy point of view, well, the server knows too much. If evil administrators or a hackers lay their hands on that information, they will know who you’re chatting with.
There are many reasons why you may want to avoid sharing this information. You might want to exchange messages with a known LGBTQIA+ rights defender, in a country that outlaws even discussing those topics. Normally big service providers keep this private from the outside… but not from the inside, not from the administrators. What if the service provider decides to cooperate with a restrictive government? Or what if the data leaks?
Seeld proposes a solution that respects everyone’s privacy, and doesn’t need its users to trust us not to share data. We use mailboxes and box addresses.
Before people can exchange messages, Seeld requires them to connect. This process happens in two phases.
Let’s consider Alice and Bobby. First, Alice sends an encrypted connection request to Bobby. Following that, Bobby decides whether to accept or reject the connection request. Let’s assume Bobby accepts. He stores Alice’s details in his “contacts” list, and sends a connection response to Alice. Alice can now store Bobby’s details in her “contacts”. Of course, each user’s “contacts” list is fully end-to-end encrypted.
What do those details contain? Among many other things, they include a generated mailbox address and a generated key. To clarify, here’s how the connection exchange might be represented:
This implies that Seeld users have at least as many mailboxes as they have connections.
Now that the two persons are connected, they can start sharing messages.
When Alice wants to post a message to Bobby, she send it to the box address she set up for him. She is authenticated, so the server authorizes her to deposit the message in the mailbox.
When Bobby checks the mailbox Alice created for her (which he only knows about), he does not authenticate in his request towards the server. The server doesn’t know Bobby receives Alice’s messages from that box address. However, the server ensures that whoever fetches messages from that box has the right mailbox key. Bobby has it, so he’s able to get the encrypted message, and decrypt it using his PGP private key.
Even though only Bobby has the PGP key to decrypt the messages in that mailbox, the mailbox key prevents anyone else from stealing the encrypted messages. Why does Seeld enforce this additional protection? Because we want to prevent anyone from collecting encrypted data so that it could be decrypted later. As quantum computing evolves, it will be able, at some point, to read PGP-encrypted messages. Post quantum cryptography algorithms, once available, will prevent that from happening. But the risk would remain for messages collected under the “old” algorithm.
This is how you could picture exchanging messages on Seeld:
Since Alice and Bobby exchanged these mailboxes and keys during the connection process, in end-to-end encrypted form, the server partially ignores who these mailboxes relate to. It sees that Alice (authenticated) deposits a PGP-encrypted message in some mailbox, but doesn’t see that Bobby fetches that message from that address. And it sees that Bobby deposits a PGP-encrypted message to another mailbox, but cannot know it is actually Alice that fetches what ends up being Bobby’s reply.
Therefore, neither the server nor the administrators can understand who is talking to whom.
