Introducing Keybase Teams(keybase.io)
keybase.io
Introducing Keybase Teams
https://keybase.io/blog/introducing-keybase-teams
115 comments
@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.
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.
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?
DNS could always be used only for the initial name registration. After that, ownership would be managed within Keybase.
Are you worried someone will dictionary-attack this feature and just claim all of the good names?
Please work on building some kind of safeguard against typosquatting and other similar angles.
The one thing that worries me with this sort of thing is the "oops, I typo'd" something factor.
The one thing that worries me with this sort of thing is the "oops, I typo'd" something factor.
When will you add file support to the mobile clients? We're absolutely dying for it over here!
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.
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.
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.
Fantastic, thanks!
Is it possible to encrypt with teams? eg `keybase encrypt -m "my message" {{insert team name here}}`
It's not yet, but this is on our short list!
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.
I'm sure you're thinking of this - but integration with the iOS 11 Files app would be awesome!
+1 -- I would really like files to be working at all, but integration with iOS11 files feature would be amazing (also would love to see iPad working)
If you delete a team, can a new one be created with the same name?
Edit: Additionally, are team names private? Can they be discovered without guessing them? If you guess one, can you prove it exists?
Edit: Additionally, are team names private? Can they be discovered without guessing them? If you guess one, can you prove it exists?
nope! We feel pretty strongly this is the right answer.
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.
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.
Same goes for sub-team name? I.e. don't put private project names, future release date related things etc in there?
"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."
(from https://keybase.io/docs/teams/design)
(from https://keybase.io/docs/teams/design)
OT, but any update on exploding messages in Keybase chat? (or did I miss it?)
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.
(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.
> it's what you might want in certain sensitive situations or certain DM's
+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.
+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.
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.
I would happily pay for kbfs alone and I would hate to see them go under because they run out of money.
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.
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.
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.
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.
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 [email protected] 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.
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.
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)?
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 :)
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 :)
And how will you deal with squatting? I am looking forward to holding all the popular names hostage.
Seems like they limit the number of teams you can create [per user] to 101. I guess it's the same dilemma as with domain names again.
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.
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.
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.
What if neither Alice nor Bob have a domain name? What happens if the domain name is dropped, transferred to a third party, suffers a dispute etc?
Keybase could just offer free subdomains from a domain owned by Keybase for people who don't have their own domains.
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:
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`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/
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?
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?
Your idea is really good.
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?
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.
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.
[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 never looked at facebook network activity.
But I'm wondering if they are not actually logging your keystrokes (or google analytics).
Otherwise, AnyCrypt looks awesome.
But I'm wondering if they are not actually logging your keystrokes (or google analytics).
Otherwise, AnyCrypt looks awesome.
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?
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?
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/
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
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!
Sorry to be such a pest but I've spent probably too much time banging my head against this problem. Thanks!
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
Probably related to this bug: https://github.com/facebook/draft-js/issues/1077
Are you serious? Seriously? REALLY?
I don't believe this comment.
I don't believe this comment.
> 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 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?
Closed source? https://github.com/keybase
Which repo contains the server part and the JS frontend?
The client is in this one:
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.
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.
I understand the trust model but it still does not qualify as "open source" if the source is not available.
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.
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.
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.
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.
How? Domain name squatters do exist. And domain names can change ownership.
It does create the possibility of leaking strategic project information unless names are intentionally obscured.
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?
Very cool. Regarding team naming, is there anything preventing one from registering "google" or "google.com" as a team name?
In another post the blog author mentioned that he reserved team names for a bunch of well-known tech companies.
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!
Ok but my company is not on that list. The question stands.
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.
> 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.
More info here: https://keybase.io/docs/teams/puk
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
How does this interact with device compromise?
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`
Looks like you also got a PUK, but after a delay. Signature here: https://keybase.io/tanderson/sigchain#9b066b9a96f8d041cf7b55...
Yep, thanks!
I've never heard of this company before. How do they make money if this is free?
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.
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 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.
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.
> 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.
I'd argue that this is the point of raising investments prior to there being a product which may generate revenue.
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.
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)
% 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)
I didn't see that coming; Keybase want to be Slack 2 :D
Where and when do you get paid?
Wondering why this is off the front page so quickly?
Any idea how make simple onboarding for public team?
Something like https://github.com/rauchg/slackin for Slack.
Thanks
"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?
Tried multiple generic names as well as some random companies. Might I ask what you are basing your "blacklist" on?
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.
Hmm, this prompted me to install the Keybase client on Windows, but the setup exits after "Initializing..."
Unrelated, but any interest in making the Android app available via a non-Play-Store medium?
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 made my day !!
keybase chat list-channels equifax # spoiler: none found
keybase chat list-channels equifax # spoiler: none found
Awesome work, thanks guys!
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.
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.
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)
(PS, keybase has public, try --public flag on keybase chat send)
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.
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.
If you squint, a "team" looks a bit like a friends list. Couldn't everyone create their own?
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.
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.
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!