Post-quantum endpoint identity / EndpointId

[domenkozar]

With post-quantum key exchange now supported (#4147), are there plans for making Iroh's endpoint identity post-quantum as well?

As I understand it, EndpointId is currently tied to an Ed25519 public key, so while the key exchange can be post-quantum safe, the long-term identity/authentication is still based on a classical signature scheme.

Is there a planned direction for migrating EndpointId to a post-quantum-safe identity scheme?

In particular, I'm curious whether the likely approach would be to:

• make EndpointId independent of a specific signature algorithm (for example, derived from/hash of an identity key), and
• support migration/rotation from existing Ed25519 identities to a future PQ signature scheme.

[domenkozar]

Ed25519 is secure today, but it is not post-quantum secure. Shor’s algorithm on a sufficiently capable fault-tolerant quantum computer would allow an attacker to derive private keys from public keys and forge signatures.

Recent estimates put breaking 256-bit elliptic-curve cryptography in the range of roughly 800–1,500 logical qubits. A 2026 result reduced the theoretical requirement to 835 logical qubits, while Google demonstrated an attack construction using ≤1,200 logical qubits and ≤90 million Toffoli gates. These estimates are not specifically for Ed25519, but for comparable 256-bit elliptic-curve discrete-log problems.

This is no longer purely hypothetical hardware scale. IBM's current roadmap targets 200 logical qubits in 2029 and 2,000 logical qubits with up to 1 billion operations around 2033+. That does not mean Ed25519 will definitely be broken in 2033, but it puts machines of the required order of magnitude on current industry roadmaps.

Cryptographic migrations across protocols, identities, deployed software, and long-lived keys can take years. Therefore, the sensible approach is not to abandon Ed25519 today, but to make the system crypto-agile and define a post-quantum migration path now, rather than starting once a practical attack is imminent.

[flub]

Hi, we are preferring to not build in crypto-agility into the protocol for now. The basic idea currently is to stay on ed25519 for identity until it is realistic that it is broken. At this point maintaining backwards compatibility would not make sense and a new major version would need to be released with a new identity algorithm. For identity store-now-decrypt-later concerns do not apply so this is a reasonable approach.

[domenkozar]

Keeping Ed25519 for now seems reasonable, but I’d be concerned about waiting until it’s broken to migrate. At that point, attackers could impersonate existing endpoints and forge messages linking old identities to new keys. A major version can replace the algorithm, but it can’t by itself restore trust in those identities.

Could we avoid crypto-agility for now while still planning an identity migration that happens before Ed25519 becomes practically vulnerable?

[domenkozar]

I'm building local-secrets vault that will use Iroh for vault-to-vault syncing and one of the major goals is to prepare us for PQ-world.

We'll run these patches with our relay that supports PQ identity for the launch.

It's all OSS, hopefully this will inspire Iroh to also join our quest!