The Invisible Internet Project, known as I2P, is a peer-to-peer anonymity network. It has run quietly for over two decades, serving people who want to share files, host hidden services, and chat without revealing who or where they are. While Tor gets most of the attention in the privacy world, I2P takes a different path. It uses a technique called garlic routing, layered on top of distributed peer discovery, to make traffic analysis very hard.
But like every network that relies on public-key cryptography, I2P has a quantum problem. The keys it uses to build tunnels, exchange session secrets, and sign router records were designed before anyone seriously considered cryptographically relevant quantum computers. If a quantum adversary records I2P traffic today, they could decrypt it years from now once the hardware exists. That is the harvest-now-decrypt-later threat applied to anonymity.
This article walks through how I2P works under the hood, where its cryptography sits, what garlic routing actually means, and how the project is thinking about post-quantum migration.
What I2P Actually Is
I2P is a fully distributed, packet-switched mix network. Every participant runs a router. Routers exchange information about each other through a distributed hash table called the network database, or netDb for short. When you want to talk to someone, your router does not connect directly. Instead, it sends your messages through a chain of other routers, encrypting each layer so that no single hop sees both who sent the message and who received it.
The official I2P site at geti2p.net describes the network as built for hidden services first, with regular internet access as a secondary feature. This is the opposite of Tor, which is primarily an anonymizing proxy to the regular internet. I2P assumes both endpoints are inside the network. Hidden services in I2P are called eepsites, and they have addresses ending in .i2p.
Each user has one or more long-term cryptographic identities, called destinations. A destination is essentially a public key plus some metadata. To reach a destination, your router queries the netDb, finds the leaseSet for that destination, and learns which inbound tunnels to use to deliver messages.
How Tunnels Are Built
Tunnels are the basic transport in I2P. Each router maintains pools of tunnels, both inbound (used to receive messages) and outbound (used to send them). A tunnel is a chain of three or more routers (configurable, though most users keep the default), and each router along the chain only knows the previous and next hop, never the full path.
To build a tunnel, the originating router sends a build request through a series of hops. Each hop encrypts and forwards the request, performing a Diffie-Hellman exchange so that the originator ends up sharing a separate session key with each hop. After the build is complete, traffic flowing through the tunnel is encrypted in layers, peeling off one layer at each hop. The final layer is decrypted by the endpoint of the tunnel, where the actual payload is processed.
Historically, I2P used 2048-bit ElGamal for tunnel build encryption and 1024-bit DSA for router signatures. Both are completely broken under Shor's algorithm. Even modern variants based on elliptic curves (Ed25519, X25519) are vulnerable to a sufficiently powerful quantum attacker, which is exactly the threat the cryptographic community is preparing for. To learn more about the underlying threat model, see our what is post-quantum cryptography primer.
Around 2019, I2P introduced ECIES-X25519-AEAD-Ratchet, a major upgrade that replaced ElGamal with X25519 plus ChaCha20-Poly1305 and added a forward-secret double ratchet inspired by the Signal protocol. This was a huge improvement for forward secrecy, but it is still classical elliptic-curve cryptography under the hood.
What Garlic Routing Means
Onion routing wraps a single message in nested layers of encryption, like the layers of an onion. Garlic routing extends this idea by bundling multiple messages, called cloves, into a single garlic message. Each clove can have its own destination, instructions, and delay. From the outside, all you see is one encrypted blob entering the network.
This bundling has practical benefits. It hides ack messages alongside data, masks request and response patterns, and lets the network insert dummy traffic without adding new packet types. To a passive observer, ten messages and one dummy look identical to ten messages and zero dummies.
For a passive adversary trying to do traffic correlation, garlic routing is harder to analyze than pure onion routing. The size and timing of cloves can be padded and delayed independently, which weakens correlation across multiple hops. This matters because traffic analysis, not direct cryptographic attack, is the most realistic threat to most anonymity networks today.
But the cloves still need to be encrypted. Today, that encryption uses X25519 for the key agreement and ChaCha20-Poly1305 for the symmetric layer. Both halves face quantum risk, though for different reasons. X25519 is directly vulnerable to Shor's algorithm. ChaCha20-Poly1305, like AES-GCM, is symmetric and only loses half its security to Grover's algorithm. Practically, ChaCha20 with a 256-bit key still has 128 bits of post-quantum security, which is fine.
The key exchange is the urgent part. To understand why, see our deep dive on harvest now, decrypt later.
The NetDb and Router Identities
I2P routers identify themselves with long-lived signing keys. Older versions used DSA-1024, which has been deprecated for years. Modern routers use Ed25519. Every router publishes a signed router info record into the netDb, and other routers verify that signature before trusting the record. If an attacker can forge router info records, they can pollute the netDb with malicious routers and steer tunnel builds toward their own infrastructure.
LeaseSets, the records that describe how to reach a destination, are also signed. LeaseSet 2 added support for newer signature types, and there is ongoing work on LeaseSet 3, which is designed to be flexible enough to carry post-quantum signatures.
For the post-quantum migration, both router signatures and leaseSet signatures need to be replaced. The natural candidates are the NIST-standardized algorithms: ML-DSA for routers (it has fast verification, which is what netDb operations need) and either ML-DSA or Falcon for leaseSets (smaller signatures help with leaseSet size limits). Our ML-DSA versus SLH-DSA comparison walks through the trade-offs.
Why I2P Migration Is Hard
I2P faces three challenges that make a post-quantum upgrade trickier than it sounds.
The first is bandwidth. ML-KEM-768 ciphertexts are around 1088 bytes, compared to 32 bytes for an X25519 public value. ML-DSA-65 signatures are around 3309 bytes, compared to 64 bytes for Ed25519. Tunnel build messages, which are sent constantly, would balloon. Many I2P users are on low-bandwidth links, and the network as a whole runs on volunteer routers with modest pipes.
The second is computational cost. Tunnel hops do many cryptographic operations per second. ML-KEM is fast on modern CPUs, but on the older hardware that some volunteer routers use, the difference adds up. ML-DSA verification is fast (hundreds of microseconds on a modern CPU), but signing is slower than Ed25519.
The third is backward compatibility. I2P has many users running old versions, and the netDb has to accommodate routers with different cryptographic capabilities for years during transition. Hybrid approaches, where keys carry both classical and post-quantum components, are the obvious answer. Our hybrid encryption explainer covers the design pattern.
What the I2P Project Is Working On
The I2P+ fork and the upstream Java I2P project both have active discussions about post-quantum migration. Public proposals on geti2p.net mention experimenting with ML-KEM in tunnel build messages, possibly behind a feature flag, and adding ML-DSA as a router signature type alongside Ed25519. Both upgrades would be hybrid initially, meaning every tunnel build does both an X25519 and an ML-KEM exchange and combines the resulting secrets. That way, even if one algorithm fails, the other carries the security.
LeaseSet 3 work has been progressing in I2P specifications. The format is being designed to allow new key types without changing the wire format every time. This is the right move. Cryptographic agility is essential because we will probably see more post-quantum algorithms standardized over the next decade.
C++ I2P (i2pd), an alternative implementation, has historically moved faster on cryptographic upgrades. It already supports ECIES-X25519-AEAD-Ratchet across the board, and adding post-quantum primitives would slot into that infrastructure cleanly. The two implementations need to stay compatible at the wire level, so any post-quantum work has to be coordinated.
Side Channels and Implementation Hazards
When new cryptographic primitives go into a high-volume network like I2P, side-channel risks matter. ML-KEM has documented constant-time implementations in liboqs and the reference code from the NIST submission. Falcon has well-known timing risks because its sampler relies on floating-point operations, which is one reason ML-DSA tends to be the safer choice for large deployments.
I2P routers run on diverse hardware: x86 servers, ARM single-board computers, even old Raspberry Pis. Constant-time guarantees on one platform do not always translate to another. Compiler optimizations can also reintroduce timing leaks even into well-written code. Any post-quantum I2P deployment needs careful per-platform testing. To dig into the architecture-specific issues, see our PQC on ARM Cortex-M and PQC on RISC-V articles.
What Users Should Do Today
If you use I2P for serious anonymity, the practical advice is to keep your router updated, enable ECIES-X25519-AEAD-Ratchet (the modern default), and pay attention to release notes. The transition will not happen overnight, but the project is moving in the right direction.
If you are running an eepsite that holds sensitive data at rest, do not rely on I2P alone. Encrypt your data with a tool that already uses NIST-standardized post-quantum algorithms. Even if your transport gets recorded today and decrypted in 2035, the underlying files should still be opaque.
QNSQY uses ML-KEM-1024 with X25519 in hybrid mode and ML-DSA-87 with Ed25519 for signatures. That means files encrypted today survive both classical and quantum adversaries. For background on why that combination was chosen, our NIST FIPS guide walks through the standards.
FAQ
Is I2P quantum-safe today? No. The current cryptographic primitives (X25519, Ed25519, ChaCha20-Poly1305) are strong against classical attackers but not against a sufficiently large quantum computer. The symmetric layer (ChaCha20) survives Grover's algorithm with reasonable margin, but the key exchange and signatures do not survive Shor's algorithm.
When will I2P add post-quantum support? There is no public timeline. The project is small, mostly volunteer-driven, and any change has to maintain compatibility with old routers. Expect experimental flags in the coming years before default migration. The work depends on volunteer effort.
Is garlic routing better than onion routing? For traffic analysis resistance, yes, marginally. Garlic routing makes correlation harder by bundling multiple messages and inserting dummies. For end-to-end confidentiality, both rely on the same kinds of layered encryption, so the differences are mostly about traffic patterns, not raw cryptographic strength.
Can I use I2P and a post-quantum cryptography tool together? Yes, and you should. Encrypt files with a tool that uses ML-KEM and ML-DSA before sending them through I2P. That way, even if the I2P layer is broken in the future, your files stay protected. This defense-in-depth approach is the only sensible strategy when you do not control the network's cryptography.
What about tunnel rotation as a defense? I2P rotates tunnels frequently, typically every 10 minutes. This limits the value of harvested data because each tunnel only carries traffic for a short window. But the long-term router and destination keys do not rotate as often, so a quantum adversary who breaks one of those still gets persistent access.
Sources
- NIST Post-Quantum Cryptography Project (FIPS 203, 204, 205): https://csrc.nist.gov/projects/post-quantum-cryptography
- I2P Project Documentation: https://geti2p.net/en/docs
- I2P Network Database Specification: https://geti2p.net/en/docs/how/network-database
- I2P Tunnel Implementation: https://geti2p.net/en/docs/tunnels/implementation
- ECIES-X25519-AEAD-Ratchet Specification (Proposal 144): https://geti2p.net/spec/proposals/144-ecies
- NIST Special Publication 800-208 (Stateful Hash-Based Signatures): https://csrc.nist.gov/pubs/sp/800/208/final
Related Articles
- What is Post-Quantum Cryptography
- Harvest Now, Decrypt Later
- ML-KEM Explained
- Hybrid Encryption
- NIST FIPS Guide
Protect Your Data Before Q-Day Arrives
QNSQY's NIST-standardized post-quantum encryption protects files against both current and quantum-era threats.