There is a heated discussion going on right now about if and when cryptographic primitives will have to be updated to be quantum-safe. I am not qualified to weigh in on the debate, but some serious cryptographers seem to think that current signature algorithms will be broken by quantum computers sooner than expected.

A recent question from an iroh user prompted us to write this up.

Iroh connection establishment

So let's take a look where post-quantum algorithms are relevant for iroh:

During iroh connection establishment, we verify the identity of the remote endpoint. This requires a signature algorithm. We exchange a secret for the symmetric encryption of the connection. This requires a key exchange algorithm.

So there are two attack vectors. If the signature algorithm is broken, an attacker can impersonate any endpoint id. If the key exchange algorithm is broken, an attacker can decrypt the contents of the connection.

You might think this isn't a problem. After all, nobody has a sufficiently powerful quantum computer today.

But an attacker can record connections now and then break the key exchange later, once a sufficiently capable quantum computer becomes available. This is called harvest now, decrypt later.

While we still have some time to decide on a post-quantum signature algorithm, securing the key exchange is more urgent because encrypted connections can be recorded by anyone who can observe the traffic.

So how can we secure the key exchange?

The number0 team decided to rely on existing standards as much as possible. Iroh connections are QUIC connections that use TLS 1.3 for encryption.

In TLS 1.3, the key exchange algorithm uses an ephemeral keypair on each side, so we have freedom to choose the kind of keypair we use.

Post-quantum key exchange algorithms are standardized and have acceptable overhead, so for scenarios where we are concerned about harvest now, decrypt later, we can enable them.

We have to configure iroh to use the aws-lc-rs Rust binding to AWS-LC via the iroh feature flag tls-aws-lc-rs, and configure rustls to prefer post-quantum handshakes via the prefer-post-quantum rustls feature.

iroh = { version = "0.98", default-features = false, features = ["tls-aws-lc-rs"] }
# iroh depends on rustls with default-features = false, so we need to enable this explicitly
rustls = { version = "0.23.38", default-features = false, features = ["prefer-post-quantum"] }

What this does is to prefer a post-quantum handshake despite the higher cost, if both sides support it. It does not force a post-quantum handshake, so if you talk to an iroh node that does not support post-quantum, you will get a normal X25519 handshake.

So if you are extremely paranoid you would have to configure your iroh endpoint to not allow classical handshakes at all, and lose interoperability with default configured iroh endpoints.

Keep in mind that turning on post-quantum key exchange isn't free. X25519MLKEM768 adds roughly 1 KB in each direction — enough that the handshake requires multiple UDP packets in both directions. aws-lc-rs is also a heavier dependency than ring.

What about signatures?

While post-quantum key exchange algorithms are standardized and come with relatively modest overhead, post-quantum signature algorithms are the subject of active research.

All current options have significant downsides regarding computational cost, key size or signature size. So there is no industry consensus yet which one to use.

There is also less urgency because there is no harvest-now-decrypt-later equivalent for signatures.

Conclusion

Iroh today lets you opt in to a post-quantum key exchange algorithm, protecting against harvest now, decrypt later. If your traffic needs to stay confidential for a few years or more, turn it on.

For signature algorithms we are waiting for an industry consensus to emerge.