Nostr private messages

NIP-04 introduces the concept of encrypted direct messages. This mechanism allows users to exchange encrypted messages but while it's simple simple in nature it comes with inherent drawbacks.

Firstly NIP-04 doesn't guarantee perfect forward secrecy. Perfect forward secrecy is a name for a property of cryptographic systems which prevents the attacker from accessing all encrypted messages after gaining access to long-term cryptographic keys. This means that if your private Nostr key is made public then all private messages which you received can be decrypted using that key.

Secondly NIP-04 doesn't protect message metadata which includes message timestamp and public keys of both parties. This effectively allows an attacker to generate a list of all direct public messages exchanged on Nostr including public key of the sender, public key of the receiver and the message timestamp. Below you can see a screenshot of my conversation with the Nostrica account. Names of both parties and exact timestamps are visible. Note that I am logged in with my public key not private key. This data can be accessed by anyone.

Screenshot which shows that metadata of encrypted direct messages such as timestamps and public keys of both parties can be publicly seen taken in the Hamster client. Screenshot which shows that metadata of encrypted direct messages such as timestamps and public keys of both parties can be publicly seen taken in Hamster.

Approach 1 - key rotation

A very simple approach to enhance the existing system with perfect forward secrecy is through key rotation. A Nostr user could publish a list of semi-ephemeral keys together with time-based validity ranges. Other parties could use those keys to communicate with them:

[
    {
        "publicKey":    "encodedpubkey1",
        "validityFrom": "2023-03-23T00:00:00Z",
        "validityTo":   "2023-03-24T00:00:00Z"
    },
    {
        "publicKey":    "encodedpubkey2",
        "validityFrom": "2023-03-24T00:00:00Z",
        "validityTo":   "2023-03-25T00:00:00Z"
    }
]

Using this technique if Alice wanted to send a message to Bob she would first retrieve the list of public keys published by Bob. Alice would then select a key which is valid for the time at which the message to Bob is being sent treating the validity range as a half-open interval [validityFrom, validityTo). Finally Alice would send a NIP-04 message to the selected semi-ephemeral public key.

This approach has several drawbacks. Firstly it requires that the list of public keys is published in advance. This is problematic if a user rarely opens their Nostr client and the client is not capable of automatically generating and posting the list of ephemeral keys in the background. The list of published ephemeral keys could however include many keys and cover a significant amount of time in the future. For example it seems to be feasible to post a list of ephemeral keys for years in advance with the validity of each ephemeral key set to one week. Another problematic feature of this approach is that the user would have to forever store the list of past keys so that past messages can be decrypted if desired.

While this approach could enhance the existing system with perfect forward secrecy it doesn't address the problem of metadata.

Approach 2 - async handshake

Another approach involves performing an async handshake leading to shared secret derivation by sending multiple events. If Alice wanted to send a message to Bob and they wouldn't have a secure channel established yet then Alice could first locally save the message to be sent. Alice would then exchange several NIP-04 messages with Bob to perform an async secret derivation algorithm using ECDH key exchange. Once a shared secret is established messages could be easily exchanged using a block cipher.

A downside of this approach is more network traffic needed to initially establish a secure channel as well as potentially delayed sending of the initial message when network connectivity is degraded. Another challenge involves sharing the shared secret between different clients and devices.

Again, while this approach could enhance the existing system with perfect forward secrecy it doesn't address the problem of metadata.

Approach 3 - ephemeral keys

During the NosTropical hackathon organized after the Nostrica conference an approach to hiding metadata was suggested by npub1h72rk..., npub1fzdvt..., npub1afjrs... and npub1duedm.... After listening to their presentation during the hackathon and briefly discussing it I will describe it here as best as I can. Unfortunately the presentation wasn't recorded due to technical problems.

Let's assume that Bob wants to send a message to Alice. First Bob creates ephemeral keys Bob' and Bob''. Next Bob sends the following NIP-04 message to Alice:

 +---------------------------------------+   
 | NIP-04                                |   
 | from  Bob'                            |   
 | to    Alice                           |   
 |                                       |   
 | +-----------------------------------+ |   
 | | My real key is Bob.               | |   
 | | My conversation key is Bob''.     | |   
 | +-----------------------------------+ |   
 |              payload is signed by Bob |   
 +---------------------------------------+

This message informs Alice that Bob will be using ephemeral key Bob'' to send messages to Alice. It is send by an ephemeral key Bob' in order to hide the fact that Bob wants to communicate with Alice.

Now Alice knows that Bob will be sending messages from identity Bob''. At this point the emphemeral key Bob' can be discarded. In order to send a real message Bob uses key Bob'' to send a NIP-04 message to a randomly generated identity Random. This message contains the real NIP-04 message from Bob to Alice as its payload to hide its metadata. Alice knows that she should monitor all messages sent by Bob'' thanks to the previously received message.

 +---------------------------------------+   
 | NIP-04                                |   
 | from Bob''                            |   
 | to   Random                           |   
 |                                       |   
 | +-----------------------------------+ |   
 | | NIP-04                            | |   
 | | from  Bob                         | |   
 | | to    Alice                       | |   
 | |                                   | |   
 | | +-------------------------------+ | |   
 | | | <Bob's real message.>         | | |   
 | | +-------------------------------+ | |   
 | +-----------------------------------+ |   
 +---------------------------------------+

Note that this outer NIP-04 message is encrypted to a key derived from keys Bob'' and Alice as otherwise Alice would not be able to decrypt it.

This approach hides the message metadata but doesn't address the perfect forward secrecy. Even though the attacker doesn't know that the outer NIP-04 message is encrypted with keys derived from keys Bob'' and Alice (and thinks it is encrypted using keys derived from Bob'' and Random) an attacker with a lot of computing power e.g. a nation-state can try to decrypt all captured NIP-04 messages. Nonetheless it is in my opinion quite an interesting idea which should be explored further. This mechanism can also be combined with approaches described in previous sections. If you have any questions about this mechanism contact its aforenentioned creators, probably using (still flawed) NIP-04 messages.

Some more information about this approach:

Bye friends!

For now it is time to head home. I had a great time and enjoyed talking to people at Nostrica, making new friends, dancing and hanging out with my coworkers. I hope that all of us are building a strong and friendly community. I already miss both Costa Rica and all of you!

Pura vida!

Costa Rica visible from above. The picture is taken from an airplane window and in the foreground you can see a part of an airplane engine. The hills covered by vegetation meet an irregular coastline.

2023-03-27