Show HN: Public Key Directory – Key Transparency for the Fediverse(publickey.directory)
publickey.directory
Show HN: Public Key Directory – Key Transparency for the Fediverse
https://publickey.directory
2 comments
How does this compare to FOKS (https://foks.pub)? Do both projects accomplish similar goals?
Edit: I see that this is primarily intended for federated social networks, but should be reusable for other uses. However for other e2ee systems (e.g. messaging, filesystems) where hiding your social graph is important, wouldn't a key directory be able to infer (part of) your social graph by recording which lookups you make? What's the best way to mitigate that?
Edit: I see that this is primarily intended for federated social networks, but should be reusable for other uses. However for other e2ee systems (e.g. messaging, filesystems) where hiding your social graph is important, wouldn't a key directory be able to infer (part of) your social graph by recording which lookups you make? What's the best way to mitigate that?
> However for other e2ee systems (e.g. messaging, filesystems) where hiding your social graph is important, wouldn't a key directory be able to infer (part of) your social graph by recording which lookups you make?
Metadata resistance is out of scope for this project.
ActivityPub already leaks your social graph all over the place already. This is intended for ActivityPub. Trying to fix this in our design would have been a fool's errand.
Even if we could mitigate that, your k-anonymity is already limited to the users on the same instance you're on. Attackers are assumed to be able to see which messages are routed to which server.
That said, your public keys are vended publicly via an HTTP REST API. Just because someone is fetching those public keys (which could be fetched over Tor) doesn't mean you know who is requesting them, or for what purpose.
(I deliberately design things to be Tor-compatible; and to that end, do not ever rely on DNS records or DNSSEC.)
Metadata resistance is out of scope for this project.
ActivityPub already leaks your social graph all over the place already. This is intended for ActivityPub. Trying to fix this in our design would have been a fool's errand.
Even if we could mitigate that, your k-anonymity is already limited to the users on the same instance you're on. Attackers are assumed to be able to see which messages are routed to which server.
That said, your public keys are vended publicly via an HTTP REST API. Just because someone is fetching those public keys (which could be fetched over Tor) doesn't mean you know who is requesting them, or for what purpose.
(I deliberately design things to be Tor-compatible; and to that end, do not ever rely on DNS records or DNSSEC.)
I've been working on solving this problem so we can have end-to-end encryption for DMs on ActivityPub (and therefore Mastodon).
I thought I'd share it here in case anyone was interested in this work.