Keybase.io
keybase.io
keybase.io
The alpha site's changing every day, and we're working on the documentation now. I don't use the term "alpha" loosely. There will be extensive security details published, explaining every aspect of the identity proof system, client sessions, etc. They will be on the site before we open general access or turn beta. Right now only a few friends are on there. All that said, Max and I can answer questions here.
My profile on the site is https://keybase.io/chris if anyone wants to look. My profile demonstrates early examples of how identity proofs will work, including both twitter and github. We'll of course be adding other public identities in the future.
The site design is also very iffy at the moment; I was about to move into firefox bugs tomorrow.
1. I like the site design, the story flow on the front page does a great job of explaining what keybase is.
2. I see (from the abovementioned story flow) that keys can be verified by reviewing signed tweets/gists. Is this functionality extendable to arbitrary links; i.e. verifying keys against personal blogs, Tumblr, WordPress or does the third-party site need to implement a recognized API?
Again, thanks so much, and it looks like a terrific site so far.
With twitter, it's the ability to post a tweet under a certain username. With owning a tumblr account, it might be something similar. With your known StackExchange profile it might mean posting a statement in a specific part of your profile. And so on.
The common thread in each case is (1) that you post in a place where only your identity can, and (2) what you post is a signed statement claiming a connection among three things: (a) your keybase username, (b) your public key, and (3) the identity on that third party service. (The third one is necessary so it can't be moved elsewhere.) Note how twitter and github's are totally different, but achieving these three things.
We will build out this list of identity checks, hopefully making all kinds of them easy to do. Everything from proving you own a domain to having a tumblr or reddit accoun. The definition of those checks will all be publicly reviewable, both in the spec and in the client, which is what checks them for you.
Authenticating a self-signed domain certificate via keybase is a neat idea, but would probably need some browser support, unless there's a clever hack that I'm not thinking of.
If you want to encrypt a message to my key, just run the following command:
gpg --auto-key-locate pka -ea -r mike([-dot-])cardwell([-at-])grepular([-dot-])com
mike@glue:~$ dig +short txt mike.cardwell._pka.grepular.com
"v=pka1\;fpr=35BCAF1D3AA21F843DC3B0CF70A5F5120018461F\;uri=http://grepular.com/0018461F.pub.asc"
mike@glue:~$Obviously Twitter isn't likely to implement either of those, so some high-value custom implementations are still great. But if Maria owns maria.com and can assert it automatically, that's pretty strong supporting evidence.
This form has essentially the same level of security as Hushmail. Anybody using it should consider the content exposed to Keybase or anyone compromising Keybase.
In the keybase Web client, all crypto happens on the browser. The server knows no keys or data in plaintext. Of course, you'd have to audit the front-end JS code to believe that claim.
But our intention is that the only way to compromise the Web-based tools would be to insert malicious JavaScript into the client's browser. A read-only compromise of the server yields only encrypted data, and the server never has access to the decryption keys.
Next, people usually mumble about auditing it, downloading a copy, signing it, etc. At the end of the day, you arrive to code installed on the client - which you already have.
The web version just weakens your story.
Incidentally, you can't simply audit the "front-end Javascript"; you have to evaluate everything that influences the Javascript runtime (the DOM, stylesheets, cached resources, &c) every time the page loads. Browsers aren't designed to make content-controlled code "auditable"; it simply isn't a capability of the environment.
Rather, the server replies with links to tweets, gists, etc. -- maria's public identity proofs. The keybase client does not trust that these are honest, so it scrapes them directly and makes sure they were signed by the same public key that the server provided. In other words, the server could reply with a different maria, and simply lie, but not with the real maria's github or twitter account.
The server could also lie by omission, leaving out an identity. But it cannot invent ones that do not exist, without the client knowing.
Again, the premise here is that maria is the sum of her online identities.
The website itself is of course a different story. When you look up maria on keybase's website, you are trusting that keybase.io did not lie about her github account. Fortunately you can confirm by following the link to her gist, where she announced her keybase username and posted her key fingerprint.
There's a reason that gpg does this..... Maria's twitter being hacked, Maria's github being hacked, Maria's Keystore being hacked....a lot can go wrong.
There are still weaknesses like, you lie about a github and link to your own github, and lie about the public key. And...many others.
SSL CAs:GnuPG (GPG/PGP) -> Subversion:Git
Also, WoT works best when people meet other people they trust in person and sign each other's keys as the GNU/Linux community encourages. https://www.kernel.org/signature.html Then it's possible to get other people's keys elsewhere on the planet and know they're probably good given they're signed by someone you trust.
GPG mail plugins that popup a barcode that someone else can scan with their laptop's webcam or some mobile app.
GPG mail plugins should also have a search toolbar that can quickly get a key so it can be verified.
Mobile platforms must support GPG natively, many only support S/MIME.
Her portfolio: http://www.hadilaksono.com/
> keybase id maria
pgp: C4B3 15B4 7154 5281 5100 1C58 C2A5 977B 0022
github: mаria_leah ✓ https://gist.github.com/23423
twitter: mаria_h20 ✓ https://t.co/mаria_h20/523554
site: mаriah20.com ✓ https://mаriah20.com/X904F...
Maybe the client should apply some logic as browsers do for IDN homograph attack to show characters not in your locale in a different way, or at least warn you.
But for future identity proofs (domains, for example, which we've yet to implement), this kind of attack is real. Our approach here will be that anything outside of normal ascii will be highlighted and addressed to the user, as a serious warning.
Great idea and good luck!
It does demonstrate control of the email account, and you cannot fake it either.
Despite this hope, I can't seem to help the fact that the first thing that popped into my head when I read their webpage is "oh, they're wrapping and abstracting important key authentication and critical key trust configuration to make it more user-friendly, and implementing it all in javascript. WHAT COULD POSSIBLY GO WRONG?"
Even if I got whacked on the head one day and suddenly loved javascript, I would not use it for certain projects when I wanted to be taken seriously by, say, cryptographers.
Then again, look at all the success cryptocat has had!
The average skill of developers using a language is low, therefore it's not possible for anything written in the language to be of high quality?
Wow. Even assuming that the initial assertion is correct, that's horrifically illogical.
True reason: you have an anti-js bias. You're welcome to that, but for goodness sake be rational in your hatred.
On a serious matter, javascript (eg all browsers) absolutely needs to change to make the web more trustworthy. I agree with some of the Matasano points[0], but these are the minimum, exhaustively complete changes that would improve browser security:
i. js that can be cryptographically signed and verified, a trust model and a browser security policy to enforce it.
Think ascii armored GPG signature as a comment for the code it encloses.
ii. js native extensions: able to talk to native code that was previously installed
iii. js objects that can be made immutable (can't change them in any way)
iv. js objects that can be made un-protypable (can't copy or "subclass" them)
v. js properties that can be made read-only
vi. js properties that can be made private (only the object itself can use them)
With folks pushing to make this happen across all browsers, javascript theft of bank passwords and credit card numbers would be much harder. Crypto stuff like the Stanford library would benefit.
References:
0. http://www.matasano.com/articles/javascript-cryptography/
I cannot support a project that doesn't build and strengthen the underlying WoT. Getting https involved for authenticating unknown keys is a huge step backwards. Madness.
You can still verify the keys with your client's cached copies, or using another PGP client.
`keybase-installer` needs an initial install over https from npm. We unfortunately saw no way around this.
Assuming that install succeeds with integrity, then all future upgrades of the installer and client are verified with PGP keys stored locally on the client.
Once the client is installed, it speaks HTTPS to the server, but we're not trusting the root CA. Rather, we sign with our own CA that we ship with the client.
The proofs themselves, on twitter and github, all can be verified in the clear, as FiloSottile points out, but of course relying upon the HTTPS certificates of twitter and github to make sure the proofs weren't corrupted in transit between those services and the client.
Write it in a language that has a packaging system not designed by amateurs.
Browser crypto can be scary! Do you have a malicious extension installed? We can't tell. Further, how can you guarantee we haven't been tortured into serving you custom, targeted JavaScript? Hopefully you're not that important.
I realize malicious extensions can currently do as they please, but can't browsers allow extensions to define a security policy that forbids all other extensions from modifying a page? This policy could be specific for a single website: Keybase.
Because if browsers could do that, they could then support proof carrying code, which could be used to verify Keybase hasn't been tortured into serving a custom, targeted JavaScript.
Remember, I can introduce any code I want so long as I control the server which is serving your web page. JavaScript crypto is an attempt to not trust the server serving the data, but if that server, or any other server can inject any code into the web page which is handling the encrypted data, then you have no security. You are still left trusting the server to not screw you. Which is the same as using HTTPS which we already have today.
For example, to make it impossible for code sent by a server to execute any Javascript (or other scripting languages) at all. The server could instead send a data structure (as opposed to code) describing what to do, without having the power to replace any encryption functions or to execute additional functions that can subvert encryption. I realize a first version of this might sound too restrictive, but the point here is to show how it can be made to work.
If it's possible to reduce what the server sent to the browser down to a fingerprint, it will also be possible for the browser extension to verify this fingerprint with multiple third parties. It can verify the fingerprint of the server code matches a fingerprint published on Twitter, or GitHub or other sources, which is something Keybase tries to do.
An attacker would need to break into all (or at least a majority) of those services to serve you bad code. Which is harder than breaking only into your server.
Forbidding other malicious browser extensions from interfering with a Keybase browser extension would allow the Keybase extension to perform all this fingerprint-checking logic with the guarantee the verification hasn't been tampered with.
The point of web applications is that you can quickly distribute an application that runs on a common platform to everyone at once. It's a very nice idea. It is also insecure to boot.
You are proposing two different changes. First, an enhanced ability of your web server to tell my browser which code is allowed and which code is not. This is good. This way, for example, my bank running on bank.example.com can tell my browser to not load any JavaScript code, or even any external resource from anywhere but bank.example.com. Now nobody can inject a JS file from evil.example.com. Fine-grained control over what the browser should and should not allow is a good thing. Controlling extensions is a bit different. I want my extensions to work. I want my ad blocker and my privacy guard to function even on sites like my bank's. In general, I would not want a site like Google to disable my ad blocker, that would be evil.
Now, if you are saying that you want to sign this application and distribute the signature to other services so that I as the user can verify that the application blob I got from your server has not been tempered with, then how do you go about updating your application? If you found a critical bug in your JavaScript code and fixed it, now you have to create a new application blob, a new signature, and distribute that signature to all these other services that are supposed to arbitrate whether you are delivering honest code. Notice that you and you alone still control the signatures. There is no external verification that you are not delivering evil code to me, I still have to trust you, personally. Adding a signature/checksum means that the code you delivered has not been tempered by a third party, but it says nothing about you. And the point of in-browser crypto is so that I don't have to trust you.
That's where the whole thing breaks down. If someone forces you to change your code, then update all the signatures and launch this code, then I still have no idea that it happened. So at best this might protect me from a malicious third party. But guess what? HTTPS already does that, and is a much simpler and proven solution.
In-browser crypto does not work, and will never work. There is no way to make it work. The web is not a platform where the client can treat the server as untrusted. Every time I see an attempt at this I cringe since someone clearly wasted a whole lot of effort thinking they finally cracked it. Keybase is probably the first place where I am not completely against it as they are using it as a demo of what your actual client would be doing. Then again, they could probably have just scrapped it completely and done the whole thing server-side without so much effort.
The alternative to what you are trying to achieve is this: every website is distributed as an open source application blob and a number of trusted third parties reviews the code before it gets published. These third parties each sign the the code with their private keys, showing that the believe the code to not be evil. The problem with this is that it completely undermines the central promise of the web application: instant deployment to all your users. This system is exactly what you have with Linux distributions' repositories. It work, it's secure, but it's slow.
Advantage: it's distributed
What happens when Snowden uses it and the USG requests access?
Oops.
Businesses / nonprofits cannot provide privacy-as-a-service unless they're "SWAT proof" (distributed).
Advantage: SKS is "SWAT proof."
Sounds like a datamining goldmine too, but what do you expect from OkCupid founders.
btw had to do it. https://i.imgflip.com/6w8mc.jpg
I'm like, wow, if that's the only issue, that's great lol. Sounds pretty easy to fix ;-)
On top of this....I think this is cool in theory but bad in practice.
The assumption that Root CA's are trustworthy is already hard enough to make, how do I know that Maria is actually Maria? How will you verify that ``Maria'' actually owns that twitter, github, gmail. Maybe it is possible to devise some type of scheme for those sites, but how about more obscure services?
One mistake in one single account causes the entire thing to fall apart...
> confirmed they're all her, using GnuPG to review a signed tweet and gist she posted.
So it sounds like it you believe in GPG as a viable method of id, there's no reason not to trust this.
That's the part where you trust the PKI, and that part is easily subverted, breaking the trust of the entire system.
If they were using the inherent properties of maria's key (e.g. the fingerprint), then they wouldn't need this whole silly website and username database.
Maybe this should be an offline tool that just goes and fetches tweets and gists so we don't have to trust them. You could add friend mappings with key fingerprint + nickname.
I add it and use it. When you use this, I'm assuming I get that key every time from the server. I can get it and verify it once, or twice, or three times, but what about the 1000th time? What happens when I am important enough that they return a public key that is not Maria's, and I am none the wiser.
I think what Keybase is addressing in the status quo is twofold: (1) sadly, almost no one does what you describe; in person meeting key exchanges and webs of trust may sadly be as unpopular in 20 years as they are now, and as they were 20 years ago. People who go to them are often confused, even programmers. I wish it were different.
And (2) more important, in 2014, often the person you're dealing with is someone whose digital public identity is what matters, not their face in real life or phone number. If you know me online as github/malgorithms and twitter/malgorithms, to get my key, meeting someone in person or talking on the phone to someone who claims to be me is actually less compelling than a signed statement by malgorithms in all those places you know me.
And if you do know me in real life, then I can tell you my keybase username and fingerprint, exactly as you're used to. So it's still as powerful for meeting in person. With the added benefit you can confirm my other identities, which you likely know to.
In answer to your scenario about verifying: you only need to review the "maria" the server provides once, and then your private key signs a full summary of maria -- her key and proofs. Cases 2 through 1000 of performing a crypto action on maria involve you only trusting your own signature of what "maria" is. The client can query the server for changes to her identity, and this will be configurable; if maria adds a new proof, you might wish to know.
You could of course manually review and verify Maria's github post that contains her public key - all that keybase is really doing here is providing an easy way of discovering that github post (or tweet, or whatever).
The high bits are: all crypto is with GPG/RSA as per RFC4880. There are of course problems here, but we wanted backwards-compatibility and well-tested, well-used clients.
We encrypt server-stored GPG private keys (if you choose to use that option) with TripleSec (see https://keybase.io/triplesec).
Users use GPG to sign a series of JSON objects, of the form "I'm maxtaco on twitter", or "I checked Chris's proofs as of 2014/2/14 and they look good to me." All JSON objects that a user signs are chained together with SHA-2 hashes. So a user can sign the whole group of JSON statements by just signing the most recent one.
Here's an example (click on "Show the Proof") https://keybase.io/max/sigs/ZnBizHMA8RKSB598TaDtjlPlLKSEu1Wu...
There's a fair amount of engineering that went into the software distribution system. We rely first on npm to get the initial client out there, but after that, exclusively GPG for code-signing. That's documented here:
https://github.com/keybase/node-installer/wiki/Update-Archit...
We hope to have better documentation soon, and we value feedback, we just haven't had the time to put it together yet.
I downloaded the command line util and tried to login, only to be let down :(
Excited to try it out!
So my first question is this: if I know "maria" and I want to look her up to get her GPG key, how does keybase handle that? Does it just do an email address lookup, as in goes to, say, GitHub, grabs her email address, maria@example.com, then goes to a public key server and grabs the key that corresponds to maria@example.com?
If that's the case, there is a security issue: what if Maria never published a GPG key, but Chloe did using Maria's email address? Moreover, what if Chloe has access to Maria's inbox and can read these messages I believe to be only readable by Maria?
Edit: I see from responses below that various online presences of an identity tied to "maria" are checked. Is this not then susceptible to its own attack? For example, if Maria does not have a Twitter account and I create one, or compromise hers and post a different key, will I be able to at least introduce doubt into her identity, if not take it over outright?
We want the server to be untrusted, ideally just a dumb message router.
If Chloe wants to impersonate maria, she'll need to get control of maria's twitter and github accounts. Just claiming maria's email address won't get her anywhere. (Note that GPG keyservers are susceptible to exactly the attack you describe).
The other part, where you check Maria's Twitter and GitHub accounts, means that a few things like Twitter, and GitHub are impervious to Chloe: a tall order and a centralized one at that.
Once again, is the point here for me to get a tuple of (email address, public GPG key) so I can email Maria securely? If so, then someone somewhere has to prove that this tuple fetched from the public key servers is valid.
If the point is to only communicate via keybase.io, then the service is centralized, and useless once actual sensitive info is exchanged, the US government takes notice and shuts it down at the DNS level.
To answer the question, the point isn't to get an (email address, GPG-key) mapping. It's to get a (public-internet-identity, GPG-key) mapping. People sometimes do this today in an adhoc manner (e.g. tweeting your GPG fingerprint). We want it to be checkable by user-friendly software.
All public server-side data is available as a dump (https://keybase.io/__/api-docs/1.0#call-dump-all). Private data like encrypted public keys and password hashes we of course will keep under wraps.
We don't have immediate plans to make the system distributed, but if someone did it, we'd find it very cool. It's just too much for us to do right now.
This looks like a great step in the right direction.
One thought is vouch and level of credibility by the person's profile. If a lot of people vocuhed for Maria or if Maria has a lot of active tweet and/or a lot of Github activity there is a good chance this is a real Maria. However, the activity-based credibility is easily forged and defeated so probably not a good idea to add, bur worth thinking about :)
As a former Opera user, I certainly sympathize though.
For reference, I'm using Firefox 25.0.1 and Chromium 30.0.1599.11 in Linux.
Also, being able to use this with arbitrary crypto software (eg GPG) would be even better!
You might want to include some links that explain what the keys are, what PGP is, etc - because not everyone who lands on your site will know.