Practical Attacks on Nostr, a Decentralized Censorship-Resistant Protocol

Practical Attacks on Nostr, a Decentralized Censorship-Resistant Protocol

Speaker: Hajime Kumagai (Researcher, NICT, Japan) — joint work with researchers from NICT, NEC Corp, University of Chicago, and University of Osaka

Conference: Black Hat USA 2025 — August 6-7, 2025, Mandalay Bay, Las Vegas

YouTube: https://www.youtube.com/watch?v=O97xhyHFSsw

Reading time: 8 minutes

Type: Briefing

TL;DR

Researchers from NICT and collaborating institutions conducted the first full security analysis of Nostr — a decentralized, cryptography-based social networking protocol with over 1.1 million user accounts — and found seven vulnerabilities enabling eight distinct attacks. Findings include signature verification bypasses across multiple clients, a CBC-mode bit-flipping attack against encrypted direct messages enabled by a cross-protocol key reuse flaw, and a link-preview oracle that allows an attacker to recover plaintext from encrypted messages without breaking the encryption algorithm. The research took two years and involved coordinated disclosure with developers.

Introduction

Censorship-resistant social media has become an active battleground. Centralized platforms can suspend accounts, modify content policies, and comply with government takedown orders. Federated alternatives like Mastodon distribute authority across servers, but user identity is still anchored to those servers. Nostr takes a more radical approach: users hold their own cryptographic key pairs as identity, and relays — anyone can run one — simply forward signed events without owning or controlling user data.

This shift in architecture offers genuine freedom, but it creates a security assumption that is easy to miss: in a system with no trusted central authority, the entire burden of verification falls on client software. Every client must validate every event it receives. If even a few popular clients skip or improperly implement signature checks, the protocol's cryptographic guarantees collapse — and attackers can forge posts, hijack profiles, intercept encrypted messages, and redirect Bitcoin payments.

Hajime Kumagai of NICT presented findings from the first comprehensive security analysis of Nostr at Black Hat USA 2025, covering 56 protocol specifications (NIPs) and nine clients — both open source and proprietary — with practical demonstrations of each attack category.

▶ Watch: Introduction and Nostr Architecture Overview (00:00)

Nostr's Cryptographic Architecture

Nostr's security rests on four core specification areas. The base NIP defines the event structure and mandates that every event be signed with the author's secp256k1 private key. NIP-04 specifies encrypted direct messages using ECDH for key agreement and AES-CBC for message encryption. NIP-26 provides a delegation mechanism for multi-device sign-in, allowing a user to authorize another key pair to act on their behalf. NIP-57 defines a micro-payment protocol for tipping other users with Bitcoin through the Lightning network.

A critical design decision: the Nostr specification does not require relay servers to verify event signatures. Some relay implementations check signatures to filter spam, but this is an optimization for the relay's own storage — not a security guarantee for clients. The protocol explicitly positions relays as untrusted forwarders. Therefore, any client that expects relay-side verification to substitute for client-side verification is operating on a false assumption.

▶ Watch: Nostr Specification and Cryptographic Design (02:00)

Attack Category 1: Signature Verification Bypass

The most fundamental and widespread finding was that many Nostr clients either skip signature verification entirely or implement it incorrectly.

Complete omission. Several clients — particularly mobile apps — accept and display events without ever checking the cryptographic signature. Kumagai showed code examples from multiple clients where there is simply no signature verification call. The rationale offered by some developers: on mobile devices, constant signature verification drains battery. The consequence is that any relay (or attacker with relay access) can inject arbitrary forged events that appear indistinguishable from legitimate posts.

Cache poisoning bypass in Damus (iOS). Damus, one of the most popular iOS Nostr clients, appeared at first to implement proper signature verification. On closer inspection, the researchers found that the verification function was gated by a cache lookup. If an event ID had been verified before, the function returned true immediately without re-verifying. If the event ID was not in the cache, it performed standard ECDH signature verification.

The attack exploits this by sending a forged event with the same event ID as a legitimate event that has already been cached as verified. The attacker changes the event content — for example, replacing a Bitcoin Lightning address in a public profile with the attacker's own address — while keeping the event ID unchanged. When the client receives the forged event, the cache lookup finds the ID already marked as verified and returns true without inspecting the new content.

Mitigation: when an event ID is found in the cache, clients must also verify that the event content hashes to that ID — since the event ID in Nostr is a SHA-256 hash of the event's canonical fields. This is a single additional hash computation that fully defeats the cache poisoning attack.

"Many clients even skip signature checks, so they do not verify signatures," Kumagai noted. "It is especially dangerous for profile events because profiles contain the Bitcoin address for users."

▶ Watch: Signature Verification Bypass and Damus Cache Poisoning (10:01)

Attack Category 2: Ciphertext Integrity Failure in Encrypted Direct Messages

NIP-04 encrypted direct messages use AES-CBC for encryption. CBC mode provides confidentiality but no ciphertext integrity — it does not detect whether the ciphertext has been tampered with. When signature verification is absent (as documented above), an attacker can manipulate the ciphertext of an encrypted message.

The basic CBC bit-flipping attack is well understood: an attacker who flips bits in the initialization vector (IV) can cause predictable, controlled changes in the first block of plaintext upon decryption. However, uncontrolled flipping in later blocks produces garbled output, and an attacker who does not know the plaintext cannot reliably craft a meaningful modification.

Cross-protocol known-plaintext attack. The researchers identified that Nostr's key reuse between direct messaging (NIP-04) and the delegation protocol (NIP-26) creates a pathway to obtain known plaintext/ciphertext pairs. The delegation flow uses the same ECDH key agreement as direct messages and sends structured metadata in a predictable format. An attacker who can trick a victim into scanning a manipulated QR code (one that embeds both the victim's expected delegation target and the attacker's endpoint) can observe the delegation session and extract known plaintext-ciphertext pairs from the metadata exchange. With this known pair, the attacker can compute the XOR difference and use it to craft targeted modifications to direct message ciphertext — replacing, for example, "send me the file" with "send me Bitcoin."

This attack has concrete implications for any Nostr client that follows the NIP-04 standard: encrypted direct messages can be tampered with by an attacker who has not broken the encryption key, simply by exploiting the lack of message authentication.

The fix: use authenticated encryption (AES-GCM or ChaCha20-Poly1305) instead of unauthenticated CBC mode, and maintain strict key separation between the messaging identity key and the delegation key.

▶ Watch: CBC Ciphertext Integrity Attack (16:02)

Attack Category 3: Link Preview Oracle for Plaintext Recovery

Many Nostr clients support link previews — when a message contains a URL, the client automatically fetches the page metadata and renders a preview card. The researchers identified that this behavior, combined with the ciphertext malleability described above, creates a plaintext recovery oracle.

The attack targets messages containing secret URLs — such as invitation links for private meetings, shared cloud storage links, or other tokens embedded in URLs. The oracle works as follows:

1. The attacker observes that an encrypted message was sent (e.g., by monitoring network traffic or a relay they control).
2. The attacker manipulates the ciphertext to redirect the URL domain — using the CBC bit-flip technique — from the legitimate server to an attacker-controlled server, while preserving the secret path and token portion of the URL.
3. When the victim's client decrypts the message, it automatically fetches the preview for the now-redirected URL, sending the secret token as part of the HTTP request to the attacker's server.
4. The attacker reads the secret token from their server's access logs.

For full plaintext recovery beyond the URL, the researchers extended the technique using the Oracle's response as a feedback channel for byte-by-byte brute force. By flipping individual bytes in the IV and observing whether the preview request fires — indicating a valid HTTP URL prefix — the attacker can recover the plaintext character by character. The technique mirrors classical padding oracle attacks but uses a link preview network request as the oracle signal rather than a decryption error.

"Can an attacker still learn the plaintext even if the encryption algorithm is strong and safe?" Kumagai asked. "The answer is yes. We can use link preview for another oracle."

▶ Watch: Link Preview Oracle for Plaintext Recovery (22:02)

Disclosure and the Unique Challenge of Decentralized Security

The research team spent two years working with developers on coordinated disclosure. The multi-client, multi-community nature of Nostr created challenges that centralized platforms do not face. A vulnerability in Signal can be patched in a single codebase with a forced update deployed globally within weeks. A vulnerability in Nostr requires independent developer communities — some hobbyist, some commercial — to update their clients on independent timelines with no central authority to mandate updates.

"In centralized systems, fixes can be deployed quickly. But in decentralized ones, many clients are developed by different communities, so it is difficult to fix vulnerabilities at the same time," Kumagai explained. "We need to get the design right from the start."

The researchers proposed several forward-looking design improvements: mandatory, well-specified signature verification rules in the protocol specifications (not just "sign it," but "verify it this way"); strict key separation between messaging, delegation, and payment protocols; a zero-trust client model where every event from every relay is verified regardless of source; and migration from CBC-based encryption to authenticated encryption primitives.

▶ Watch: Takeaways and Decentralized Security Design Principles (26:03)

Notable Quotes

"Many clients even skip signature checks, so they do not verify signatures. It is especially dangerous for profile events because profiles contain the Bitcoin address for users." — Hajime Kumagai [10:01]

"The lack of the verification of the signature is very simple, but it is very impactful on SNS." — Hajime Kumagai [12:02]

"Can an attacker still learn the plaintext even if the encryption algorithm is strong and safe? The answer is yes. We can use link preview for another oracle." — Hajime Kumagai [22:02]

"Strong cryptographic algorithms are not enough. We need good code and a better cryptographic protocol design to make a decentralized system secure." — Hajime Kumagai [32:03]

Key Takeaways

• Missing signature verification is systemic: Multiple Nostr clients — especially mobile apps — skip signature checks entirely or allow cache poisoning to bypass them, enabling event forgery across all content types including profiles and encrypted messages.
• CBC mode without authentication is exploitable: NIP-04 encrypted direct messages use AES-CBC with no message authentication, making them vulnerable to bit-flipping attacks that can alter message content without knowing the key.
• Key reuse between protocols enables cross-protocol attacks: Sharing ECDH key material between direct messaging and delegation (NIP-26) creates a known-plaintext oracle that powers targeted ciphertext manipulation.
• Link previews become decryption oracles: Client-side link preview fetching leaks secret URL tokens to attackers who can manipulate ciphertext — and enables full plaintext recovery via a byte-by-byte brute-force technique.
• Decentralized protocols require stronger upfront specifications: Without a central authority to mandate updates, cryptographic implementation rules must be unambiguous in the protocol spec itself — incomplete specifications lead to divergent, insecure client implementations that cannot be patched simultaneously.

Slides

No slides PDF was available for this briefing.