Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
Add Keybase proof integration #10013
Implement Keybase's parametrized proof integration.
Gargron left a comment •
Hello! Thank you for submitting this patch.
There are some code style/organization issues that I have highlighted. The patch also needs to be tried out...
Edit: This does not mean I expect you to personally address these issues. Just notes!
2 times, most recently
Mar 1, 2019
I'm going to summarize how this integration works from admin and end-user perspective, as far as I understand it, to allow people to leave feedback without reading the code.
From end-user perspective, if you are on Keybase, you can click "Prove your Mastodon identity", enter the instance address*, and it will send you to a page on your Mastodon instance with an "Authorize" button that will confirm the connection. From then on, both your Keybase account and your Mastodon account** will display a link to each other.
From admin perspective (and this has been a major concern for me since the start), running a Mastodon server is not enough. To allow users to prove Keybase identities, you must yourself have a Keybase account, and your instance must first be whitelisted by the Keybase team.
This is, admittedly, both a lot of hassle for admins and a lot of new code. We already have link verification, i.e. confirming that two pages link to each other with correct markup (rel=me), independently of Keybase. I am not quite sure why Keybase could not simply use the same method, thus allowing two-way verification without much extra work and without any cryptography.
On the other hand, in keybase/keybase-issues#2948 more than 160 people expressed a desire for a Mastodon/Keybase integration.
Keybase had been a Patreon sponsor of Mastodon for 3 months, but when this PR was submitted, I returned all donated money back to them to keep money out of the equation. Still, this is a very hard call, so I would appreciate input from other contributors and users of the platform.
This is why I'm hesitant on this feature that would hardcode in ties to a centralised, private verification service. There are other ways of verifying identity that allow Keybase alternatives to participate, up to and including your own website.
Keybase team member here. We'd love to see this integration, really because we have a lot of people expressing interest in it. There are shared values, as you can imagine, between the security/cryptography and decentralization crowds.
We also have 300,000 pretty serious users, most of whom are tech types, and most of whom are not yet on Mastodon. We'd like to promote Mastodon instances to them, as a better kind of social network. Twitter, Reddit, Github, etc., are all big players and we'd rather see a solution that allows anyone to create a community with public key crypto support.
A few clarifications:
There are a number of other advantages to this model for security, such as an auditable history of when the proofs were made, pinned to the bitcoin blockchain. That just won't be the case if all you've got is an input field on each website that can change without a signature.
I appreciate this point, however a subtle clarification: Keybase is guaranteed to be transparent. We can prevent a write to our database, just as a Mastodon instance could. But unlike a Mastodon instance, if a public announcement is in our database, it can be proven we're giving everyone in the world the same answer, and anyone could run a verifiable mirror.
As a final long-term strategy point. Decentralization projects NEED public key crypto more than anyone else. Admittedly, there is a chicken and an egg problem: someday you could have the perfect 100% decentralized app WITH cryptographic security, but we're nowhere near that right now, and each side kind of depends on the other.
We cryptography people support the idea of Mastodon, even though it isn't "secure" in ways we'd like (I assume there's private unencrypted data on your servers. It's certainly not E2E encrypted. The horror!) But decentralization is a goal in itself, and we love it. Similarly, Mastodon can benefit from Keybase, even if we're not as decentralized as you'd like. Either side getting too dogmatic will keep security from Mastodon users, and Mastodon-style federation from Keybase identities. This opportunity is great for both sides.
Single longest Github comment I've ever written!
But having it rely on something centralized and poprietary (considering the keybase backend) won't develop a healthy ecosystem on the fediverse.
Why not integrate whatsapp as well when we are on it?
Wow, a staggering amount of code for something that should be simple.
Edit: I'll answer my own question as since writing it I've read the docs on proof integration. It seems that for certain high-profile sites (HN, Reddit, Facebook) Keybase provides dedicated proof creation/verification code (Keybase writes all the code, the target service doesn't need to do anything).
Mastodon on the other hand would, with this PR, re-use their generic proof integration endpoint, shifting the burden of implementation to Mastodon so that Keybase wouldn't have to many any changes to their code.
@wiktor-k - your summary is a good one, although an added difference: a twitter integration has 2 problems:
We have a special opportunity to fix this case with Mastodon and subsequent partners: if someone effectively announces a key on their Mastodon profile, it should be cryptographically checked that it is in fact their key. Otherwise all you get out of it is safety in one direction. Both of these should work:
This allows digital signature verification and all kinds of other awesomeness.
To be honest it's just a text so there is not much they can change. Additionally Mastodon implements content negotiation so curling any toot with
I was under the impression that the Keybase browser extension does two-way validation of that claim...
I'm not sure that this model works best with federated systems such as Mastodon. Even if this is cryptographically checked on mastodon.social any other instance admin can put
The only secure place to do this kind of validations is in Keybase browser extension or on keybase.io (that are already trusted by Keybase users). There is no way to know if a random instance admin is running this validation code there or just playing with a little bit of HTML.
As far as I understood the system would protect from malicious users but would assume all admins are good. But if the user was malicious they can spin up their own instance in the first place.
The way we approach it you need to trust only your own admin... For example with link verification, we do not trust what the remote server claims, we re-run our own checks for remote accounts. Ideally it would be the same for these Keybase signatures. Re-verified on the receiving end.
Eugen, it's good that you bring link verification as I see this (Keybase and link verification) strikingly similar.
Link verification shows
The same applies to Keybase proofs, if one trusts their admin they don't need "cryptographically checked" proofs - a simple one will do. If a "Keybase badge" is hosted on a foreign instance then one can't trust it anyway so it doesn't matter if it's "cryptographically checked" or not. How would one verify Keybase proof on foreign instance? The same way as with link verification - by following the link and checking the link back.
hi Wiktor, I think this is where we disagree (let me convince you!), and I think the difference is why so many people are interested in getting these cryptographic proofs into Mastodon.
(And note we chose to prioritize working on Mastodon integration since it was getting requested the most, along with the fact that we believe in the idea.)
Remember, one goal here is that someone could fire up a Keybase app (which is open source) and make a request to both a Keybase and a mastodon instance, and know for sure it's getting absolutely the right keys for that mastodon user. If the only connection were usernames, there are some ways Keybase OR Mastodon could cheat. Sure, people might trust their admins enough to use an instance, but people want this because they don't trust anyone with their end-to-end encryption and/or signatures. If, instead of usernames, it's a cryptographically-signed message which both Keybase and the instance agree about, then (1) a bad actor would have to have bad data on both sides, and (2) more important, it would be discoverable and exportable (since the sig would have to exist in Keybase's merkle tree). Which means really not feasible at all to cheat, even for a moment!
But with just usernames, targeted lies are totally possible.
So, I think...if you sort of trust your admin, like enough to use their instance, but not for something private, then the Keybase solution is much better than just hosting something like a public key. Or a username-username connection.
As a last point - I'm just not seeing meaningful Mastodon connections outside of Mastodon, and I hope this could help. I think people will want profiles out there with some of their identities connected. I'd love to promote on Keybase that GitHub programmer X is also Mastodon
Because the Keybase connections are all verifiable, someone running Keybase can feel very good about drawing transitive conclusions. I don't know of any formal way other than Keybase to get all this identity connection. That's just how Keybase will lead to Mastodon, but also, starting on the Mastodon side, even not running Keybase or worrying about the crypto, people will start being able to make these connections. I could look at you on instance X, follow the link to Keybase, and then follow the link from Keybase to GitHub, Reddit, or Twitter (assuming you want). Right now I don't know which of those services are doing the rel=me bidrectional thing (if not, how will you get them on a Mastodon profile?) , but with Keybase it doesn't matter. I think that's pretty cool.
Ok, thanks for listening!
No problem, and thanks for taking the time to explain. I really appreciate it.
For the record I'd like to see Keybase integration probably as much as everyone else. I'm just discussing the design issues that could, in my opinion, be improved.
I get why you think plain two-way links are not enough. But two-way link + a signed toot, that Keybase would verify should be enough to satisfy your threat model. Keybase validates the toot, adds
The only thing that implementing parametrized proofs gives is tighter integration with Keybase, for example Mastodon checking if someone didn't remove their Mastodon profile from Keybase and removing the backlink then or a better styling for Keybase proof. That is nice, the only minor issue I have with that is that it's overly specific to one service only. Styling and automanagement of backlinks is good but maybe it would be better to enhance link verification so that every other service could benefit.
My 2 cents, have a nice day!
@malgorithms excellent overview and explanations of what a public key crypto infrastructure can bring to the fediverse, thank you for sharing! I have a question, if you don't mind: do you see value in implementing this sort of integration abstractly enough to allow for crypto infrastructure other than Keybase? Say, if a competitor were to launch a service equivalent to yours, do you think it would be worthwhile to enable Mastodon users to integrate with their service as easily as with Keybase? if not, how come, and if so, how do we ensure this happens?
good question @edobry . I'd be totally happy to see other services adopt a similar protocol. I might not call them "competitors" because Keybase does a lot of different things, not just identity connections. For example, we do encrypted filesystem, chat and team memberships. Meanwhile, we'd love to see an Ethereum dapp that also does identity right, so people can connect dapps to Mastodon. We're not really getting into that stuff at all. So the more the merrier.
I think the technical answer to your question is a good one. The team's assessment is this really could evolve as needed without (1) breaking Keybase<>Mastodon or (2) preventing other people from doing the same. There is some specific Keybase code in this PR, but it's pretty superficial; most details in the PR are either general or easily generalized.
As soon as someone like Keybase comes along and wants this, too, they'll have some small differences we haven't thought of yet in the user flow and protocol, and the higher level Keybase-specific code can get modified to be a bit more general and designed to accommodate those things we haven't thought of. That would lead to a next, much smaller PR for Mastodon to keep Keybase support and add the next set of partners. I would say trying to predict those generalizations right now might be tough and could bloat the PR with harder to follow code that no one uses and yet still isn't general enough.
tl;dr we'd love to see this Keybase<>Mastodon connection, and wouldn't feel the least bit threatened to see other Keybase-like services, should they come along. we'd be happy to help with the generalizations when that happens too.
Note I personally will be on vacation all next week, so I might not be the fastest to reply here...but other people on the team who've been working hard on this will be around.