A Basic Introduction to Private Messaging
Many of the people discussing private messaging don't really understand what makes messaging private. This is leading to much confusion, as there are many messaging apps on the market, which are all more or less private.
What is your personal threat level? Which aspects of privacy are paramount to you, for the use case you are considering? Only you can answer that. If you are not a computer scientist or other expert on the topic, but wish for it to be an educated answer, I offer this introduction to the topic.
I also welcome naive questions and expert review and will use any discussion to refine the essay.
But which one is more private and which is less private?
The thing that makes messaging the most private is the location of the messages and the transmission of the messages. These are what determine how and to what extent a third-party is
- aware of the existence of the message,
- able to trace or monitor the message flow, which allows them to use additional/parallel data and patterns to deduce the associated metadata (sender, recipient, topic, or urgency),
- likely to intercept the message
(Please note here that tracing the message package to its destination or source aids in physical interception through legal warrants and other personal intimidation or blackmail, since humans are not as hard as encryption.)
The messages should preferably be stored on machines the sender and/or the recipient personally control, and on no other machines. Other machines, if included in the system, should only be used to forward/relay the messages, not to store them. The messages should best be sent over a secure connection, with their metadata and content obscured through methods such as gift-wrapping (see [[NIP-59]]) and encryption.
Gift-Wrapping
Gift-wrapping is done in three parts:
- An unsigned message (a rumor) is placed within
- a sealed, signed envelope, which is then
- gift-wrapped in a second envelope with the recipient's address on it.
This means the relay server only needs to know who to send it to, not who sent it. The recipient unwraps it, to see who sent it, and to decide if they want to open it. If opened, the recipient is then holding a message sent from the sender, that may or may not be written by that sender. (Which adds plausible deniability, if leaked, as there is no way to retroactively tie the message back to the broken seal.)
Encryption is Obfuscation
Encryption is simply any technique used to make a message unreadable to anyone who does not have the means to interpret it. The goal of encryption is not to keep the message private, but to make the message difficult to read through obfuscation. It is therefore typically done as a backstop, in case the message is intercepted or leaked.
A very simple form of encryption is to agree ahead of time on shifting the alphabet n letters forward (so that a shift of 5 would lead to As becoming FS and Bs becoming Gs). This is a chiffre.
A more complex form of encryption is to use a cryptographic key to scramble or unscramble a message. The scrambling creates gibberish, called ciphertext. This requires both sender and recipient to share a key. Nostr typically uses a key pair encryption system, by which a message can be encrypted using a public key, but only decrypted by a private key.
Other forms of data obfuscation are hiding or obscurely naming files, randomly-generating string addresses (such as with share links), masking text, shuffling database tables, or substituting words (as was assumed with the Pizza Gate scandal.
Epoche Keys
Some keys are meant to be persistent (such as those used to sign longform articles on Nostr), and some are meant to be transient, and are rotated as epoch keys. These are only valid for a span of time (an epoch), until:
- a specific date,
- a certain length of time has passed,
- or some activity happens (someone creates a group, joins a group, or leaves a group).
These epoch keys work most effectively if they are rapidly and automatically rotated, preferably without needing to interact with the user.
Public versus Private
Private messages are inherently different than the public messages we typically use for Nostr notes. The latter are relayed, but also typically stored for longer than the relay performance requires. There are even archive relays that store everything anyone has posted to a public relay, including deleted, expired, or ephemeral messages. Public messages are those readily and easily available to anyone, in a public place, regardless of any attempts at obfuscation or requests for removal.
Once your data is out there, it is out there.
Private messages should ideally be peer-to-peer (client to client) or ephemeral (forwarded from server to client and then deleted). P2P is vastly superior privacy to ephemeral, and ephemeral is vastly superior to anything stored for the medium-to-long term. Ephemeral messaging can even be performed by servers on the same machine as the client; such as local relays, which gives them the privacy level of a P2P system. Second-best privacy for ephemeral messaging is using a private relay on a remote machine you control.
But it must be emphasized that anything transmitted over the Internet is being relayed, not sent P2P, because the Internet itself is a relay system. Something like Bluetooth would be more P2P, as a communications channel, but this is often impractical over a long distance, and maintaining a proprietary network is expensive and difficult, so most messaging systems simply use encrypted Internet transmission.
Single-device vs Multi-device Messaging
It is best practice, if a bit annoying, to use different accounts with different devices. A protocol like #Cordn allows for single-device or multi-device logins, for convenience. This is a very popular feature, but I am remaining with single-device, for the added security and the ability to block one device's account without losing access from the other (after losing a cellphone, for instance).
The Advanced Bit
I will simply quote another source, for this final topic:
In order to precisely understand the confidentiality guarantees that MLS enjoys, we must explain the two notions of post-compromise security and forward secrecy.
To read this blog post, your web browser used the TLS protocol to establish a secure connection with my web server, which probably took less than a second. Group messaging is a different beast: the protocol runs for a long period, sometimes several years. Secure group messaging protocols must therefore account for the possibility that one of the devices is stolen or compromised during the lifetime of the conversation.
Forward Secrecy (FS) and Post-Compromise Security (PCS) refine the confidentiality property: they state what happens to confidentiality when a device is compromised by an attacker.
Forward-Secrecy
Forward secrecy means that even if private keys become known to an attacker, they still can’t decrypt messages that were sent in the past. In other words, confidentiality of messages you send now are not affected by future leak of private keys.
Post-Compromise Security
Post-compromise security is the “reverse” of forward secrecy : even if private keys become known to an attacker, they still can’t decrypt messages that will be sent in the future, after some period of healing (where those private keys will be replaced by new ones). In other words, confidentiality of messages you send now are not affected by previous leak of key material.
The source article below explains these final two aspects of private communications, in more detail.