Blog author here. In the interest of keeping the post more of a summary, we left the cryptographic details to our docs. Here's a link to that: https://keybase.io/docs/teams/index . We're happy to answer questions here.
This really is an exciting product for us. Once you can define a team, cryptographically, without server trust, a lot of other things follow. We'll be launching some of those things in the coming weeks.
Also left out from the blog post: teams (and chats) can be controlled through a local API, so pretty much everything in Keybase can run in the form of a bot, also without trusting Keybase servers. Cheers to crypto!
@malgorithms is there any support to change usernames? Before teams, I had a company PGP key under the company name, but with this launch I can't create a team with the defacto company name since it's already in use.
I have the same problem.. The only obvious possible option is deleting the whole account, but even that says "If you delete your account, you can't get it back, and you can't create another account with the same name." so you might not be able to use it as a team after deleting.
Can the team creator give up admin rights on the team without resetting her user? I want to create a team for my employer so we can try it out, but I'm not the person they would want to be the admin if/when they adopt keybase.
Yes, you can be the initial owner and then add other people as owners (or admins). From there you could downgrade yourself to a regular user - or if they're owners, they could downgrade you.
They could also kick you out. I've done this a few times today. We reserved a number of team names for known tech companies, and when they've asked, I've created the team myself, added a couple of their managers as `owner`s, and then they've booted me.
You can think of the team's sigchain as just a string of signed announcements. You can sign someone else in as owner.
> We reserved a number of team names for known tech companies
I think this demonstrates the problem of creating completely new namespace from scratch. One way to solve that would be to couple the team namespace to DNS namespace; to claim a team name you'd need to demonstrate the control of corresponding DNS name, same way as you do for DV certificates. Of course I can understand that you'd want to support teams for organizations/groups that might not have their own domains, but you could support such cases by creating a "pseudo-TLD" (or just straight up buy your own TLD), for example .keybase.
But control over DNS can change, right? If you sold or forfeited your domain name, how with this separate authority know to revoke your access to the team name as well? Should they even do that?
OT, but I'm curious what are the scenarios in which somebody (except keybase.io) can lock me out of my account?
If I understand keybase correctly, if somebody were to say deploy some malware on my computer, thereby getting both my password and one device key, they would be able to completely take over my account, revoking each other key, and I'd have no way of getting my account back.
Obviously if somebody gets a device key, they would get access to all data, but is there any way to prevent the above from happening? So I could revoke the compromised key(s) and setup anew. Aside from manually having somebody at keybase do so.
Can you post some information about this local API? I'd love an interface for building end-to-end encrypted bots, but I haven't found anything that allows that yet.
`keybase chat api --help` gives a bunch of examples. There's more possible than what that suggests, but it should be a good start. We'll expand the docs soon.
We have already written a number of internal bots at Keybase. We have one that posts all our github commits into a channel, for example.
Does the presence of files in the teams feature mean that kbfs will be rolling out to the iOS app? Its been "coming soon" for awhile now and has always been the more compelling feature to me than chat :) Either way, congrats on the release, this looks really awesome!
It'll come after some improvements to team management and chat. But it isn't that much work, technically. KBFS is already running on your phone and understanding the filesystem... (your phone helps rekey data when needed.) It's just about building an interface around it. Which is no small task. It needs to be good. Hopefully soon.
Answer to your edit: team names are not private, as their hashes can be found in our merkle tree, which anyone is free to mirror or lookup. So if you name your team `foobar` someone would be able to hash foobar and look it up, and yes, prove it exists. This is a feature, not a bug :-)
But if you picked a team name with very high entropy, then I guess that would be semi-private in that it would be undiscoverable by brute force.
"The very existence of subteams are hidden from all who aren't members of the subteam. Thus, if you wanted to create the team `lets_fire_bob.just_kidding_fire_bruce`, then Bruce would have no way of knowing his number is up."
we pushed it behind teams, but we'll do it soon. 2 things we want to work on shortly:
(1) switching to short-term exploding message mode (what you would expect from OTR), so your messages can be read and then disappear. And devices don't cache them. This has inconveniences, especially for team chat, but it's what you might want in certain sensitive situations or certain DM's.
(2) a message auto-deletion policy for the team. This is different, and it's been requested by some testers.
I second you! I think that Keybase holds a lot more potential than most of the Blockchain unicorns floating around... I'd be happy to pay for kbfs to gain some assurance that I won't lose everything because the company went under or got acquired by someone with less scruples.
Thirding this. I’m a huge Dropbox user now but the public folders and the file syncing provided by kbfs check all the same boxes I care about, with none of the privacy or ethical issues that company has. The only reason I haven’t moved already is because the future is uncertain wrt. future cost.
Cool! Pay me and I"ll build you a linux server with mattermost and git on it. You can self host all the things they're putting together here on keybase. And it's free now, but it won't be for too much longer, soon there'll be freemium and then a full paid service. Because they want you to build an environment and workflow around it, and once you're making money with it you'll gladly pay a bit in a few years or so when you're large enough to afford it.
But until then, I"ll totally build you a self hosted solution. I'll even work remote.
Am I confused on mattermost's feature set or did you miss that end 2 end encryption is the core "product" of Keybase and everything else is addons to that?
> But Keybase teamwork is end-to-end encrypted, which means you don't have to worry about server hacks. Alternatively, you can lie awake at night...fearing a breach of your company's messaging history. What if your team's history got stolen from Slack and leaked or published? The legal and emotional nightmare.
I think it's great that this is an e2e solution, and obviously the path for an attacker from total compromise of keybase, to total compromise of user data is one step removed - it needs to go via pushing a backdoored keybase client (or, ahem, a secret entity needs to force that to happen).
But either way, in terms of a targeted attack for a company's data - surely the clients (phones, workstations) are the weak point? In other words, I think the paragraph oversells the benefit of e2e a little bit?
This isn't really keybases' fault - consumer computing is pathetically insecure and hard to secure (with the possible exception of iOS devices). That's just how things are right now.
> But either way, in terms of a targeted attack for a company's data - surely the clients (phones, workstations) are the weak point? In other words, I think the paragraph oversells the benefit of e2e a little bit?
Literally no encrypted channel is secure against a client-side compromise that allows an attacker to observe the conversation. It is effectively equivalent to a trusted user deciding to knife you in the back.
Even e2e 1:1 conversations have that weakness. The trust in the group is only as strong as the human element (and in the case of computing, the least secured client device).
So I don't think it really oversells it, personally, given the fact there is no option that is universally agreed to be substantially better secured and immune to a traitor and/or compromised client.
" it needs to go via pushing a backdoored keybase client (or, ahem, a secret entity needs to force that to happen)."
Or just one or more packets directed at the client if it has some kind of listener open with a vulnerability. If nothing else, most security-focused apps don't do covert channel analyses. If this one doesn't, its secrets might be intercepted through storage or timing channels via another compromised app (even unprivileged) on the computer. Mitigating that usually has a performance hit and/or takes a language whose operations map pretty well to hardware where developers can estimate timing well.
So, they've removed one step. That's good. Opponents don't have to go straight to subversion from there, though. There's a few more possibilities.
Looks like they registered more than just a "few tech companies," I've gotten the following error message testing which names they might have blocked: "this name has been reserved by Keybase staff, perhaps for your team. Reach out to chis@keybase.io for more info." Some names tested: Ford, Nike, Safeway (though wholefoods was available- while "wholefoodsmarket" was reserved). Tech seemed pretty well covered: Google, Robinhood, ProtonMail, all throwing the above message.
I'm curious about the decision to make team names globally unique and unchangeable. It obviously has some trust benefits in that you can't spoof a team if you know the name, but shouldn't the proof of legitimacy be in the membership and signature chain, not the name?
If Keybase popularity grows, then any sufficiently large company will probably have to use "CompanyName-Corp" or something equally vague as their team name would be taken by squatters. A malicious user could invite someone to "CompanyName-Corporate" and most users probably wouldn't even notice.
There are so many conveniences around a global team name. Any time we played through the mental exercise of ambiguous names, it led us back to the deep pains of reading out loud security codes or fingerprints, or relying on some kind of hard-to-use web of trust around trusting people and then their vouching for teams. (note people, too, have unique names.)
With our testers, I've already had so many conversations about team names. If it's an in-person conversation it's validated entirely without looking anything up. If it's digital over an alternative medium - then the sharer doesn't have to go look up their team's identifier in order to talk about it. Everything is easier.
Also, I'm not that cynical by nature, but I've had a lot of conversations with people about security since we started Keybase. People don't check codes. From encrypted chats to SSH server fingerprints (ugg!) -- people don't check them. If a team name can be equivalent to one, but the cost is that the space is limited, it's worth it.
I guess in summary: why is a name better than a fingerprint? It can be memorized without effort. It can be visually or verbally reviewed without effort. And it often has meaning.
> [A name] can be visually or verbally reviewed without effort.
Have you considered the possibility of typo-squatting, look-alike Unicode characters, and other such tricks (basically all the same tricks people use for domain names)?
One option could have been to use top-level domains for a team (e.g. add a TXT record to prove ownership of 'example.com' and then you can create that the 'example.com' team).
Out of interest, is there a reason you didn't go for that? Would be easy to memorise and validate while also ensuring uniqueness. Feels like it could also play in quite nicely with letting people on-board — e.g. you could have a feature that anyone with an email address in my domain is allowed to join the main team without needing admin approval.
That said, this sounds great — can't wait to try it out :)
Requiring the team name to be a domain name (validating that they own said domain name) seems like it would be a reasonable solution. Domains are already globally unique, already tied to organization identity, and already closely related to anything keys will be used for (software, e-mail, etc).
Someone could still spoof "companyname-corp.com" but then it's at least obvious in the same way spoofed URLs already (usually) are.
Domain names as identity is something I would love to see happen, mostly because I have a vested interesting in selling millions of people those domain names via Hover.com
Keybase does a nice job aggregating those various identities, be it a domain name, Twitter handle, HackerNews ID. It's probably a better solution to help people/businesses establish an interconnected series of online identities that are provably the same entity.
ps. Thanks to Chris for reserving some of the more common team names including hover and making sure we could get our hands on it.
This actually seems like a remarkably elegant solution to the above problem. I'm hesitant to make it domain linkable though. A cool kind of solution to ambiguity would be a graph network, say "join team X with members X,Y" to identify the team uniquely. And that is referenced to the people you're linked to on keybase, and the groups they're in. If a group by the same name exists with the same named people, it shouldn't be picked over the correct group, and if it were, you would be rejected from joining the team.
What happens if you forget to renew your domain name, or someone steals it by the trademark rules? Would that person then gain access to your encrypted chat?
If it's just a pointer to a merkle root for the admin chain then they don't get access to the encrypted chat, they'd still have to request access from an existing user.
You could simulate that today by say creating a weird named team (say random GUID), adding a text file like .well-known/keybase-team.txt on the domain with that team name, and then encouraging people to sign up via something like:
keybase request-access `http GET http://example.com/.well-known/keybase-team.txt`
The idea was to make it easier for my friends and I to send encrypted messages over any medium. Facebook Messanger, Slack, G chat / hangouts, etc. Facebook couldn't look into our messages, and everything was pretty easy. It took two clicks, which was a pain.. but because we were security conscious we could power through.
On the other hand, most people I work with, my family, other friends, etc. don't have the patience for that. It needs to be no clicks to at max one click. The current route keybase is continuing to take is a command line interface with multiple commands necessary.
The CLI is simply not going to catch on for the normal user. The experienced users just use their own PGP keys and manage it.
As for the new interface, it does look nice. However, the fact it needs to be a unique chat name is kind of a pain. Why not just sign a unique identifier to the chat, then rename locally? Similar to the way Signal does it? Also, what happens if you recent your PGP key?
Have you thought about having the extension read all of the page, look for PGP encrypted message and automatically decrypt the message? It wouldn't be compute intensive if you optimized for a specific website. Also getting the submitted message and encrypting on the fly?
Also, have you thought about how this could work for phones?
That's how it works, just searches the page for the pgp messages. It checks for messages on DOM changes.
FireFox on mobile enables add-ons, so it would work on desktop or mobile if I wanted to do that. However, this was more of a proof of concept. It worked and works well with friends, but we no longer use it all that much.
Usable security sure is hard. My problem is I was invited to keybase back in the old days by a friend. I played with it, and soon forgot it existed. I've just been trying it out again, and it has changed a lot for the better. I feel like someone who isn't completely incapable of computers could make sense of it with some coaching. However, getting grandmother on keybase probably will never happen. :)
[edit] But what is up with the command line tools on macOS? I expected to find them in one of the usual bin locations so it would be in $PATH, but I ended up just aliasing it in my zshrc. It would seem that a symlink to the executable from /usr/local/bin would be appropriate if it needs to stay inside the .app bundle.
How did you deal with text injection into react forms on facebook?
Whenever I interact with text in a form field on facebook via a browser extension, it is not picked up by react, and the original text is what is picked up on submission. I've banged my head into this problem repeatedly. Is there an easy fix or is this something much more subtle?
I mean on the encrypt side, not the decrypt side. When I try to put text into a react form, react doesn't pick it up - it still uses the original text in the input form. I will definitely look at that code though, thanks!
I won't pretend to be an expert, but very vaguely, if I know anything about react: you would have to modify the local state of the form (if it's possible at all by a 3rd party in fb frontend code) and react/flux will modify the dom for you. If you go more directly (on the DOM for example) you will get overwritten by the current state as soon as react re-renders
sorry I'm not @lettergram, so I cannot really help you with his code; I never tried to inject code into a facebook page, but I can imagine that especially after minification it's going to be a pain to do
> But Keybase teamwork is end-to-end encrypted, which means you don't have to worry about server hacks. Alternatively, you can lie awake at night...fearing a breach of your company's messaging history. What if your team's history got stolen from Slack and leaked or published? The legal and emotional nightmare.
I don't know why but I'm really put off by the negative marketing. Using Slack has obvious drawbacks from data security perspective but is using a closed source, hosted software like Keybase correct solution?
I haven't had a chance to try the app yet, but I'm very curious: how will searching work? That's the only real thing I can imagine would prevent this from replacing slack.
The principle is good but people are criticising the implementation; arbitrary strings in a flat namespace is messy and confusing.
Domain names have already established general rules and procedures for this event and basing the team-names on subdomains would have been cleaner and saner than trying to reinvent the wheel with blacklists and human reviewers.
Who gets ford as a team-name, Ford Aviation a small charter operator in the UK or Ford Motors? Domain registration has already resolved that one.
If I stay in a team chat for a long time including files and all of that do all of my devices keep a copy of everything said and worse every file posted?
I was shocked to find they had reserved a bunch of names I wouldn't expect. A friend of mine theorized they may have reserved companies listed on Crunch Base. So far that theory hasn't been proven wrong at least!
I'm getting this error upon trying to create a team:
> can't create a new team without having provisioned a per-user key
According to the docs (https://keybase.io/docs/teams/puk) it should have automatically been created for me, though? Not sure if relevant but I did not use the auto-updater to update Keybase for macOS (if there is one), I just downloaded the latest DMG.
In case anyone's curious, all Keybase users are now getting "per user keys" (PUKs). It's a key whose secret key is encrypted for each of your devices, and whose public key is advertised publicly in your sigchain. New users get a PUK right away, and older users run a background thread to make one. wilg's thread missed a window and would have rerun in 50 minutes, but he solved the problem by starting up a different device.
In turn, all team crypto operations happen for PUKs (and not device keys) so it's necessary to have a PUK before you can use teams. These details are mainly hidden from users, except for bugs (as above, but we'll fix it soon). This is a change from previous designs, but the advantage is that when a user adds a new device, she'll get instant access to all teams, when the PUK's secret key is encrypted for the new device. Whenever a user deletes a device, there's a rekey cascade --- the user's PUK is rotated, and so are all teams the user is a member of.
From the link: "On device revoke, the revoking device makes a new master key, encrypts for the private key for all remaining devices, and writes the new master key to the sigchain along with the statement revoking the old device."
Exactly. Sorry for the doc bug there. s/master key/PUK/g, now fixed on the site. An earlier internal name for PUKs was "master keys" but we've since changed.
I have the same error. And what's strange is I believe I do have a per-user key on this device. At least I think I do, based on the output of `keybase device list`
That's not the primary motivation right now. Much of the investment they're attracting is in support of building the technologies to support products down the road, as best as anyone can tell from the outside. malgorithms can correct me if he's feeling it.
And you've been on HN 3+ years and not seen all the keybase proofs in peoples' profiles? Mine's a good example.
To be honest, although I haven't been around that long, I have noticed the keybase proofs and still wondered about the purpose of the company as a whole. It seems to have something to do with identity, but other than that I haven't been interested enough to search out more information about them.
Especially since it's not available on appstores (either Android or Apple) in France apparently. I've seen french crypto import regulations by the ANSSI cited as a reason, but nothing official from keybase.
This looks like the start of a viable social network with very strong security.
At one point I would have thought that's great, but now I find it vaguely alarming. Maybe this is overly cynical, but I wonder what happens if it really starts to take off (say, growing towards Twitter scale). At what point does it become yet another social network that's degrading into a cesspool? And how do you get out of that state when everything is cryptographically locked down?
The lesson of Bitcoin seems to be that cryptographically irreversible actions combined with valuable digital assets (whether coins or, say, celebrity accounts) have a tendency to attract scammers and hackers, so you better be certain that your client machines can't be broken into and that you're immune to social engineering. And who is that certain?
I'll probably try it out, but I think undo buttons are really important. I'd be more comfortable if there were some trusted people who can roll back mistakes and fraud after they've been discovered and proven. (But, then again, how do we know they can be trusted?)
I guess this is all just FUD, but, hey, I'm feeling it.
But it's not a social network. There's no public posts, there's no leverage-your-friend-network aspect. Messaging platforms aren't social networks (e.g. Slack isn't a social network). File storage/sharing platforms aren't social networks. The only social aspect here is following other users and seeing who they followed/are following them, but that's just a trust thing, following someone doesn't e.g. expose you to posts made by them.
Huh, I didn't know about --public. That's interesting.
But that doesn't make it a social network. If Keybase had a mechanism to follow a bunch of people and automatically syndicate all of their public posts into a single stream that could be consumed by a desktop app, then this would be vaguely Twitter-like. But it appears that you have to manually query every individual user whose public posts you want to see, which doesn't scale to automatically following lots of users, which means this feature as-is isn't going to be used to clone Twitter.
This really is an exciting product for us. Once you can define a team, cryptographically, without server trust, a lot of other things follow. We'll be launching some of those things in the coming weeks.
Also left out from the blog post: teams (and chats) can be controlled through a local API, so pretty much everything in Keybase can run in the form of a bot, also without trusting Keybase servers. Cheers to crypto!