Is Nostr really unsuitable for privacy-focused chat apps? — Taking Keychat and Simplex as examples One of the most common misconceptions about Nostr is that it can’t be used to build a truly private chat app. It’s time to clear up that misunderstanding. We’ve written a number of related notes before — this is just a summary for now, which we may later expand into a full article. ----- Simplex Chat is very popular in the Nostr community; whenever someone posts a note asking which chat app is secure, many people recommend Simplex Chat. We also think Simplex Chat is a great app. So, many people ask what is the difference between Keychat and Simplex Chat? Is Keychat's security as good as Simplex Chat's? Is it really possible to create a chat app as secure as Simplex Chat on Nostr? Why not just use Simplex Chat? Why reinvent the wheel? A common misconception in the Nostr community is that Nostr is not suitable for private things. "Nothing about any of the protocols we’ve developed requires centralization; it’s entirely possible to build a federated Signal Protocol-based messenger, but I no longer believe that it is possible to build a competitive federated messenger at all." — Signal Founder Moxie signal.org/blog/the-ecosystem-is-moving%C2%A0 This is because the encryption process is completed on the client side, and relays only pass the encrypted messages. Keychat and Simplex Chat both use the Signal protocol to encrypt messages, so both meet the following security requirements 1-4: Anti-Forgery Anti-Forgery ensures that the sender of a message is verifiable and the message has not been tampered with. End-to-End Encryption End-to-end encryption ensures that only the sender and receiver can decrypt and read the message content, protecting it from unauthorized access by servers or other network devices. Forward Secrecy Forward secrecy ensures that even if the current key is compromised, historical messages cannot be decrypted, since each message uses a new encryption key, which is deleted after use. Break-in Recovery Break-in Recovery ensures that if the current key is compromised, future messages cannot be decrypted, and the system can recover from the attack. This feature is also known as backward secrecy. Metadata Privacy Protecting the privacy of communication involves more than just protecting the content of messages; it also includes protecting the identities of the communication parties and other data. Regarding the fifth point, metadata privacy. The designs of Keychat and Simplex Chat are different. Simplex’s metadata privacy protection scheme "Simplex chat is the first messenger without user IDs." “To deliver messages, instead of user IDs used by all other platforms, SimpleX uses temporary anonymous pairwise identifiers of message queues, separate for each of your connections — there are no long term identifiers.” “Temporary anonymous pairwise identifiers SimpleX uses temporary anonymous pairwise addresses and credentials for each user contact or group member. It allows to deliver messages without user profile identifiers, providing better meta-data privacy than alternatives.” We can understand this mechanism as, if a Simplex Chat user has 10 friends, they have 10 IDs, using different IDs with different friends? Keychat’s metadata privacy protection scheme Current chat applications and email have forgotten that an address is not the same as an ID, treating the ID as the address. Emails and current chat applications send messages as [from: Alice's ID to: Bob's ID]. Regardless of how your geographical address changes, when Alice sends an email to Bob, it’s always [from: Alice's ID to: Bob's ID]. This compromises metadata privacy. However, letters work differently; they are [from: Alice's current geographical address to: Bob's current geographical address]. Keychat separates the receiving address and sending addresses from the ID, and the receiving address and sending addresses are also different. Keychat messages are [from: Alice's one-time sending address to: Bob's almost one-time receiving address]. This makes it difficult for outsiders and relay administrators to determine who is sending messages to whom. Which scheme do you think is easier to understand and better protects metadata privacy? Finally, Keychat also uses ecash sat as a stamp for messages, with relays funded by stamp revenue to sustain operations. ————————— Evolution of Receiving Addresses in Signal, Simplex Chat, and Keychat A receiving address is indispensable to any chat application—just as an envelope needs only the recipient’s address. Because this address is exposed plaintext metadata, its design determines how much metadata privacy the user enjoys. Signal each user has a single receiving address that is also their ID. For Bob and Carl alike, Alice’s address is always the same—simply A—and it never changes. Simplex Chat Here, the receiving address (smp://<queueKey>@<relay-host>/<queueId>) is different for every contact. Alice has one fixed address for Bob, A(b), and another for Carl, A(c). Having separate—but constant—addresses for each contact is already a significant improvement over Signal’s single, global address. Keychat Keychat goes a step further: the address not only differs per contact but also rotates over time. Alice begins with A(b1)for Bob and A(c1) for Carl; after she replies, they become A(b2) and A(c2), and so on. Each time Alice responds to Bob, her address is refreshed. This dynamic, per-contact rotation provides even stronger privacy than Simplex’s static per-contact addresses. ------------------ The comparison above only covers encryption security and metadata privacy at the application layer, but we also need to consider metadata privacy at the network layer — specifically, the fact that servers and relays can still see users’ IP addresses. Simplex adopts a two-hop relay design: the sender (Alice) first sends the message to relay A, which then forwards it to relay B; the recipient (Bob) retrieves the message from relay B. Keychat uses a single-hop relay: the sender (Alice) sends the message to relay A, and the recipient (Bob) receives it directly from the same relay. The metadata privacy issue at the network layer should be addressed at the network layer itself, by using tools such as VPNs, Tor, or proxies. ------------------ Old Nostr DM (NIP-4) integrates four capabilities into a single Nostr key—it serves as an ID, an encryption key, a receiving address, and a sending address. The encryption key in NIP-4 does not change, so NIP-4 messages lack both forward secrecy and backward secrecy. Consequently, if the private key is compromised, both historical and future messages can be exposed. The receiving and sending addresses remain constant, which poses a severe issue for metadata privacy in NIP-4 messages; Everyone can see who (ID) is sending messages to whom (ID). Currently, most Nostr apps use NIP-4 for DM functionalities, such as Damus and Primal. —————————————————————————————————————— New Nostr DM (NIP-17) integrates three capabilities into a single Nostr key—it serves as an ID, an encryption key, and a receiving address. Kind-17 separates the sending address from the ID, making the sending address random and concealing the sender's real ID, thus improving metadata privacy. The encryption key in NIP-17 does not change, so NIP-17 messages also lack forward secrecy and backward secrecy. Once the private key is leaked, both historical and future messages will be compromised. The receiving address remains constant, so there is still a slight issue with metadata privacy in NIP-17 messages; everyone can see who (ID) is receiving messages. Apps like 0xchat and Amethyst use NIP-17 to implement DM functionalities. —————————————————————————————————————— In Keychat, the ID, encryption key, receiving address, and sending address are separated. The encryption key, the receiving address, and the sending address are updated independently and continuously. Keychat's encryption key is derived using the Signal protocol, and each message uses a unique encryption key, which is deleted after use. Thus, Keychat messages have both forward secrecy and backward secrecy. Even if an encryption key is compromised, only the current message can be leaked, and historical and future messages remain secure. Keychat's sending address is randomly generated for each message. Therefore, external parties do not know the sender's ID. Keychat's receiving address is derived using the Signal protocol, with almost every message using a unique receiving address. Thus, external parties do not know the receiver's ID.