NIP-44 (Versioned Encryption)

NIP-44 is the Nostr Improvement Proposal that defines versioned, keypair-based encryption for event payloads. It exists to replace the legacy NIP-04 direct-message encryption, which had known weaknesses, and is the cryptographic primitive that newer private-messaging standards on Nostr build on. The specification is careful to scope itself: it defines only how bytes are encrypted between two keypairs, not how messages are structured or which event kinds carry them — a deliberate separation of primitive from protocol.

Why NIP-04 had to go

The original NIP-04 scheme encrypted DM content but did so with dated constructions and no message authentication, and it leaked message length outright. Unauthenticated encryption means a tampered ciphertext may decrypt to garbage without detection; length leakage means an observer can distinguish "yes" from a paragraph. NIP-44 was designed — with review from applied cryptographers — to give the ecosystem a modern, versioned primitive with authenticated encryption and reduced metadata leakage, and to be simple enough to implement consistently across the many independent Nostr clients and signers.

How version 2 works

The currently deployed version (0x02) derives a conversation key via ECDH scalar multiplication over the same secp256k1 curve that Nostr identities (and Bitcoin keys) live on, then expands it with HKDF-SHA256; per-message keys are derived from that key and a random nonce. Symmetric encryption uses ChaCha20, chosen for speed and resistance to multi-key attacks, and integrity is protected by HMAC-SHA256 (preferred over polynomial MACs, which are easier to forge). A custom power-of-two padding scheme pads plaintext to a minimum of 32 bytes, reducing length leakage on short messages, and the result is Base64-encoded. The leading version byte lets the scheme evolve without breaking older clients — the "versioned" in the name is the upgrade path NIP-04 never had. The design has also been independently audited.

What it does not protect

The authors are explicit about limits, and honest tooling should repeat them. NIP-44 provides no deniability (signatures prove authorship), no forward secrecy (a leaked key exposes past messages), no post-compromise security, and no post-quantum security. It also does not hide metadata: the created_at timestamp, sender and recipient public keys, and event structure remain public unless an outer protocol conceals them. That metadata gap is exactly what gift-wrapping and the private-message stack address on top of NIP-44 — the primitive encrypts bytes; hiding who is talking to whom requires the layers above.

Why sovereign users should care

For implementers, the spec's practical guidance is blunt: use an existing audited library rather than composing the primitives yourself, and validate against the published test vectors, because the failure modes of hand-rolled cryptography are silent. The version byte earns its keep here as well — a client encountering an unknown version should refuse loudly rather than guess, and the ecosystem can migrate to a version 3 someday (post-quantum, forward-secret, or otherwise) without a coordinated flag day. That upgrade path, mundane as it sounds, is the structural lesson NIP-04's dead end taught the protocol: primitives age, and a protocol that cannot rotate its cryptography gracefully is a protocol with an expiry date.

For Bitcoiners running their own clients, relays, and signers, understanding this primitive clarifies what private Nostr messaging actually guarantees — and what it does not. The security model ultimately reduces to the same key that signs your notes: encryption is only as safe as the private key behind it, which is why NIP-44 operations are typically delegated to a NIP-07 signer or remote signer rather than handled by web-page code. See NIP-59 (Gift Wrap) for the metadata-hiding layer and NIP-17 (Private Direct Messages) for the full DM stack that consumes it.