Skip to content

Blog post explaining in what ways an iroh endpoint id isn't private - #511

Open
rklaehn wants to merge 4 commits into
mainfrom
blinded-address-lookup
Open

rklaehn wants to merge 4 commits into
mainfrom
blinded-address-lookup

Conversation

@rklaehn

@rklaehn rklaehn commented Aug 14, 2026

Copy link
Copy Markdown
Contributor

This explains why iroh endpoint ids are currently not private, sketches a plan to make them more private in the future (whether we do this is another question), and provides a proof of concept blinded mainline address lookup service.

It also contains a teaser to the rcan work.

If you want to publish this while I am away, feel free to finish it.

The corresponding repo is https://github.com/n0-computer/iroh-mainline-address-lookup-blinded

Todo:

  • make repo public
  • add final get in touch message

@vercel

vercel Bot commented Aug 14, 2026

Copy link
Copy Markdown

The latest updates on your projects. Learn more about Vercel for GitHub.

Project Deployment Actions Updated
iroh-computer Ready Ready Preview Sep 2, 2026 9:01am UTC

Request Review

@n0bot n0bot Bot added this to iroh Aug 14, 2026
@github-project-automation github-project-automation Bot moved this to 🚑 Needs Triage in iroh Aug 14, 2026

@ramfox ramfox left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Grammatically and structurally, this is good. I also like the tone, for example "let's go full paranoid" lol

My current hold up is the tension between a) informing folks of the very important point that endpoint ids should not be used as secret keys, and b) possible solutions to make them able to be used as secret keys. Since these possible solutions need so many caveats, we may want to remove them or just make them even more vague.

Regardless of which version we choose (only state problems or state problems and potential solutions)I have made suggestions in the text on how to re-phrase some of the language!

Comment thread src/app/blog/blinded-address-lookup/page.mdx Outdated

No.

There are various ways to learn of the existence of an iroh public key, so while keeping an iroh public key secret provides a modest amount of security that is sufficient for [some applications], it definitely **isn't** a secret in the cryptographic sense.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
There are various ways to learn of the existence of an iroh public key, so while keeping an iroh public key secret provides a modest amount of security that is sufficient for [some applications], it definitely **isn't** a secret in the cryptographic sense.
There are various ways to learn of the existence of an `iroh` public key, so while keeping an `iroh` public key secret provides a modest amount of security that is sufficient for [some applications], it definitely **isn't** a secret in the cryptographic sense.

Comment thread src/app/blog/blinded-address-lookup/page.mdx Outdated

## Relays

The iroh relay protocol works using iroh public keys as identifier for endpoints connected to the relays.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
The iroh relay protocol works using iroh public keys as identifier for endpoints connected to the relays.
The `iroh` relay protocol works using `iroh` public keys as identifiers for endpoints connected to the relays.

Comment thread src/app/blog/blinded-address-lookup/page.mdx Outdated

This additional information must be safe against replay attacks.

I haven't worked out the details yet and don't want to share more half-baked ideas, but I am pretty sure this is doable.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe we hand this to @matheus23 or @dignifiedquire to get a second opinion, so we can remove this line or change it to something like:

"The exact process for achieving this hasn't been worked out, but we are confident that this is theoretically possible."

?

[`SecretKey`]: https://docs.rs/iroh/latest/iroh/struct.SecretKey.html
[`raw_sign`]: https://docs.rs/ed25519-dalek/latest/ed25519_dalek/hazmat/fn.raw_sign.html
[some applications]: https://iroh.computer/sendme
[granovetter property]: https://erights.org/elib/capability/ode/index.html

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

😬 this link is unreachable for me

@github-project-automation github-project-automation Bot moved this from 🚑 Needs Triage to 🏗 In progress in iroh Sep 2, 2026
rklaehn and others added 3 commits September 2, 2026 10:58
Co-authored-by: ramfox <kasey@n0.computer>
Co-authored-by: ramfox <kasey@n0.computer>
Co-authored-by: ramfox <kasey@n0.computer>
@rklaehn

rklaehn commented Sep 2, 2026

Copy link
Copy Markdown
Contributor Author

Grammatically and structurally, this is good. I also like the tone, for example "let's go full paranoid" lol

My current hold up is the tension between a) informing folks of the very important point that endpoint ids should not be used as secret keys, and b) possible solutions to make them able to be used as secret keys. Since these possible solutions need so many caveats, we may want to remove them or just make them even more vague.

Regardless of which version we choose (only state problems or state problems and potential solutions)I have made suggestions in the text on how to re-phrase some of the language!

Yes, I had this tension as well and was hoping for some input how to resolve this.

My take is that all these solutions are great for the future, but we don't want to imply that iroh is flawed in some way. Iroh is working as designed, we don't want to do a half-assed privacy feature.

If we ever proclaim that iroh public keys are private, it will be after we have implemented all these improvements and have them independenty vetted.

Maybe an info box along these lines?

The final part where we mention rcan would also be a cliffhanger to a rcan blog post that we would have to publish soonish after.

@rklaehn
rklaehn requested a review from ramfox September 4, 2026 08:30
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

Status: 🏗 In progress

Development

Successfully merging this pull request may close these issues.

2 participants