sam/i2pforge
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions 1
Page: backing up your key
Pages
Home backing up your key encrypt at rest faq how it works operator runbook opsec mistakes running multiple tunnels the installer troubleshooting verifying your setup
1 backing up your key
Sam Bent edited this page 2026-07-17 15:15:52 -04:00
Table of Contents

Backing up your key

Your .b32.i2p address is derived from one file: the destination key. If you lose that file, you lose the address, and nobody can recover it or reissue it. So this page is short and it matters. Read it before you rely on the address.

What to back up

The whole ./i2p-keys folder. In it you will find:

  • eepsite.dat is the secret key. It proves you own the address. Guard it like a password.
  • eepsite.b32.i2p is your public address in plain text. It is safe to share.

If you turned on encryption at rest, the secret is stored as eepsite.dat.i2pfk1 instead, and you also need the passphrase. See Encrypt at rest.

You do not need to back up anything else. The rest of the container's data is temporary and rebuilds itself.

How to back it up

The built-in backup command wraps the folder in an encrypted archive. It uses age if you have it, and falls back to gpg or openssl:

./scripts/i2pforge backup --out i2pforge-keys.tar.age

Store the resulting file somewhere safe and offline. To restore it on a new machine:

./scripts/i2pforge restore --input i2pforge-keys.tar.age

If you would rather not use the tool, a plain copy of the folder works too. Just make sure the copy keeps the file permissions and that you store it somewhere an attacker cannot read, because eepsite.dat in the clear is enough for someone to impersonate your service.

Moving to a new machine

Because the address is just a fingerprint of the key, moving is simple:

  1. Copy or restore ./i2p-keys onto the new machine.
  2. Start i2pforge there, pointing at the same folder.
  3. Within a minute the same .b32.i2p address comes back.

This is also what happens during an upgrade. When you pull a newer image and recreate the container, the key folder stays put, so the address never changes. The upgrade test in the repository proves this: it brings up a service, records the address, recreates the container from the image, and confirms the address and the key file are byte-for-byte identical afterward.

If you think the key was stolen

Treat a stolen eepsite.dat the way you would treat a stolen password. Whoever has it can stand up a service at your address and pretend to be you. There is no way to revoke the old address. Your only move is to generate a new key, which gives you a new address, and tell your users about the change:

./scripts/i2pforge rotate

This is destructive and asks you to confirm twice. It archives the old key and lets the router generate a fresh one on the next start. The old address stops being yours the moment you stop serving it.