I2P Explained: Garlic Routing, Tunnels, netDb and How It Differs From Tor

I2P (the Invisible Internet Project) is an anonymity network built for services that live inside it. Every participant runs a router that builds short-lived, one-way inbound and outbound tunnels, bundles messages as "garlic", and finds peers through a distributed database kept by volunteer floodfill routers. Tor, by contrast, builds two-way circuits chosen from a list signed by directory authorities.

This post goes one level deeper than our pieces on running a Tor relay, Tails and its update model, Oblivious HTTP and why a VPN does not make you anonymous. It explains how the network works, what I2P's own threat model says it does not protect against, and how network defenders and software owners should think about it. Every technical detail comes from the I2P specifications and docs (the old geti2p.net addresses now redirect to i2p.net), the i2pd project's documentation and release notes, the Tor Project's own documentation, or the IETF. It is not a guide to hiding activity from anyone, and it links to no hidden services.

Key takeaways

• I2P is a packet switched "free route mixnet": the sender picks the outbound path, the receiver picks the inbound path, and tunnels last 10 minutes.
• Tunnels are one-way, so a message and its reply cross four tunnels. Tor uses one circuit in both directions.
• "Garlic routing" means layered encryption plus bundling several messages ("cloves") into one.
• The network database (netDb) holds only RouterInfos and LeaseSets, stored by floodfill routers in a DHT whose keys rotate daily at midnight UTC.
• New routers bootstrap from a signed i2pseeds.su3 file fetched from HTTPS reseed servers.
• The cryptography now runs on Noise: NTCP2 (2018), ECIES-X25519 end to end (2020) and SSU2 (2022), with post-quantum hybrids rolling out.
• I2P's own threat model says it is not designed to hide that a computer runs I2P. For enterprises it is an inventory and egress policy question.

What is I2P and what is it used for?

I2P describes itself as a "scalable, self organizing, resilient packet switched anonymous network layer" for applications to run on. Its threat model says the design started in 2003, and the introduction notes it was first written by the founding developer, jrandom, that year. The Tor Project's history page dates the first Tor deployment to October 2002, so the two grew up side by side on the same research.

The goal differs from Tor's. In I2P both ends of a conversation sit inside the network: a client talks to a "Destination" (a cryptographic identity, not an IP address) that is itself reached through tunnels. The introduction lists the typical uses: web browsing through a local proxy, hosting sites, IRC style chat, file sharing with the bundled I2PSnark client and email with SusiMail. The i2pd site describes the same split between peer to peer applications and client to server ones such as websites and messengers.

Java I2P, i2pd and the newer routers

Java I2P carries two version numbers. Users see the product version (2.14.0); the specifications use the API version (0.9.71). When the SSU2 spec says a feature was enabled in 0.9.56, it means the release that shipped as Java I2P 2.0.0 in November 2022. Record both in inventory notes.

Routers, Destinations and local ports

A router joins the network, relays traffic for others and publishes a signed RouterInfo. A Destination is an application's identity, and one router can host many. Applications reach their router through local ports. The I2P FAQ lists 4444 (HTTP proxy), 4445 (HTTPS proxy), 7654 (I2CP, "do not expose to an external network"), 7656 (SAM, off by default) and 7657 (router console). The i2pd configuration guide lists 7070 for its console, 4444 and 4447 for its HTTP and SOCKS proxies, and SAM, BOB, I2CP and I2PControl on 7656, 2827, 7654 and 7650 when enabled. Names map to Destinations through a locally unique address book, and base32 addresses take the form of 52 characters plus .b32.i2p, encoding the SHA-256 hash of a Destination.

How do I2P tunnels work?

An I2P tunnel is a temporary, one-way path through a sequence of routers. The tunnel routing overview names three roles: the gateway (first router; the creator for outbound tunnels, the router listed in the LeaseSet for inbound ones), the participants in the middle, and the endpoint (last router; the owner for inbound tunnels).

The docs follow a message from Alice to Bob. Alice sends it out one of her outbound tunnels with instructions for its endpoint to forward it to the gateway of one of Bob's inbound tunnels, which carries it to Bob. Bob replies through his own outbound tunnel into one of Alice's inbound tunnels. Hence the garlic routing page's line that "four tunnels are required for a single round-trip message and reply".

At build time each hop receives only what its role needs: tunnel layer and IV keys, a reply key and IV for the build response, its 4 byte tunnel ID, and the identity and tunnel ID of the next hop. Each hop learns its neighbours, not the path. The implementation spec says "tunnels themselves are short-lived (10 minutes)".

Tunnel length, pools and peer selection

Clients set tunnel length through I2CP options, up to a maximum of 7 hops.

Tunnels are grouped into pools for redundancy: exploratory pools for the router's own lookups and client pools for applications. Each tunnel is tested by sending a delivery status message out an outbound tunnel and back through an inbound one; tunnels that fail repeatedly are dropped and, for inbound client tunnels, a fresh LeaseSet is published. The peer selection doc sorts known peers into "fast" (capped at 30), "high capacity" (capped at 75) and "standard", and picks client tunnel hops randomly from the fast group.

Worked example: counting hops for one exchange

Assume Alice and Bob both use 3 hop client tunnels. One way, the message crosses three remote routers in Alice's outbound tunnel and three in Bob's inbound tunnel: six. The reply takes six more through Bob's outbound and Alice's inbound tunnels. I2P's comparison page calls this a "12-hop round-trip (6 inbound + 6 outbound)". The Tor glossary says most Tor circuits use three relays and "most onion services use six hops in a circuit", with one circuit carrying both request and response. The same I2P page puts I2P round trips at 1 to 3 seconds against roughly 200 to 500 milliseconds for Tor; those are the project's own figures, not independent measurements.

What is garlic routing?

The I2P docs warn that the project has used "garlic" loosely. The term comes from Michael J. Freedman, who coined it in Section 8.1.1 of Roger Dingledine's Free Haven master's thesis in June 2000 as an extension of onion routing. In I2P it means three things.

Layered encryption. The originator wraps a message in one layer per hop and each hop peels one, seeing only the instructions for the next hop. In this sense garlic routing is onion routing, which is why I2P can reuse onion routing research.

Bundling. Freedman's "bulbs" are I2P's "cloves". A garlic message can carry several cloves, each with its own delivery instructions for a Destination, a router or a tunnel. Usually there is one clove, but the router periodically adds a Delivery Status Message that returns to the sender as an acknowledgment, and a Database Store Message carrying the sender's LeaseSet so the far end can reply without a netDb lookup. Since 0.9.12 the acknowledgment is itself garlic wrapped so routers on the return path cannot read it.

The old encryption scheme. Older pages use "garlic encryption" for ElGamal/AES+SessionTags, now replaced by ECIES-X25519 (below). The garlic routing page itself is marked accurate for 0.9.12, so read its crypto references as history.

Two details are easy to get wrong. Tunnels are not built from garlic messages; tunnel encryption is a separate layer. And there is no "turning point" as in Mixmaster reply blocks: every path is one-way, so replies always use a separate pair of tunnels chosen by the other side.

How does I2P differ from Tor circuits?

Both use layered encryption over volunteer routers, and the I2P docs credit Tor research openly. The differences sit in path direction, who picks the path, peer discovery and where traffic ends up.

The Tor directory spec explains why Tor centralised discovery: after early versions trusted individual authorities, Tor moved to a single voted consensus so no one authority could mislead clients. The Tor glossary says the consensus is "voted on by the directory authorities once per hour". I2P's netDb page takes the other side: "Unlike Tor, where the directory servers are hardcoded and trusted, and operated by known entities, the members of the I2P floodfill peer set need not be trusted, and change over time." Each design trades one risk for another. Tor's authorities are a small, known, auditable trust base; I2P's floodfills avoid a central point but must resist Sybil routers clustering in the DHT.

Services differ too. Tor's onion services overview describes a service that picks introduction points, signs a descriptor with the key encoded in its onion address, uploads it to a DHT and meets the client at a rendezvous point. An I2P service publishes a LeaseSet listing its inbound tunnel gateways, and clients send garlic messages to them. I2P's comparison page argues that one-way tunnels mean "each participant only ever sees half of a communication flow"; treat that as a design argument, not a measured property.

How does the network database work?

The netDb page describes a distributed database holding "just two types of data": RouterInfos and LeaseSets. Each record is signed by its owner, verified by anyone who stores or uses it, and carries liveness information so stale entries drop out.

RouterInfo and capability letters

A RouterInfo is keyed by the SHA-256 of the router's identity and contains its keys, reachable addresses, a publication date, options and a signature. Capability letters tell other routers whether to connect or build tunnels through it.

"Shared bandwidth" is the share percentage times the lower of the inbound and outbound limits. Above the minimum threshold, the spec says, advertised bandwidth "is not used or trusted anywhere in the router" for selection, so lying about it gains little.

LeaseSet and its variants

A LeaseSet lists the current inbound tunnel gateways (leases) for one Destination, each with a gateway, tunnel ID and expiry, signed by the Destination. Release 0.9.38 added LeaseSet2 (several encryption types, offline signing keys), Meta LeaseSets (multihoming across many Destinations) and Encrypted LeaseSets, where the floodfill sees only a blinded key and an expiry. Client-only destinations, such as a browser proxy's tunnels, never publish their LeaseSet; servers reply using the copy bundled in the client's garlic messages.

Floodfill routers

The netDb is "distributed with a simple technique called floodfill":

• Floodfill turns on automatically only for routers configured with high bandwidth, currently at least 128 KBytes/sec shared, that also pass health tests such as queue time and job lag. Routers volunteer when floodfills are scarce and step back when there are too many.
• The page says about 6% of routers are floodfills and, in older text, "around 1700"; treat both as approximate.
• Floodfills "have no central authority and do not form a consensus". Their only extra job is accepting stores and answering lookups.
• Storing. A router sends its RouterInfo directly to the closest floodfill. LeaseSets go through an outbound client tunnel, garlic encrypted so the tunnel endpoint cannot read them.
• Flooding. A floodfill that accepts a newer valid entry sends it directly to the three floodfills closest to its routing key, which do not re-flood. Expired LeaseSets and RouterInfos older than an hour are never flooded.
• Lookups. Routers ask the two closest working floodfills in parallel through exploratory tunnels. LeaseSet lookups and replies are garlic encrypted; the page notes RouterInfo lookups are not.
• Segmentation. Java I2P and i2pd keep a main netDb plus a separate "client network database" per client, so entries that arrive down a client tunnel are only answered down that tunnel. This blocks probing that would link a Destination to its router.

Worked example: the daily routing key

Kademlia measures closeness by XOR distance. To stop attackers parking identities next to a target forever, I2P hashes the 32 byte search key together with the UTC date as an 8 character string yyyyMMdd:

• On 26 October 2026 the routing key is SHA-256 of the key followed by the bytes of "20261026".
• At 00:00 UTC on 27 October the string becomes "20261027", the routing key changes completely, and a different set of floodfills becomes closest.
• Only search keys rotate, not floodfill hashes, and routing keys never go on the wire.

The docs are candid that "recent research demonstrates that the keyspace rotation is not particularly effective": attackers can precompute hashes, and a few routers can "eclipse" part of the keyspace. Rotation raises cost; it does not stop a determined Sybil.

Worked example: which routers become floodfills

128 KBytes per second is roughly 1 Mbit/s of shared capacity. The desktop still relays tunnels; it just never stores the database.

How does a new router bootstrap?

A fresh router knows nobody. The netDb page says it needs "at least one reference to a peer" and gets it by "reseeding": downloading RouterInfo files that volunteers publish on the ordinary web from URLs hardcoded in the router.

Since 0.9.14 the reseed data is a single signed file, i2pseeds.su3, and since 0.9.42 requests append ?netid=2 (the production network ID) so test networks stay separate. The update spec defines the su3 header: the magic bytes I2Psu3, a signature type (DSA-SHA1 up to RSA-SHA512-4096 and EdDSA-SHA512-Ed25519ph), the signer ID, the file type and a content type (3 for reseeds). The signature covers header and content, and the content type sets the trust domain: clients keep a separate set of X.509 certificates for each kind of signed content.

The netDb page lists the bootstrap attack plainly: "taking over a reseed website, or tricking the developers into adding his reseed website to the hardcoded list". Implemented defenses are fetching a subset of RouterInfos from several reseed sites, an out-of-network monitor that checks reseed hosts for stale or inconsistent data, and the signed su3 format.

i2pd exposes this as configuration: reseed.urls, reseed.file, reseed.proxy, reseed.threshold (reseed below 25 known routers by default) and reseed.verify, "Verify .su3 signature", which defaults to false. We return to that default below. Reseed lists also change between releases: Java I2P 2.14.0 added five reseed hosts and removed one, and i2pd 3.0.0 "Updated reseeds list".

Which transports and cryptography does I2P use now?

I2P has two encryption layers. The transport layer protects each router to router link; tunnel and end to end garlic encryption protect messages across many links. The SSU2 announcement of October 2022 described a decade-long plan to upgrade "all the cryptography from the original Java I2P implementation dating back to 2003".

Timeline of the cryptographic migration

Dates come from the SSU2 announcement, the SSU2 rollout table and the release notes. The specs do not date 0.9.14 and 0.9.38, so those two rows are placed by their position between dated releases.

NTCP2 and SSU2 side by side

Both specs say the obfuscation resists deep packet inspection but is not secrecy: NTCP2 notes that anyone with the published router hash and IV "may decrypt the X value", and SSU2 calls its handshake header protection "effectively just obfuscation". Confidentiality comes from the Noise handshake that follows.

End to end and post-quantum

The ECIES spec replaces ElGamal/AES+SessionTags with a protocol based on Noise_IK_25519_ChaChaPoly_SHA256, supported since 0.9.46, using X25519, ChaCha20/Poly1305 and SHA-256. Its status note says network deployment is complete. A separate ECIES-HYBRID spec adds ML-KEM from NIST FIPS 203 (it stresses "NOT compatible with" CRYSTALS-Kyber) and reads "implementation, testing, and rollout in progress". i2pd's configuration guide offers ntcp2.version values 2 (standard) and 3 to 5 (ML-KEM-512, 768, 1024), defaulting to 4 on builds with post-quantum support. The 2.13.0 release notes give the reason: "harvest now, decrypt later" attacks on traffic recorded today.

What does I2P's own threat model say it does and does not protect against?

Start with the date: the threat model page is marked "Updated: 2010-11" and "Accurate for: 0.8.1". Its attack classes still hold, but its notes on transports and cryptography predate everything above.

It defines anonymity as "how hard it is for someone to find out information you don't want them to know", calls "perfect" anonymity not a useful concept, and describes I2P as a free route mixnet with "no official entry and exit points". At concept level:

The page also lists choices that may increase exposure: no low bandwidth "guard nodes" as Tor uses, traffic shifting between tunnels in a pool, and new tunnels every 10 minutes. The FAQ is equally sober: whether I2P is dangerous depends on your adversary, and a determined law enforcement investigation "will probably find you anyway".

Recent events show the last rows are real. On 4 February 2026 the I2P blog reported "ongoing Denial-of-Service and resource exhaustion attacks". The 2.14.0 notes list fixes for an out-of-bounds read in garlic clove parsing, an undersized NTCP2 buffer, a SOCKS proxy authentication downgrade, missing CSRF protection on I2PControl and a fallback to a default password. Old routers carry those bugs.

I2P, Tor, a VPN and Oblivious HTTP compared

These designs are often lumped together as "privacy tools", but they hide different things from different parties.

A VPN moves trust to one provider, OHTTP splits one request between two parties that must not collude, and Tor and I2P spread trust across volunteer routers while conceding that an observer of both ends can still correlate traffic. Our OHTTP and VPN posts cover those columns in depth.

For defenders: how I2P shows up on a corporate network

The most useful line for a security team is the threat model's own: I2P "is not specifically designed to hide that a computer is running I2P". The netDb publishes router addresses and the software sits on disk like any other application. You do not need to defeat transport obfuscation to know where it runs; you need endpoint inventory and a clear egress policy.

What a router does on the wire

• Bootstrap. On first start, or when it knows too few routers (25 for i2pd), it fetches i2pseeds.su3 over HTTPS from reseed hosts.
• Peer links. Since 0.7.8, Java I2P picks a random port between 9000 and 31000 on first run and uses it for TCP and UDP, connecting out to arbitrary remote ports on many peers. Inbound connections are optional.
• Time sync. Java I2P sends SNTP on UDP 123, by default to pool.ntp.org.
• Transit. By default a router relays tunnels for others. i2pd has share and notransit options; Java I2P uses a share percentage.
• Random-looking handshakes. NTCP2 and SSU2 avoid fixed protocol bytes and give probes no identifiable answer, so port numbers and payload patterns are a weak basis for policy.

Where it shows up on endpoints

• Packages. Java I2P's download page lists a Windows installer that needs Java, a jar for macOS, Linux and BSD (Java 17 or later, with a signature file), a macOS installer for Apple Silicon that bundles Java, an Android APK, an APT repository for Debian and Ubuntu, and Docker images. i2pd ships GitHub release packages, Arch's extra repository, a Gentoo ebuild, community Debian and Fedora COPR repositories, Docker images (purplei2p/i2pd), Flatpak, F-Droid and Android.
• Local listeners. 4444, 4445, 7654, 7656 and 7657 for Java I2P; 7070, 4444, 4447 and optionally 7650, 7654 and 7656 for i2pd.
• Data. ~/.i2p for Java I2P on Linux, including a netDb/ directory of cached RouterInfo files.

Step by step: inventory I2P across a fleet

These commands only read state. Run them through your existing endpoint tooling.

1. Linux packages and services:

dpkg-query -W -f='${Package} ${Version}\n' 'i2p*' 2>/dev/null   # Debian, Ubuntu
rpm -qa | grep -i i2p                                              # Fedora, RHEL
pacman -Q i2pd 2>/dev/null                                         # Arch
systemctl list-units --type=service --all | grep -i i2p

2. Local listeners on the default ports:

sudo ss -lntup | grep -E ':(4444|4445|4447|7070|7650|7654|7656|7657)\b'

3. Containers and sandboxed apps:

docker ps -a --format '{{.Image}} {{.Names}}' | grep -i i2p
flatpak list --app | grep -i i2p

4. Windows, in PowerShell:

Get-Package | Where-Object Name -like '*i2p*' | Select-Object Name, Version
Get-NetTCPConnection -State Listen |
  Where-Object LocalPort -in 4444,4445,7070,7654,7656,7657 |
  Select-Object LocalAddress, LocalPort, OwningProcess

5. Fleet-wide with osquery, if you run it:

SELECT name, version FROM deb_packages WHERE name LIKE 'i2p%';
SELECT p.name, l.port FROM listening_ports l JOIN processes p USING (pid)
  WHERE l.port IN (4444, 4445, 4447, 7070, 7654, 7656, 7657);

6. Record the Java I2P product and API versions or the i2pd version, and compare with the current releases (2.14.0 and 3.0.0 at the time of writing).

A port match is a lead, not proof; other software uses 4444 or 7070. Confirm the owning process and package before acting.

Writing an allow or block policy

Start from the business question. Most organisations have no reason for I2P on managed laptops or servers; a few have a legitimate one, such as privacy engineering, censorship research or developers building software that talks to a router over SAM or I2CP.

• Use inventory and egress posture, not signatures alone. Random ports and obfuscated handshakes mean signatures miss some traffic and flag unrelated traffic. Default deny egress with explicit exceptions covers peer to peer networks generally.
• Treat reseed hosts as a detection signal, not the policy. They change between releases, users can supply a reseed file by hand, and blocking them only affects first start.
• Decide about transit up front. If your network must not carry third party traffic, require notransit on i2pd, or the equivalent bandwidth share setting on Java I2P, and confirm it in testing.
• Tell staff. Most installs on work machines are curiosity. A clear policy and an exception process do more than a silent block.

The supply chain angle: verifying and updating routers

An anonymity router runs all day, accepts connections from strangers and parses complex input. Where you get it and how fast you update it matter as much as any setting.

Verify downloads. Java I2P release posts publish SHA-256 checksums for each artifact, and the download page links signature files:

sha256sum i2pinstall_2.14.0.jar
# Compare with the SHA-256 list in the 2.14.0 release post

In-router updates use the su3 format. The update spec says release signers use 4096-bit RSA keys whose X.509 certificates ship with the router, and the router checks that the unsigned header version matches the signed one, which "prevents spoofing of the version number".

Prefer package sources you already trust. i2pd is in Arch's extra repository and Gentoo, and its release packages and Docker images come from the project's GitHub organisation. Its community Debian repository is installed by piping a downloaded script into a root shell; if you use it, read the script, pin the repository key and add it through configuration management.

Turn on reseed signature checks in i2pd, since reseed.verify defaults to false:

# /etc/i2pd/i2pd.conf (excerpt for an approved, isolated router)
[reseed]
verify = true

[http]
address = 127.0.0.1
auth = true

Keeping the console on localhost with authentication follows the FAQ's advice not to expose local services. i2pd 3.0.0 also now creates key files readable by the owner only, so check permissions on older installs.

Keep routers current. In 2026 Java I2P shipped 2.11.0 (February), 2.12.0 (April), 2.13.0 (July) and 2.14.0 (October), and i2pd shipped 2.59.0, 2.60.0, 2.61.0 and 3.0.0 on a similar rhythm. Legacy code gets removed (SSU1 is gone) and security fixes only help once installed. Subscribe to the release feeds and treat a new release like any security update.

Track the router inside your own artifacts. If an image you build includes i2pd, or an application bundles a SAM client library, those are components of your software and belong in its SBOM and vulnerability management.

Common mistakes

• Assuming protection against a global observer. The threat model concedes intersection attacks for low latency traffic; Tor's documentation makes the same concession.
• Running a router on a work laptop. It relays third party traffic by default, it is visible to your network team, and it breaks most acceptable use policies.
• Running outdated routers. The 2.14.0 and 3.0.0 releases fixed real parsing and authentication bugs.
• Mixing identities. A nickname or key reused on the clear web and inside I2P links the two, and no routing design undoes that.
• Exposing local ports. I2CP, SAM, the console and the proxies belong on localhost.
• Leaving reseed.verify at false on i2pd. The su3 signature only helps if the router checks it.
• Writing policy around port numbers. Ports are random and handshakes are built to resist fingerprinting.
• Reading old docs as current. The threat model dates from 2010 and the garlic page still mentions ElGamal; check each page's "Accurate for" line.

FAQ

Is I2P the same as Tor?

No. Both layer encryption over volunteer routers, but I2P uses one-way tunnels chosen separately by each side and a netDb kept by floodfill routers, and is built for services inside the network. Tor uses two-way three relay circuits and a consensus signed by directory authorities, and is built mainly to reach the public internet.

What is a floodfill router in I2P?

A router that stores and serves netDb entries. Routers sharing at least 128 KBytes/sec that pass health checks opt in automatically when the network needs more floodfills and out when there are too many, forming a Kademlia style DHT with no central authority.

What is a LeaseSet?

A signed record listing the current inbound tunnel gateways for one Destination so others can reach it. It changes as tunnels expire every 10 minutes, and newer variants support multihoming and encryption.

Can my employer tell I am running I2P?

Usually, yes. The threat model says I2P is not designed to hide that a computer runs it, the netDb publishes router addresses, and endpoint inventory shows installed software and listening ports. Ask before installing it on a work device.

Does I2P let you browse normal websites anonymously?

That is not its purpose. Exits to the public internet are not part of the network layer; only a few application layer outproxies exist. Tor is designed for that use.

What is the difference between Java I2P and i2pd?

Java I2P is the original reference router with a full console and bundled apps. i2pd is an independent C++ implementation that runs as a daemon with a small web console. Both join the same network, and newer protocols such as SSU2 were designed by the two teams together.

Does I2P use post-quantum cryptography?

It is rolling out. Java I2P 2.10.0 (September 2025) made it available but off by default for new tunnels, and 2.13.0 (July 2026) made it "fully available" on NTCP2. The hybrid ML-KEM spec still lists rollout as in progress.

Should we block I2P on a corporate network?

Most organisations should not allow it on managed laptops or servers, and should enforce that with software inventory, application control and default deny egress rather than signatures alone. Allow legitimate research only in isolation with a current, verified build.

Where Safeguard fits

Safeguard does not inspect network traffic, inventory endpoints or detect I2P on your network, and it does not run or harden routers. Those jobs belong to your endpoint management, application control and egress tooling. The fit is narrower. If your team builds software that touches I2P, such as a container image that bundles i2pd, a service that talks to a router through a SAM client library, or internal tools around a sanctioned research router, Safeguard can scan the repository or image (safeguard scan --dir ., safeguard scan --image <name>) to produce an SBOM, list each package and version, and match them against vulnerability databases, with reachability analysis to rank the code paths your application actually calls. Results land as JSON under ./output, and the platform shows which projects contain a given component and version, so when a router or library release fixes a parsing bug you can find every image that still carries the old one. Policies and gates in CI can stop an image with a known vulnerable component from shipping.

An anonymity router is software like any other, and the containers, libraries and scripts around it pull open source dependencies of their own. Keeping those current, and having a path to a fix when an upstream release is slow, is the supply chain side of operating anything that touches I2P.

Fix it without waiting for upstream

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation categories include dependencies, licenses, security posture and findings, and each one is set separately. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds.

3. Gold Registry: start from components that are already fixed

Safeguard Gold rebuilds patched versions of open-source packages and images from source, signs each build, attaches an SBOM, SLSA provenance and VEX, and serves them from registry.safeguard.sh to your organization. Every Gold artifact is held continuously to zero exploitable critical or high CVEs and a completed license check, with signed build provenance (signed with Safeguard's key and verifiable with cosign, SLSA Build Level 3 as the design target) and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. Ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

These demos show dependency scanning and remediation, not network monitoring. You can download Safeguard and follow the CLI docs to try them on your own projects.

This demo sets up the Safeguard runner on your own machine, approves it with its device code and scans from the terminal. Pointed at a container image that bundles a router, or at the repository that builds it, the same scan lists the packages and versions inside so you know what to rebuild when a release fixes a bug.

Click through it at your own pace, or open it full screen.

This demo is a real CLI session: asked to fix the lodash CVE in a repository, it reads the finding and the advisory, edits package.json to lodash 4.17.21 and runs npm install and npm test, asking before any command that changes something and pushing nothing. The same flow applies when a library in a tool you wrote around a sanctioned router needs a version bump.

Click through it at your own pace, or open it full screen.

This demo connects Claude to the Safeguard MCP server with OAuth and lets you choose which tools Claude can use. You can then ask which of your projects ship a given package version and get the answer from your own scan data.

Click through it at your own pace, or open it full screen.

Quick check

Sources

• I2P: Introduction to I2P architecture and operation
• I2P: Threat model
• I2P: Garlic routing
• I2P: The network database
• I2P: Tunnel routing
• I2P: Tunnel implementation
• I2P: Peer selection
• I2P: NTCP2 specification
• I2P: SSU2 specification
• I2P: ECIES-X25519-AEAD-Ratchet specification
• I2P: PQ Hybrid ECIES-X25519-AEAD-Ratchet
• I2P: Software update specification (su3, reseed files)
• I2P: Naming and address book
• I2P: FAQ
• I2P: Comparison with other privacy networks
• I2P: Downloads
• I2P blog: SSU2 Transport (11 October 2022)
• I2P blog: 2.10.0 release (8 September 2025)
• I2P blog: 2.13.0 release (20 July 2026)
• I2P blog: 2.14.0 release (20 October 2026)
• I2P blog: Stormy Weather (4 February 2026)
• I2P blog index
• i2pd project site
• i2pd documentation: Configuration
• i2pd documentation: Installing
• i2pd 3.0.0 release notes
• Tor Project: Glossary
• Tor Project: History
• Tor Project: How do Onion Services work?
• Tor specifications: Directory protocol
• Tor specifications: Routing relay cells
• RFC 9458: Oblivious HTTP

Last reviewed: 26 October 2026. I2P and i2pd ship new releases every few months and reseed lists change between them; check the current release notes and each page's "Accurate for" line before you rely on a detail.