
Introducing Keybase Teams - jashkenas
https://keybase.io/blog/introducing-keybase-teams
======
malgorithms
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](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!

~~~
amingilani
@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.

~~~
V99
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.

------
xwvvvvwx
So I think Keybase is an amazing product, and this seems great as well, but I
get a bit stressed that everything is free.

I would happily pay for kbfs alone and I would hate to see them go under
because they run out of money.

~~~
mwambua
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.

~~~
Karunamon
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.

------
e12e
> 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.

~~~
AFNobody
> 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.

------
arosier
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.

------
ScottEvtuch
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.

~~~
malgorithms
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.

~~~
another-dave
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 :)

~~~
azag0
Potentially, they could still roll this out, because a dot, ".", is currently
not an allowed character in a team name.

~~~
chias
That's because it's used to designate sub-team (e.g. companyname.infosec is a
sub-team to companyname)

------
lettergram
I like the service keybase provides, but I don't think it has any chance of
taking off with the general public.

18 months or so ago I wrote an app called AnyCrypt, utilizing Keybase under
the hood:
[http://lettergram.github.io/AnyCrypt/](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?

~~~
libertymcateer
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?

~~~
lettergram
If i recall correctly, just look for DOM changes. The code is all open, so you
can look at it.

[https://github.com/lettergram/AnyCrypt/](https://github.com/lettergram/AnyCrypt/)

~~~
libertymcateer
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!

~~~
scotu
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

~~~
libertymcateer
Forgive the million questions - is this not what you are doing on facebook? Or
is it only working on facebook chat? Is that not react?

Sorry to be such a pest but I've spent probably too much time banging my head
against this problem. Thanks!

~~~
scotu
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

------
hdhzy
> 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?

~~~
azag0
Closed source? [https://github.com/keybase](https://github.com/keybase)

~~~
hdhzy
Which repo contains the server part and the JS frontend?

~~~
davidbanham
The client is in this one:

[https://github.com/keybase/client](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.

~~~
hdhzy
I understand the trust model but it still does not qualify as "open source" if
the source is not available.

------
hamandcheese
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.

------
fiatjaf
I don't know why this is being presented and commented about as a bad thing,
but globally unique names for teams, just like for users, is very good.

~~~
dingaling
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.

~~~
fiatjaf
How? Domain name squatters do exist. And domain names can change ownership.

------
dexterdog
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?

------
koolba
Very cool. Regarding team naming, is there anything preventing one from
registering "google" or "google.com" as a team name?

~~~
frenchie4111
In another post the blog author mentioned that he reserved team names for a
bunch of well-known tech companies.

~~~
jsjohnst
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!

------
wilg
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](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.

~~~
maxtaco
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.

More info here:
[https://keybase.io/docs/teams/puk](https://keybase.io/docs/teams/puk)

~~~
Gaelan
How does this interact with device compromise?

~~~
azag0
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."

~~~
maxtaco
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.

------
bachmeier
I've never heard of this company before. How do they make money if this is
free?

~~~
eganist
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.

~~~
bachmeier
> That's not the primary motivation right now.

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.

~~~
eganist
> That's a scary thought. Building this type of software takes a lot of money.

I'd argue that this is the point of raising investments prior to there being a
product which may generate revenue.

------
tanderson92
Interesting, good to see that they've thought this one out a bit (many other
unis too):

% 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)

------
Walkman
I didn't see that coming; Keybase want to be Slack 2 :D

------
brightball
Wondering why this is off the front page so quickly?

------
fiatjaf
Where and when do you get paid?

------
segeda
Any idea how make simple onboarding for public team? Something like
[https://github.com/rauchg/slackin](https://github.com/rauchg/slackin) for
Slack. Thanks

------
moontear
"Error this name has been reserved by keybase staff, contact chris@..."

Tried multiple generic names as well as some random companies. Might I ask
what you are basing your "blacklist" on?

------
breakingcups
Hmm, this prompted me to install the Keybase client on Windows, but the setup
exits after "Initializing..."

------
acobster
Keybase is a truly exceptional product and this feature especially solves a
big problem for my company. Thank you for all your work on this.

------
bruce_one
Unrelated, but any interest in making the Android app available via a non-
Play-Store medium?

~~~
Blaque
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.

------
metahost
This made my day !!

keybase chat list-channels equifax # spoiler: none found

------
adammenges
Awesome work, thanks guys!

------
skybrian
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.

~~~
eridius
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.

~~~
jsjohnst
If it looks like a duck, swims like a duck, and quacks like a duck, then it
probably is a duck.

(PS, keybase has public, try --public flag on keybase chat send)

~~~
eridius
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.

