Iroh 1.0 - Dial Keys, not IPs
76 points by mhm
76 points by mhm
Since there's a lot of confusion both here and on HN about how Iroh is different to mesh networks layered on VPNs (Tailscale, ZeroTier, Netbird etc.), this is my interpretation: Iroh is aimed at application developers who want to communicate P2P between machines running their app while mesh networks are aimed at network admins who want to connect devices they own/manage together.
Imagine I'm developing an P2P messaging app where, on one side the user is on a mobile device which constantly roams between WiFi/mobile data (so doesn't have a stable address), and the other side is a laptop sitting behind a NAT and a CGNAT. If I want to get these folks to talk to each even while the IP addresses change, I need some mechanism to deal with this. Historically this would have been done via an intermediary server owned by the app developer which both the endpoints talk to so they can share state. Iroh tries to instead standardise this and offer it as a service.
Gotcha, cool!
So if I understand correctly then, this is closer to an opinionated WebRTC setup that handles assigning a persistent ID to clients. All the work of making a signaling server is taken care of and the solution is generic enough and cheap enough to run that you can get away with using a community hosted one. Kinda similar to what you get with Steam’s proprietary p2p gamenetworkingsocket infrastructure
Yes I think your examples are spot on. They appear to be also mostly using standards with the main one being QUIC which is a nice touch.
I see what you're pitching as the market audience, but looking at their pricing, they scale based on concurrent users and their tiering for the average caps out at 5,000. Isn't that... quite low?
Maybe I missed something, but hanging everything off a single key sounds incredibly dangerous. What happens if that key is lost or compromised?
I did a quick search for "key rotation" in the Iroh docs, but didn't find anything.
The keys are public. In iroh, they're a replacement for an IP address (also public) as a way to reach another node.
The public keys are public, but there is a corresponding private key that must be kept private.
Secure private key storage is hard enough that the dominant advice is rotating keys.
When the private key rotates, the public key changes, akin to the IP changing.
Depending on the usecase this might be fine: after all most deployments of SSH/Wireguard have long-lived keys.
But if the problem statement is "IP addresses can break, without warning, and it's outside of your device's control.", I think there's a similar story of "private keys can be exfiltrated, without warning, and it's outside of your device's control".
There are things can help, like offline keys (similar to DNSSEC KSK/ZSK, though the trend there is a single shortlived key) or hardware-backed keys.
Another relevant factor is the PQC migration, and so perhaps Iron public keys (and thus addresses) will become much larger!
It's up to the developer to choose how to persist or rotate keys (which are Ed25519 key pairs). The public keys are used for identity, so if you do rotate keys, the new public key needs to be communicated to peers somehow. Some applications that use Iroh persist the keys and some generate them for each session.
If the private key was compromised, the attacker would be able to impersonate you when initiating or receiving connections. If it was lost, you stop being able to prove your identity to peers. My understanding is that the risk is similar to any other password or private key lost or compromised.
I mean, you're kind of right but also "it's up to the developer to choose how [...] rotate keys" wouldn't that require solving the problem that this system is attempting to solve again?
Yes. One difference is that key rotation is already a problem for connectivity (consider typical deployments of SSH and Wireguard), so even if your routing layer didn't introduce key distribution problems, you'd still be limited by it.
Further, distributing public key updates is an application problem, whereas IP connectivity requires coordination with the network, as the page alludes to: "IP addresses can be private and inaccessible behind firewalls, but with iroh your device can be securely addressable no matter where it is.".
Globally routable IPs is ideal, but anything less than that requires things like port forwarding, or NAT punching (and some coordination server, but with what identity?)
With iroh, my application has a cryptographic identity, and I can give you an address to it that Iroh applications can route to.
I wrote an app that uses Iroh and chose not to rotate keys automatically. A user /could/ delete the stored key and get a new one, but there's not much reason to. The keys are application-scoped (there's no standard way to share keys between applications using Iroh, but I don't think there needs to be one) and for my application it's not a huge deal if they're lost or stolen.
The app distributes public keys by scanning QR codes. I've also thought about having traditional accounts on a server that tie username/password/... to a set of public keys. Users sign in on multiple devices and each device stores a private key and registers its public key. Then Iroh's role is to reliably open direct connections between devices using the known public keys. I see that as the problem Iroh solves, not key distribution or application-level identity.
Tor has the same problem - cryptography is a tool to turn confidentiality, integrity and authenticity problems into key management problems :)
Probably any system that wants Security and Decentralization (the bottom two of Zooko's triangle) will have the same problem.
I don't see the other answers actually addressing your point. Indeed if you lose the key you are no longer you. I also can't immediately come up with a way of doing something similar that wouldn't have this property. You might be able to thoroughly distribute information to avoid the obvious DoS and then use a protected (airgapped, hardware) key to only sign the actual keys for your endpoints.
Trying to understand the project, I don’t really get the Key vs IP distinction - at some point the keys get mapped to an IP address so that they can use IP routing, right?
Is the key a replacement for URLs / DNS as a way of assigning long lived identifiers to IP addresses?
yeah, "keys" are a replacement for urls/DNS, but they don't assign to a specific IP. iroh does p2p holepunching & relaying, and the keys get published to an iroh relay server ( you can run your own ) . when you try to connect one node to a second by key, it looks the key up on one of the relay servers and tries to connect via a number of methods, from direct IP connection to holepunching down to a relayed connection via the relay server.
the keys are also used for e2e encryption of data via QUIC!
Thanks! You and lalitm helped me understand it a lot better- seems like a really cool and useful project!
This looks similar to what Tor does. You identify who you want to talk to using a key and then the connection gets set up by wizards.
Yes, Tor has its own discovery system. We have an experimental tor transport that taps into that system. So if you use it you don't need to use our built in address lookup at all.
It is of course much slower than the built in IP and relay transport, so you would only use it if you care about privacy above all.
I believe Veilid is closer to that- Iroh does not do any of the onion routing etc. to hide your IP address. Though it can be run atop Tor
Is there a way to host your own relay server, such as for a particular application? Looks like yes but considering that they have a pricing page for dedicated relays this seems a little odd...
Yes, you can run your own relay server, and you linked to the right code. E.g. DeltaChat runs this as part of their chatmail relays. Some folks also embed the relay into an existing web server.
The hosted relays aim to provide that for you, without the hassle of managing your own servers. And give you more insight into your network.
I believe the code you linked is enough for self hosting in addition to their paid managed ones.
What similar alternatives are there? Host Identity Protocol? https://mkomu.kapsi.fi/hipl/index.php?index=how
Sanctum and its cathedrals, and using the library implementation to embed the secure tunnels in your app.
It solves key rotation too by allowing wrapped secrets to be deployed to active clients.
https://sanctorum.se https://github.com/jorisvink/sanctum https://github.com/jorisvink/libkyrka
ipfs tries a similar thing. I'd love my services to have reliable routing, without dependence on IP allocations. Every time I tried ipfs it was pretty flaky, even for simple examples.
Does anyone know how iroh improves on this? Is it something architecturally (relays? better NAT punching?)? Or fewer bugs?
IPFS is using libp2p under the hood. Iroh is more like libp2p - it only provides connections. We have protocols like blobs and gossip on top of iroh if you need the full functionality of IPFS. But we have found that many projects need just connections or want to use other protocols on top.
One big difference to IPFS is that we use dedicated relays. That makes it less pure p2p, but much more reliable. The relays help with hole punching, but also relay traffic if hole punching is not possible. We operate rate limited public relays. If these aren't sufficient you can either buy our hosted relays or self-host relays. Note that the relay binary is open source just like everything else.
(The reason to use hosted relays is that you get relays in multiple regions and some insight into your deployment, not that self-hosting is impossible)
Another big difference is that IPFS was written before QUIC, so it abstracts over transport streams, with the most important being TCP. Iroh is using QUIC throughout and is abstracting the transport below QUIC as an unreliable datagram transport, with the most important being UDP. Libp2p can also use QUIC, but as just another transport. It doesn't make full use of it.
Going even deeper, a big architectural difference is that we use QUIC multipath. Each transport is a separate path with its own congestion controller. This is one of the few things we do that is truly novel.
Last but not least, iroh is a rust crate that can be used in pretty limited environments. E.g. I got it running on an esp32 embedded computer with 2 MiB of SPIRAM: https://www.iroh.computer/blog/iroh-on-esp32 . There are very few p2p networking libraries that work in such constrained environments with full encryption.
Thanks for the comprehensive reply.
Yes, I can see how the reliability would be improved with:
I've wanted "mTLS over QUIC with public key pinning" to replace wireguard for point-to-point links for a while.
Iroh seems like it can do that, all while addressing routeability too. Nice! (Update: I had a look into this, and it looks like though Iroh is mTLD under the hood, the APIs don't support rejecting the peer SPKI at TLS time: you can only abort after mTLS has established.)
Very cool to see it on the ESP32. I should add it to my uart-over-wifi-on-esp32. Secure, access-from-anywhere serial to my devices!
Going even deeper, a big architectural difference is that we use QUIC multipath. Each transport is a separate path with its own congestion controller. This is one of the few things we do that is truly novel.
This made me wonder about the interaction between congestion control, load balancing, and loss recovery. The QUIC multipath draft says it has per-path congestion control and loss recovery, but no multipath scheduling. (Which seems like a shame to me, because loss recovery ought to work better if it makes use of multiple paths, but that requires a multipath scheduler which they don’t yet have.)
What’s different between Iroh and multipath QUIC?
What’s different between Iroh and multipath QUIC?
Iroh connections are just QUIC multipath connections. Our QUIC library noq implements the multipath draft RFC as faithfuly as possible.
What we add is raw public keys in TLS and some logic for hole punching, that's it. We also use TLS Alps for protocol negotiation.
Oh right, you meant that using multipath QUIC is novel, not that Iroh has something novel added to multipath QUIC?
I'm having trouble understanding what this is. Yggdrasil comes to mind, but I don't understand how these two compare.
It looks to be solving similar problems but Yggdrasil is (typically?) at layer 3, so wants OS integration, whereas Iroh is (typically?) at the application layer, so you needn't have OS support.
In practice this means a note sync app could bundle Iroh support to perform connectivity for sync, and the user might not even realise, esp if the crypto/routing was exposed as "scan QR code of your other device" type UI.
Data sync is one of the first things we have deployed in production. Delta chat has a feature to get your contacts and chat history on a new device, using a QR code.
https://delta.chat/en/help#can-i-use-delta-chat-on-multiple-devices-at-the-same-time
Most delta chat users are completely unaware that it embeds iroh for some functionality, as it should be. And it works on all desktop and mobile platforms.
Turning this around, it's possible to use IPv6 route advertisement, with something like radvd (see community instructions), to advertise Yggdrasil IP addresses to machines which are only indirectly exposed to the routing tree. If one machine on a LAN has an Yggdrasil uplink then every IPv6 machine on the LAN can, in theory, discover and use that uplink. (In practice, Android and Windows still suck.)
also worth looking at pkarr, which is just the pubkey->dns over bittorrent DHT part
from what i can tell iroh is trying to solve a mobile/browser problem, which you may or may not need solved, while pkarr is narrowly focused on solving the id->ip problem over udp
also, if you use iroh, you'd probably want to consider a post quantum protocol on top of it, depending on what you're doing. bittorrent uses ed25519 for public keys, which isn't secure for store now decrypt later attacks. it's probably fine for setting up the connection, unless the NSA is further ahead than people think, though
pkarr is narrowly focused on solving the id->ip problem over udp
pkarr can store/retrieve arbitrary DNS records (up to the 1000 byte limit of Mainline). It seems like many people are using it for IPs, but personally I use it for git refs :-)
ed25519 keys are fine for identity for now, there is no store-now-decrypt-later risk for identity. iroh uses normal TLS (via QUIC) for the connections, ed25519 is used for identity but than you can configure the TLS to prefer the hybrid X25519MLKEM768 key exchange and if both peers' TLS stack support it than it'll be a PQ-secure TLS.
The other limitation of choosing ed25519 is poor support in hardware-backed options like TPM2. Increasingly I want keys in the TPM, so I have more confidence when authenticating a machine that it's the machine I think it is.
You can sign your generated ed25519 key with another, more strongly trusted key like from TPM or other hardware. That way you can still rotate the identity key used in TLS and iroh routing but can build any kind of assurance you like.