Introducing Keybase Teams
keybase.io
keybase.io
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!
Edit: Additionally, are team names private? Can they be discovered without guessing them? If you guess one, can you prove it exists?
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.
(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.
+1 – use case for us is sending creds between team members/with clients/etc that we don't want to share permanently via 1PW/other vaults.
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.
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.
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.
The one thing that worries me with this sort of thing is the "oops, I typo'd" something factor.
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.
I would happily pay for kbfs alone and I would hate to see them go under because they run out of money.
But until then, I"ll totally build you a self hosted solution. I'll even work remote.
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.
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.
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.
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.
Someone could still spoof "companyname-corp.com" but then it's at least obvious in the same way spoofed URLs already (usually) are.
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`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.
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.
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 :)
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)?
18 months or so ago I wrote an app called AnyCrypt, utilizing Keybase under the hood: http://lettergram.github.io/AnyCrypt/
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?
But I'm wondering if they are not actually logging your keystrokes (or google analytics).
Otherwise, AnyCrypt looks awesome.
I don't believe this comment.
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?
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.
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?
Sorry to be such a pest but I've spent probably too much time banging my head against this problem. Thanks!
[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.
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?
https://github.com/keybase/client
The idea of the design is that if you trust the client there's no need to trust the server.
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.
> 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 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.
More info here: https://keybase.io/docs/teams/puk
And you've been on HN 3+ years and not seen all the keybase proofs in peoples' profiles? Mine's a good example.
That's a scary thought. Building this type of software takes a lot of money.
> And you've been on HN 3+ years and not seen all the keybase proofs in peoples' profiles? Mine's a good example.
I rarely check profiles.
I'd argue that this is the point of raising investments prior to there being a product which may generate revenue.
% keybase team create caltech
ERROR this name has been reserved by Keybase staff, perhaps for your team. Reach out to (email redacted) for more info. (code 2650)
Tried multiple generic names as well as some random companies. Might I ask what you are basing your "blacklist" on?
keybase chat list-channels equifax # spoiler: none found
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.
(PS, keybase has public, try --public flag on keybase chat send)
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.
Depending on how big a team can be, how many teams you can join, and how easy it is to forward, this may just be a matter of UI and scale.