Introduction

The Blend Protocol provides network-level privacy for the Logos Blockchain by hiding the link between block proposers and their proposals. It achieves this through multi-layered encryption, verifiable random blending path selection, and timing obfuscation. At the protocol level, Blend depends on a small set of abstract cryptographic primitives: digital signatures for message authentication, a key agreement (or key encapsulation) mechanism for establishing shared secrets between sender and receiver, a stream cipher for symmetric encryption of headers and payloads, and zero-knowledge proofs for rate-limiting and access control. The protocol's privacy and integrity guarantees rest on these abstract primitives, not on any specific instantiation of them.

The current implementation, however, instantiates these primitives entirely with elliptic-curve-based constructions: Ed25519 for digital signatures, X25519 for key agreement, BN254 pairings with Groth16 for zero-knowledge proofs, and a BLAKE2b-keyed PRNG for the stream cipher. Among these, the elliptic-curve and pairing-based constructions are all vulnerable to quantum adversaries: Shor's algorithm solves both the integer factorization problem and the discrete logarithm problem (including the elliptic curve variant and the variant in pairing groups) in polynomial time on a sufficiently large quantum computer. This means that the cryptographic assumptions underlying the current instantiations — the hardness of the Elliptic Curve Discrete Logarithm Problem (ECDLP) and the Discrete Logarithm Problem in BN254 pairing groups — will no longer hold once Cryptographically Relevant Quantum Computers (CRQCs) become available.

Crucially, this is an issue at the implementation level, not at the protocol level. The protocol still needs the same abstract primitives; only their concrete instantiations must change. The migration analyzed in this document consists of replacing each quantum-vulnerable instantiation with a quantum-resistant one — a post-quantum KEM in place of X25519 ECDH, a post-quantum signature scheme in place of Ed25519, and a post-quantum ZK proof system in place of Groth16/BN254 — while keeping the protocol structure intact.

The purpose of this document is to:

1. Identify every quantum-vulnerable cryptographic component in the current implementation of Blend Protocol.
2. Classify the nature of each vulnerability and its threat model (retroactive vs. real-time).
3. Propose post-quantum replacements with their implications on the protocol properties.

Threat Model Distinction: Retroactive vs. Real-Time Attacks

A critical distinction must be made between two classes of quantum threats:

Retroactive attacks (Harvest Now, Decrypt Later — HNDL): An adversary records encrypted communications today and decrypts them once a CRQC becomes available. This threat applies exclusively to confidentiality primitives — key exchange and encryption. For the Blend Protocol, this is the most urgent concern: if an adversary records Blend messages transiting through the network, a future CRQC could break the key exchange, derive all shared secrets, decrypt all encryption layers, and retroactively de-anonymize every recorded message. The unlinkability guarantees of the protocol would be entirely voided for all historical traffic.

Real-time attacks (Future Forgery): An adversary with access to a CRQC at the time of protocol execution can forge signatures, fabricate zero-knowledge proofs, and impersonate nodes. This threat applies to integrity and authentication primitives — digital signatures and ZK proofs. Crucially, this is NOT a retroactive threat: recording signatures or ZK proofs today provides no advantage to a future quantum adversary. Signatures and proofs are verified at the time of receipt; their purpose is fulfilled at that moment. A quantum adversary gains nothing by collecting old signatures — they would need real-time quantum capability to forge new ones.

An important nuance for zero-knowledge proofs: The threat classification of a ZK proof depends on its purpose within the protocol, not merely on the proof system itself. ZK proofs can serve two fundamentally different roles:

• ZK for confidentiality: When a ZK proof is used to hide sensitive data — for example, shielding transaction amounts and addresses as in Zcash — the hidden information (the witness) is the confidential asset being protected. Whether HNDL applies depends on the hiding property. For the systems with statistical/perfect zero-knowledge (e.g., Groth16), the proof leaks no witness information even to an unbounded adversary, so a recorded proof is not itself HNDL-exposed; the actual confidentiality surface is the associated encryption or commitment layer, which is where the confidential data resides and which a CRQC could retroactively open. HNDL applies when that hiding layer rests on a quantum-vulnerable assumption.
• ZK for integrity and authentication: When a ZK proof is used to prove authorization, compliance, or membership — for example, proving that a node is within its messaging quota — the proof does not protect long-term secrets. The witness (e.g., a secret key, a Merkle path) may be private, but its disclosure does not compromise the confidentiality of the protocol's protected data (the message payload and blending path information). The relevant threat is therefore not HNDL but real-time forgery: an adversary who can break the proof system's soundness once a CRQC exists could forge proofs of false statements. Breaking an old proof retroactively gains nothing — it merely confirms an authorization that was already established when the message was accepted and relayed.

In the Blend Protocol, the PoQ is used for integrity and authentication (rate-limiting, core node membership, leadership eligibility). The PoQ does have a hiding dimension over its witness — notably it conceals which branch the prover satisfied, i.e. whether the sender is acting as a core node or as a leader, alongside core_sk, index, and the Merkle paths. This hiding is preserved information-theoretically: because Groth16 is perfectly zero-knowledge, a recorded PoQ reveals nothing about the branch or any other witness element even to an unbounded quantum adversary, so there is no stored artifact a future CRQC could open. The only quantum-vulnerable property is soundness, which is computational; breaking it enables real-time forgery of fresh proofs but never extraction from old ones. The PoQ is therefore classified as subject to real-time forgery threat only, not HNDL.

This distinction has important implications for migration priority. The HNDL threat against encryption/key exchange is already active today for any adversary with storage capability. The forgery threat against signatures and ZK proofs only becomes active when CRQCs exist.

Migration phases. This document refers to four distinct migration phases throughout the analysis, corresponding to the two threat classes above:

• Phase 0 — Connection-level HNDL protection (TLS key exchange). Upgrade inter-node TLS connections to a hybrid PQ key exchange (e.g., X25519MLKEM768). This protects connection-level metadata — in particular the first hop from a sender to its first blend node, which is the link that ties a proposal back to the proposer's network identity. Deployable with minimal Blend-specific work since mature library support already exists (e.g., rustls-post-quantum).
• Phase 1 — Message-level HNDL protection (Blend message KEM). Replace the X25519 static-ephemeral key agreement in Blend's per-hop message encapsulation with a post-quantum KEM (or hybrid). This protects the message content and blending path independently of the transport layer: a message leaves its TLS tunnel at every hop, so only the per-hop Blend encryption keeps content and routing hidden from a path participant (or from any adversary that has broken the transport layer). Requires Blend message-format changes.