Encrypted Direct Message (NIP-04)

definition

NOSTR PROTOCOL SPECIFICATION

What is Encrypted Direct Message (NIP-04)?

A deprecated standard for private, end-to-end encrypted messaging within the Nostr protocol.

An Encrypted Direct Message (NIP-04) is a deprecated specification within the Nostr protocol that defines a method for sending private, end-to-end encrypted text messages between users. It functions by encrypting message content using a shared secret derived from the sender's and recipient's public keys, ensuring that only the intended parties can decrypt and read the message. The encrypted payload is then published as a special kind of Nostr event (kind 4), allowing it to be relayed across the decentralized network while keeping the content confidential.

The encryption mechanism in NIP-04 relies on the Elliptic Curve Integrated Encryption Scheme (ECIES) using the secp256k1 curve, the same cryptographic foundation used for Nostr keys. To send a message, the sender encrypts the plaintext using a shared secret generated from their private key and the recipient's public key. The resulting ciphertext is base64-encoded and included in the event's content field, alongside the recipient's public key for identification. This design ensures that metadata, such as the sender, recipient, and timestamp, remains public, while the message body is protected.

Despite its initial widespread use, NIP-04 is considered cryptographically obsolete and has been superseded by NIP-44. Key criticisms of NIP-04 include its lack of proper authentication tags, making it vulnerable to certain attacks, and its inability to handle large messages efficiently. New implementations are strongly discouraged from using NIP-04 in favor of the more secure and feature-complete NIP-44 standard, which provides authenticated encryption and better handling of message chunks.

etymology

NOSTR PROTOCOL

Etymology and Origin

The term 'Encrypted Direct Message' (EDM) within the Nostr ecosystem originates from a specific implementation defined in a **Nostr Implementation Possibility** (NIP).

The concept of Encrypted Direct Message (EDM) in Nostr is formally defined by NIP-04, one of the earliest and most foundational Nostr Implementation Possibilities. A NIP is a standards document that specifies how clients and relays should implement specific features to ensure interoperability across the decentralized network. NIP-04, titled "Encrypted Direct Message," was among the first set of proposals that established a basic, functional messaging layer atop Nostr's simple event protocol.

The etymology of the term is deliberately straightforward, combining "Encrypted" for the cryptographic privacy mechanism and "Direct Message" for the one-to-one communication model. The technical specification itself builds upon the existing Nostr event structure, using a kind: 4 event. The content field of this event is not plain text; instead, it contains a ciphertext payload encrypted using a shared secret derived from the sender's and recipient's public keys via the Diffie-Hellman key exchange. This design choice reflects Nostr's philosophy of simplicity and reliance on well-established cryptographic primitives.

The origin of NIP-04's specific encryption method is notable. It does not use modern authenticated encryption schemes by default, instead employing a simple AES-256-CBC cipher. This early design decision, made for simplicity, has been a point of discussion within the community regarding its security properties, leading to proposals for more robust successors like NIP-44. Despite this, NIP-04 remains a widely implemented standard, illustrating the evolutionary and community-driven nature of Nostr's protocol development, where foundational NIPs can be supplemented or deprecated by newer, improved specifications.

how-it-works

NOSTR IMPLEMENTATION POSSIBILITY

How NIP-04 Works

NIP-04 is a Nostr Implementation Possibility that defines a standard for end-to-end encrypted direct messaging between users on the Nostr protocol.

NIP-04 specifies a method for sending private, encrypted messages between Nostr clients. It uses a shared secret derived from the sender's and recipient's public keys via the Elliptic Curve Diffie-Hellman (ECDH) key exchange. The message content is encrypted using AES-256-CBC, and the resulting ciphertext, along with an initialization vector (IV), is published as a kind 4 event to the Nostr relay network. Only the intended recipient, who possesses the corresponding private key, can decrypt and read the message.

The encryption process begins when a sender's client generates a shared secret by combining the sender's private key with the recipient's public key. This secret is then used to encrypt the plaintext message. The resulting event contains the content field, which holds the base64-encoded ciphertext and IV in the format <ciphertext>?iv=<initialization_vector>. Additional metadata, such as the recipient's public key, is stored in the event's tags, allowing clients to filter for messages addressed to them while keeping the content private from relays and other users.

While foundational, NIP-04 has notable limitations. Its use of AES-CBC without authentication (e.g., HMAC) makes it vulnerable to certain cryptographic attacks, such as padding oracle attacks if a relay is compromised. Furthermore, it lacks forward secrecy, meaning if a private key is ever compromised, all past messages encrypted with it can be decrypted. For these reasons, newer specifications like NIP-44 have been proposed to provide more robust encryption using authenticated encryption and improved key derivation, though NIP-04 remains widely implemented for basic private messaging functionality.

key-features

NOSTR PROTOCOL

Key Features of NIP-04

NIP-04 defines a standard for private, end-to-end encrypted messaging between Nostr users, using a shared secret derived from their public keys.

01

End-to-End Encryption

NIP-04 ensures only the intended sender and recipient can read a message's content. It uses symmetric encryption (AES-256-CBC) with a shared secret derived from the participants' public and private keys via ECDH (Elliptic Curve Diffie-Hellman). The plaintext content is never exposed to relays.

02

Event Structure & Payload

An encrypted direct message is a standard Nostr Event of kind: 4. The content field contains the ciphertext and initialization vector (IV), formatted as <ciphertext>?iv=<initialization_vector>. The event's tags must include a ["p", "<recipient_public_key>"] tag to identify the intended receiver.

03

Key Derivation (ECDH)

The encryption key is not stored or transmitted. It is derived dynamically by each participant:

The sender uses their private key and the recipient's public key.
The recipient uses their private key and the sender's public key.
This Diffie-Hellman key exchange generates an identical shared secret for both parties, which is then hashed to create the symmetric AES key.

04

Relay-Agnostic Privacy

Relays act as dumb pipes, storing and broadcasting the encrypted event without the ability to decrypt it. This design means:

Metadata (sender, recipient public key, timestamp) is still visible.
Trust in relay operators is minimized for content privacy.
Users can use multiple relays without compromising the encryption scheme.

05

Limitations & Considerations

NIP-04 provides content secrecy but has known limitations:

No forward secrecy: Compromised private keys decrypt all past messages.
Metadata exposure: Relays see who is messaging whom.
No authentication: The standard doesn't sign the encrypted content itself, leaving it vulnerable to malleability. Newer proposals like NIP-44 aim to address these issues.

06

Client Implementation

To handle NIP-04 messages, a client must:

Generate shared secret using ECDH.
Encrypt/Decrypt using AES-256-CBC with a random IV for each message.
Format the ciphertext and IV into the content field.
Sign and publish the event like any other Nostr event. Most libraries (like nostr-tools) provide helper functions for this process.

technical-details

NOSTR PROTOCOL

A specification within the Nostr protocol for establishing secure, private communication between two users.

An Encrypted Direct Message (NIP-04) is a standardized method for sending private, end-to-end encrypted text messages between two Nostr clients. It defines a cryptographic scheme where the sender encrypts a message using a shared secret derived from the participants' public keys, ensuring that only the intended recipient can decrypt and read it. This mechanism provides confidentiality for private conversations over the otherwise public Nostr relay network.

The encryption process is based on AES-256-CBC symmetric encryption. The shared secret is generated using Elliptic Curve Diffie-Hellman (ECDH) key exchange, computed from the sender's private key and the recipient's public key. The encrypted payload, along with an initialization vector (IV), is then published as a kind 4 Nostr event to relays. A critical implementation detail is that the encrypted content must be base64-encoded for transmission.

While foundational, NIP-04 has known cryptographic limitations, such as its lack of authenticated encryption. This means the ciphertext is not protected against tampering, allowing a malicious relay to potentially alter messages without detection. Consequently, it is considered a deprecated standard, with most modern clients implementing the more secure NIP-44 specification, which provides robust authenticated encryption using XChaCha20-Poly1305.

security-considerations

NIP-04

Security Considerations and Limitations

While NIP-04 provides a foundation for private communication on Nostr, its cryptographic implementation has known limitations that developers and users must understand.

01

ECIES Encryption Scheme

NIP-04 uses ECIES (Elliptic Curve Integrated Encryption Scheme) with secp256k1 keys and AES-256-CBC. The protocol encrypts a message to a recipient's public key, but the implementation is non-standard and lacks key derivation and key confirmation, which deviates from modern cryptographic best practices.

02

Lack of Forward Secrecy

A major limitation is the absence of forward secrecy. If a user's long-term private key is compromised, an attacker can retroactively decrypt all past messages sent to that user. This contrasts with modern protocols like Signal, which use ephemeral keys for each session to mitigate this risk.

03

Metadata Exposure

While message content is encrypted, metadata remains fully public on the relay network. This includes:

Sender and receiver public keys
Timestamp of the message
The fact that a private message was sent This metadata can be used for network analysis and social graph reconstruction.

04

Relay Trust & Censorship

Encrypted messages are stored on public relays, which the relay operator can read. Users must trust relays not to drop or censor their messages. There is no guarantee of message delivery, and relays could selectively withhold encrypted events without detection.

05

No Authentication of Ciphertext

The standard does not include a Message Authentication Code (MAC) or signature on the encrypted payload. This makes the ciphertext vulnerable to malleability attacks, where a network adversary could potentially alter the encrypted data without the recipient detecting the modification.

06

Alternative & Future Protocols

Newer Nostr Improvement Proposals aim to address these weaknesses:

NIP-44: A modern, standardized ECIES implementation with authentication and versioning.
NIP-59: Enables gift wraps for indirect, sealed delivery, hiding the recipient. Developers are encouraged to implement these more secure alternatives where possible.

ecosystem-usage

NIP-04

Ecosystem Usage and Client Support

NIP-04 is a deprecated standard for end-to-end encrypted direct messages (DMs) on Nostr, using a shared secret derived from the sender's and recipient's keys.

01

Core Encryption Mechanism

NIP-04 uses a symmetric encryption scheme. The sender generates a shared secret using ECDH (Elliptic Curve Diffie-Hellman) from their private key and the recipient's public key. The plaintext message is then encrypted with AES-256-CBC, and the Initialization Vector (IV) is prepended to the ciphertext in the format: {IV}{ciphertext}. This encrypted payload is stored as a kind 4 event on relays.

02

Client Implementation & Usage

Clients implementing NIP-04 must handle key derivation, encryption, and decryption. The process involves:

Deriving the shared secret via secp256k1 ECDH.
Using the SHA256 hash of the secret as the AES key.
Managing IV generation for CBC mode.
Formatting the event content correctly. Popular clients like Damus, Amethyst, and Iris historically supported NIP-04, though many now recommend newer standards.

03

Security Limitations & Deprecation

NIP-04 is considered deprecated due to several cryptographic weaknesses:

No authentication: The ciphertext lacks a Message Authentication Code (MAC), making it vulnerable to malleability and padding oracle attacks.
Metadata exposure: While message content is encrypted, the fact that a DM occurred, the participants, and timestamps are public on relays.
Key management: Relies on clients securely handling private keys and derived secrets. The community now favors NIP-44 for its stronger authenticated encryption.

04

Event Structure Example

A NIP-04 encrypted DM is a standard Nostr event with specific fields:

json
{
  "kind": 4,
  "pubkey": "<sender_public_key>",
  "tags": [["p", "<recipient_public_key>"]],
  "content": "<IV><encrypted_ciphertext>",
  ...other_event_fields
}

The "p" tag identifies the recipient. The content is the base64-encoded concatenation of the 16-byte IV and the AES-CBC encrypted message.

05

Migration to NIP-44

NIP-44 is the modern, recommended replacement. It addresses NIP-04's flaws by:

Using XChaCha20-Poly1305 for authenticated encryption.
Implementing a more secure HKDF-based key derivation.
Including a version byte for future-proofing. Clients are encouraged to support both during transition, with NIP-04 flagged as legacy. Developers should implement NIP-44 for all new direct messaging features.

EXPLORE

06

Relay Role and Privacy

Relays play a passive but critical role. They:

Store and broadcast the encrypted kind 4 events to all connected clients.
Cannot decrypt messages without the private keys.
Can observe social graph metadata (who messages whom and when). For enhanced metadata privacy, techniques like NIP-17 (gift wraps) or NIP-59 (sealed direct messages) are used, which encrypt the entire event for a specific recipient.

ENCRYPTED DIRECT MESSAGES

Comparison: NIP-04 vs. NIP-44

A technical comparison of the two primary Nostr protocols for private messaging, detailing their cryptographic foundations, security properties, and implementation details.

Feature / Metric	NIP-04 (Legacy)	NIP-44 (v2)
Cryptographic Standard	AES-256-CBC with ECDH (secp256k1)	XChaCha20-Poly1305 with ECDH (secp256k1)
Key Derivation	SHA-256 single hash	HKDF with SHA-256 (multiple rounds)
Authentication	No message authentication (CBC malleable)	Poly1305 AEAD (authenticated encryption)
Initialization Vector (IV)	Random 16 bytes, sent in plaintext	Deterministic from shared key and conversation nonce
Padding Scheme	PKCS7 padding	No padding required (stream cipher)
Metadata Protection	None (content only)	None (content only)
Standardization Status	Deprecated	Recommended standard
Implementation Complexity	Medium (padding, IV handling)	Low (uses modern libsodium primitives)

common-misconceptions

NIP-04

Common Misconceptions

Clarifying widespread misunderstandings about the first standardized method for private messaging on Nostr.

01

Not Truly End-to-End Encrypted

NIP-04 uses symmetric AES-256-CBC encryption, which is secure, but the protocol itself does not provide perfect forward secrecy. Each message uses a shared secret derived from the sender's and recipient's keys. If this secret is compromised, all past messages encrypted with it can be decrypted. This differs from modern E2EE systems like Signal, which use the Double Ratchet Algorithm to frequently rotate keys.

02

Metadata Is Not Private

While message content is encrypted, all metadata remains public on the relay network. Anyone can see:

Who is messaging whom (public keys of sender and recipient)
The timestamp of the message
The fact that an encrypted message was sent This lack of metadata privacy is a fundamental characteristic of the current Nostr protocol, not a flaw in NIP-04 specifically.

03

Relays See Encrypted Blobs

A common fear is that relay operators can read messages. They cannot decrypt the content if implemented correctly. However, relays do see and store the encrypted payload. A malicious relay could:

Log and store all ciphertext indefinitely
Perform traffic analysis
Refuse to store or forward encrypted events Users must trust relays for availability and censorship resistance, but not for content confidentiality.

04

Key Management Is User Responsibility

NIP-04 does not specify key exchange or storage. The security of the encrypted channel depends entirely on users:

Securely exchanging the initial shared secret (often done via a Diffie-Hellman key exchange, secp256k1)
Safeguarding their private keys
Using client software that implements encryption correctly If a user's private key is lost, all messages are unrecoverable. If it's stolen, all future messages can be read.

05

It's Not The Only (Or Best) Option

NIP-04 is an early, simple standard. Newer NIPs offer improvements:

NIP-44: Uses a more modern XChaCha20-Poly1305 encryption scheme with better authentication and versioning.
NIP-59: Enables gift wraps for indirect, sealed messages, adding a layer of relay privacy. Developers are encouraged to implement newer standards, while NIP-04 remains for backward compatibility.

06

Encryption ≠ Authentication

NIP-04 ensures a message is private but does not cryptographically prove who the sender is to the recipient. The event is signed, verifying it came from the sender's key, but there is no recipient-side authentication. A sophisticated attacker could potentially replace a ciphertext in transit without the recipient knowing the content was altered, as the signature would still be valid for the original plaintext.

NIP-04

Frequently Asked Questions (FAQ)

Common questions about NIP-04, the Nostr protocol standard for encrypted direct messaging.

NIP-04 is a protocol specification within the Nostr ecosystem that defines a method for sending encrypted direct messages (DMs) between users. It works by using a shared secret derived from the sender's and recipient's public keys to encrypt message content using symmetric AES-256-CBC encryption. The encrypted payload and initialization vector (IV) are then published as a special kind of Nostr event (kind 4) to relays, where only the intended recipient, who possesses the corresponding private key, can decrypt and read it. This ensures private communication over Nostr's otherwise public relay network.

Encrypted Direct Message (NIP-04)

What is Encrypted Direct Message (NIP-04)?

Etymology and Origin

How NIP-04 Works

Key Features of NIP-04

End-to-End Encryption

Event Structure & Payload

Key Derivation (ECDH)

Relay-Agnostic Privacy

Limitations & Considerations

Client Implementation