Keybase's mission is to make encryption mainstream | Hacker News Reader

Keybase's mission is to make encryption mainstream

observer.com

180 pointsBradyDale80 comments

A good article that covers what Keybase is, where they came from, what they try to do, and where they're trying to go -- although you couldn't tell from the headline. As in the article body, Slack is namedropped just for effect; Keybase Teams being a decent proof-of-concept of a popular kind of application to show that the ideas behind Keybase can be used to build real products.

That being said, Keybase has been moving more and more towards building these higher-level services on top of (and app-wise, deeply integrated into) their core offering: Chat, File locker, etc; presumably other than delivering value these offerings make the company easier to position in the grand graph of services, and more palatable for raising capital or as a future acquisition target.

When we started Keybase, it was a hobby project to address shortcomings of PGP. Max and I both had just downloaded software packages and wanted to verify them, and it took us hours. At least one of them was bitcoin; I recall staring in awe as Max showed me the countless Gavin Andresen impostors on the popular PGP key servers.

We really thought we'd stick up the Keybase directory, make some basic scripts, and move on.

Upon further review and growing popularity, we realized we'd hit a nerve but only solved one of 3 problems related to public key infrastructure.

(1) the identity problem; this means think of a PERSON, and end up with a key. This really is what started Keybase. It was made possible because of how identity has changed in recent years. Whether you're following a famous developer or you're looking up your own sibling, odds are in 2017 you know a public definition of them: a Twitter account, Reddit account, Facebook, etc.

When attacking point 1, we made it a lot more than just posting a fingerprint. We needed these proofs to be bidirectional. It's not just that you should be able to start with a Twitter account and get a key; you should be able to start with a signed statement and end up on the Twitter account. We also attacked revocation and other issues.

But really, there were 2 big missing pieces:

(2) multi-device key management; the OLD shitty story was having one private key that you moved around from device to device. This was never an acceptable solution for most people. What the heck is a private key? How do I move it around? What if just one of my devices is compromised? And so on.

In 2015 when we decided to commit to Keybase, smartphones were poised to solve this. They solved this by guaranteeing that whatever 2 devices you have, you can always bring them together. So you should never have to move a private key around again. In the mobile era, you can bring 2 devices together and declare they're both you. Technically, underneath the surface, device #2 generates its own key pair, and device 1 signs the new public key, and device 2 countersigns this, and all this goes into an immutable chain (by signing the hash of the last identity change).

This means you don't need to understand what a key pair even is. It feels roughly the same as when your bank tells you to grab your phone in order to log in.

And if you have a compromised device, your identity isn't destroyed.

This was the 2nd thing we wanted to tackle.

Finally, to address your point, number 3.

(3) all the GUIs around PKI really kind of sucked. There were some standalone chat apps that were good, but nothing that got people building a real graph of keys and identities, so they can do whatever else they wanted. For a PKI to work, people needed usable software on every platform. And it couldn't be constrained to people in your phone book, where you needed to securely exchange a phone number first.

We think the basics of a usable PKI are:

   (1) to know who you're talking to (and to trust teams)
   (2) to be able to share data, securely, on any platform

If Keybase offered that, whether or not it felt like a "Slack-killer," you could secure all the other aspects of your life. Everyone uses different crypto powered apps now: SSH, IPFS, Signal, bitcoin, ethereum, etc., and it's so annoying to get started. Keybase actually makes all of them easier, because you can think of a person and talk to them about it. Then you can move on to transferring that cryptocurrency, accepting that server fingerprint, establishing that OTR chat (and checking security codes without meeting in person), etc.

We really felt that only by solving all 3 problems would a general PKI ever take off.

I have nothing to add other than that I really like how KeyBase decided to do identity. Letting the user decide how much they trust different services and using them to verify is a fantastic solution.

Excellent summary of your vision.

> (1) (...) Whether you're following a famous developer or you're looking up your own sibling, odds are in 2017 you know a public definition of them: a Twitter account, Reddit account, Facebook, etc.

What do you think about OpenPGP Linked Identities proposal [0] that does exactly what you described but in a decentralized way?

[0]: https://tools.ietf.org/html/draft-vb-openpgp-linked-ids-01

It would be great to see it deployed, but it solves only (1), and even so, not completely. I couldn't find it in the doc, is there a story for revocations? Part of our concern about the PGP story is that malicious servers can suppress revocations. In Keybase's architecture, we've committed to an append-only data structure, which makes it impossible to withhold revocations without being detected. In a decentralized setting, you could do something similar with a blockchain like Bitcoin or Ethereum, but for usability, it would be important to do so without requiring mobile clients to download the entire blockchain. (BTW, that draft cites Keybase as a motivation for their approach :) )

> BTW, that draft cites Keybase as a motivation for their approach

Yes, I know. Without Keybase this draft would probably never exist in the first place :)

> I couldn't find it in the doc, is there a story for revocations?

Yes, it supports revocation as links are stored as User Attributes (similar to UIDs).

> In a decentralized setting, you could do something similar with a blockchain like Bitcoin or Ethereum, but for usability, it would be important to do so without requiring mobile clients to download the entire blockchain.

Yes, I've been thinking about using Blockchain for that purpose but I'm waiting for something more concrete to materialize out of Key Transparency [0]. As far as I like Keybase for something so fundamental as identity I think a distributed solution would eventually be necessary.

As far as I remember you write sigchain Merkle root to Bitcoin [1], that's a good security measure. (although you may consider using OP_RETURN outputs rather than fake output addresses, that optimizes unspent transactions database on each Bitcoin node).

[0]: https://github.com/google/keytransparency/

[1]: https://keybase.io/docs/server_security/merkle_root_in_bitco...

I see the client source is on github (yay!), but what about the server source? Is this service federated? If not, then this is yet another silo'd solution (with a proprietary backend) dependent upon a single company to maintain..

Why did you choose to tie identity to devices? That idea has always seemed fundamentally flawed to me, and if it wasn't for this flawed core idea, I would be a big fan of what you are doing.

I am not my cell phone, my laptop, or any other possession. I am a collection of memories and experiences, so it makes perfect sense for my identity to be tied to that--like a passphrase.

This isn't just a philosophical idea. I travel a lot and change cell phones all the time. My laptops break and get stolen. I lose things. But I (almost) always have my mind with me.

They also support paper keys, which you could think of as equivalent to your mind (i.e. memorize the key)

Honestly hoping to see email support, or an email sub-project that makes using encryption (existing mostly) in email easier. At work we have to use PKI or S/MIME from Microsoft, which only works on Outlook or on Apple's Mail client, why not on some open source client? Why can't I have easy email encryption in 2017 that anyone can use? Aside from just using Protonmail (centralized issues). Glad you guys are doing this project, hoping to buy more space whenever you guys decide to sell more disk space to users.

I have found Enigmail and Thunderbird to be easy and intuitive. Both are open source. Thunderbird is the email client and Enigmail is the plug-in.

If your work does not require you to use the proprietary exchange stuff in Outlook I would say that Thunderbird with Enigmail is a really convenient solution for encrypted and signed email. Once set up there is very little overhead involved, and if a recipient's email address is in your local gpg database Enigmail will happily encrypt content by default.

Kinda does require the proprietary solution. We do have in the office a paid for Thunderbird plugin (we use Ubuntu unless working on .NET) but for personal use (at home reading work mail) I am limited to using mail on my Macbook Air. Also explaining the process to someone else I know vs just telling them to install an all inclusive mail client that is more seamless would be a different story. Short of telling the whole world to sign up for ProtonMail I would love to see a client that handles email encryption cleanly.

Now try getting your compute newb friend/family going so they can sign, verify signatures, encrypt, decrypt, add keys, etc.

Now try web of trust, key servers, revoking certs.

Then the finer points of what to when you find tons of different keys for people with the same name.

Then subkeys, short term keys, and keeping long term keys offline.

See.. easy!

I wonder if, in the mid term future, you could see e2e encryption over slack and other offerings if you added slack as a team member—granted, they’d be storing the messages plain text on the slack side, but it’d ease and encourage transition onto keybase teams rather than eg SAML.

Sometimes, when Slack e-mails me that someone has mentioned me in a channel, and in the e-mail there is content of the message, I have a brief thought of "how do they know-... oh". I'm slowly getting used to e2e provided by various IMs, as well as encrypted at rest e-mail providers (personally I user Protonmail) - it's not something extraordinary anymore.

They don't really address the fact that every single Slack "leak" is from someone already part of the team taking screenshots of the conversation. How does any kind of encryption help that?

Also doesn't mention everything you lose out on with this approach - like searching through message history.

It's a neat product I guess, but mentioning Slack in every single line seems more to get eyeballs than a valid comparison.

> like searching through message history

You can do this[0]

I'm personally rooting for them - e2ee group chat is a common request I get

[0] https://people.eecs.berkeley.edu/~dawnsong/papers/se.pdf

What is e2ee; everyone to everyone else?

What does that mean, if so..

I'm guessing "end to end encrypted".

/r/iamanidiot

Search could be done locally if the client downloads the whole message history. I don't know enough about how Teams works to know if that's actually something a client can do right now, but it should at least be technically possible.

Another alternative is simply running a bot that indexes everything and provides search. You can run the bot in-house so you keep control over your data.

I think I'm more uncomfortable with the idea of entire message histories walking around on disks of laptops and phones (not to mention that's a giant problem on phones because of storage/horsepower) than I am with the idea of slack being able to read everything...

There are better ways to do search, hash keywords then you can just search the hashes

Well, the clients could just keep indexes rather than the actual history, and then fetch the specific messages as needed when the search is performed.

Why can't you just store the chat data locally and search it there? Chat data is already small enough, it just needs to be stored in a searchable format.

You don't need to store all of it either, just store the past month or so (or store what the user chooses to store). When the user needs data in the past, the user can download that data from the dates needed.

I have IRC logs with years worth of chat data and they only take up a few MBs.

If you can't trust all the members of the team, or the person you send the message to, then no amount of encryption will save you.

But this does remove (reduce?) the need to trust that the the 3rd party provider (eg. Slack) is capable of securing your data and is also protecting it from the prying eyes of those you don't choose to trust explicitly.

> Two veteran entrepreneurs are running a little startup built around making it easy to build web and mobile applications from day one that make data impossible for a digital trespasser to read. In fact, it encrypts data in such a way that even if you use some company’s service, that company can’t see what you’re doing with it.

Is it? Not that I'm questioning Keybase, I just had no idea they were offering some type of encryption-as-a-service thing. I thought key base offered encrypted identity management, along with some encryption focused tools (kbfs, and now chat). Of course, I don't know/use key base - hence why I'm asking.

Can anyone go into more detail on how key base is offering this service:

> In fact, it encrypts data in such a way that even if you use some company’s service, that company can’t see what you’re doing with it.

(Assuming "some company's service" is a 3rd party service)

Well, kbfs is end-to-end encrypted, versus something like Dropbox (for example), which is only encrypted in transit, and unencrypted at rest. And of course, you have to trust Dropbox when they say employees don't have access to your storage unless they have a good reason. But there's nothing you can do to prevent Dropbox employees (or a government, or someone that has unauthorized access) from deciding there's a good reason to access your data, because it's not encrypted end-to-end like kbfs [0].

[0] https://github.com/keybase/kbfs

I'm new with it myself, but I think part of what's being described is the option you have, when you have a Keybase account and the Keybase browser plugin and you're logged into a third party system (such as Fbook), of clicking on a Keybase icon for a given user and sending an e2e encrypted message from your Keybase account to theirs (even where they don't have one yet--if they make one later and associate it with their account on the third-party service, they will then unlock access to the message).

Ah hah, this seems to be the answer then. Thanks!

I like that idea of encoding before it hits FB/etc. Though, the level of security provided by a browser plugin makes me a bit nervous. Not an educated nervousness mind you.. I just tend to not trust them, and how well sandboxed they are, etc. It's the reason I also don't use browser plugins for password management.

Tangent, but the article mentions using Google Authenticator -- I was going to start using that recently, but the reviews indicated it had some really big problems with restoring when you get a new phone etc and Google isn't really maintaining it. https://itunes.apple.com/us/app/google-authenticator/id38849...

Can anyone comment on their 2fa approach to google?

On Android, I use FreeOTP; I can make backups with `adb`.

Separately, I use KeepassXC (https://keepassxc.org) and store all my 2fa seeds in a dedicated (separate) 2fa database which I keep locked. You can also keep it in the same database as your password db if you want to trade the 2nd factor for convenience but still get the added benefit of one time passwords.

> I can make backups with `adb`

does it follow that an attacker can make a "backup" of your 2fa codes as well, if they get ahold of your phone for a minute or two?

No, because you can (and should) disable usb connectivity/debugging.

Physical device access is where this kind of security ends. If someone stealing your phone just to get your 2fa codes is a threat vector for you, you should be using different/additional factors.

In any event, as was pointed out, adb needs usb debugging turned on, which needs the device unlocked to be enabled.

You need to authorize each adb key on the phone, so a screen lock prevents this.

I always (usually) get a copy of the string token when adding a "google" 2fa. I store this in a password manager.

This allows me to have more confidence in recovery, as well as adding more devices, etc.

I thought Google Authenticator was not recommended, and that Google was fully backing 'Duo'

Always save the keys (or the scanner code) whenever you add them to Authenticator. Then, when you get a new phone (or whatever) you can just re-import the keys.

It's pretty stupid that Google doesn't allow for any way of getting the keys out of it's 2FA app. Your only transition path is backup/restoring an entire device to a newer one of the same OS.

There's no direct path to migrate from say an iPhone to an Android based phone without manually adding each 2FA entry to the new device.

I think they do this to make it harder for an exploit to just run the command to get the keys. I'm torn whether I think this is really an issue or not though. From a security standpoint it is one less attack vector to get my 2nd factor keys. From a usability standpoint it is annoying when I switch devices. I personally solved this problem by storing my two factor auths on my yubikey neo which is a bit more portable. I don't think there is a way to get the keys off of there either but at least the key itself is portable and works with Android and all my desktops/laptops. I am not sure if they ever figured out iPhones though.

I agree this is SHOCKINGLY not consumer ready. Considering all the shaming I see every hack about 2fa I expected it to be pretty streamlined.

> Your only transition path is backup/restoring an entire device to a newer one of the same OS.

This isn't an option on iOS! When I bought an iPhone a year and a half ago, the 2FA keys were not included in my iTunes device backup, even through backup encryption was turned on. I had to manually create new keys for all seven sites I use Google Authenticator with.

They're definitely included as I've done it a number of times. I'm going to wager you don't have your iTunes set up to backup apps from your phone. I think there's a separate check box you have to click once to enable it.

The secrets are in the keychain, which is backed up.

Google Authenticator used to store its secrets in the devices keychain as available "while unlocked". This allows them to be stored in the backup in a way that can be transferred to a new device - if you use an encrypted backup. It also makes it possible to extract the keys if you know the backup password. (I have code that does this, inspired by the old "iphone-dataprotection" codebase on google code.)

Google Authenticator now (last I checked) marks its keychain entries as "This device only" - this still allows backup/restore, but only to the same device. They are wrapped by a key only available on that specific device (the 0x835 key - you used to be able to extract it on a jailbroken device, but I'm not sure that's possible anymore).

It's possible you have grandfathered entries or even an old version of Authenticator. But I no longer see entries for "CLNPY5GLN9.com.google.Authenticator" in my decrypted keychain, so it must have migrated my old entries. Before my phone dies, I need to go through all of mine and make sure I've got a backup or regenerate the ones I'm missing. (I have old snapshots of decrypted keychains.)

If you have a rooted phone, there is another option: copying off the sqlite database. At that point you can generate QR codes with a tool like WinAuth. Bit of a pain, but very doable (if you rooted your phone.)

Bypassing this with Authy is generally a better idea.

As an additional note: I strongly recommend storing these keys securely offline. With these keys someone can replicate your 2FA generator, so you really want it not hackable.

Paper in a fireproof safe is excellent for these sorts of things, or a safety deposit box.

I just changed phones and found this really simple. You can just store a phone number with Google and receive an SMS key if you forgot to print off a key before changing phones.

Everything seems to be working pretty well for me and I noticed improvements since last using the app 1+ years ago, but obviously can't guarantee it's still being updated.

That might work with Google itself but TOTP based 2FA codes aren't specific to Google. They can be used out of band by anyone and the SMS approach wouldn't apply to anybody else.

Ahh yes - excellent point.

Google Authenticator is really just TOTP. My preferred approach is to use 1Password, which handles TOTP codes just fine.

Authenticator Plus. It's a paid product, but allows me to sync my TOTP tokens to my Google drive account, so I'll never have that problem again.

I personally use Authy, and it's survived several migrations to new phones.

Additionally to the other suggestion I can recommend using a Yubikey with NFC together with the Yubico Authenticator. You can easily move between devices.

Nice work team. I've been on Keybase for a while but I've only recently installed and started using Teams on iPhone and Mac and both the apps are very polished and easy to use. Definitely a lot easier than posting up my key and waiting for someone to email me encrypted text ;)!

I think the strategy of decentralising the data is a good one for enterprise apps like this, where there's typically little value from the perspective of the business user, employee user, or service provider from holding the data. Lots of data is great for driving personalisation and other features in a million+ person network but not really in cases like this one.

Hopefully this is a pattern that will keep working its way into enterprise apps.

> In order to give everyone confidence that the people shown in the Keybase are who they say they are, Keybase encourages users to attest to their identity cryptographically on social media. Keybase is its own social network, but it’s not one for sharing pictures of food or sad status updates. It’s a place for Mary to say “This really is Bill” and for Bill to say “this really is Mary.” With enough attestations like that, it becomes really hard for people to pose as someone they are not.

Doesn’t this sound like a nightmare in terms of social engineering attacks?

If your social account (twitter/..) gets taken over, you'll have to publish a new proof on it, which will then need to be attested by multiple people, before it becomes trustworthy anywhere.

Right. Plus your KB identity will still have all of your other online identities vouching for it. So an attacker would need to commandeer a large fraction of your accounts in order to get people to trust the fraud.

The quote from the article is the writer jumping through some creative contortion to try to explain keybase prove [1] feature to a layperson.

The idea is to prove control of some social identity; then correspondingly, others on Keybase will have increasing confidence that the person in question who has proven a few third-party accounts is indeed the same person. This doesn't mean that that person is actually-actually George Washington (which is a much more difficult problem to solve), just that the person who purports to be George Washington on Keybase does indeed control some accounts on Facebook, Twitter, etc, so if you would have vested some trust into their Facebook identity, you can vest at least equivalent trust into their corresponding Keybase identity.

[1] https://keybase.io/docs/command_line

How does keybase make money? I am afraid they are in the business of selling my online identity.

> How does keybase make money? I am afraid they are in the business of selling my online identity.

This comes up semi-regularly. Within the recent announcement of Teams [1] it was noted that:

"Put most simply, we eventually want to find a way for actual enterprises to pay, while keeping personal and community use free. And any use now is grandfathered in."

I've seen similar sentiments in earlier announcements.

They also have a clear privacy policy [2].

[1] https://keybase.io/blog/introducing-keybase-teams

[2] https://keybase.io/docs/privacypolicy

Thank you very much for your answer! I'm wondering how key base can find an investor with such a weak hope. Anyways, the privacy policy gave me the answer: everybody can can check my online identities, it is public and not deletable. Or, if the block chain is encrypted, they can sell it in a merger. Too bad!

> It’s mission: to make encryption mainstream.

Not to be pedantic, but is this normal in a major(?) publication?

From what I've seen of writers, they're barely literate before an editing pass.

Was the title on this story changed mods? If so, it'd be cool if there was some sort of annotation for when that's done.

I don't really get it. I have a Keybase account. It's attested on my social media accounts (including on HN). It includes a private key on my personal laptop and one on my phone. I haven't extended it to my work laptop because I don't want my company IT having access to a key that I've gone and told all my friends they can trust. So I'm confused about how this is supposed to work.

This is going to sound like a dumb question, but.... how much would encryption help? Even if we encrypted all of our data at rest and on the wire, I feel like a lot of security vulnerabilities wouldn't have been prevented with encryption. If you have any way of interacting with the application or the database, it's basically game over, no? Is there any data on this?

I’m not sure what threat model you’re proposing. If an attacker has control of your computer or the keybase app, then yes, it’s game over. But encryption removes the hosting entity as what would otherwise be a single point of failure. If you hack keybase the organization, you don’t immediately get access to everyone’s everything (in contrast with Equifax). An attacker would need to infiltrate the codebase and then release a malicious version to everyone that makes their apps decrypt/reroute/whatever the data.

I suppose I'd like to see what threat models actually apply to companies, and what vectors are most often used to get pwned (outside of social engineering). I understand what encryption prevents, but I don't understand how helpful it is in practice.

I've come to the belief that crypto and security are a 'feature' and never a product.

As important as these issues are - I find that businesses and consumers don't often opt for these things as a primary choice except in specific circumstances, or for specific consumers with specific needs.

The fact is - I think - most people don't care. Even most startups don't care that much. If their conversations are 'reasonably secure' then they're good with it.

I think HN readers are way to one side on this issue - we care a lot about it. I think our views are different from that of most people.

This could change but I think we're still in this mode.

If there's anyone working on an Open Source Slack (or Keybase) alternative, hit me up. I run a UI design agency and we'd love to help design a better interface for an open solution that we and others can use. Find my details in my profile, or go to http://fairpixels.pro

There's a few. One's Mattermost: https://about.mattermost.com

My company has been using it for a while.

We'd love to contribute (with design). Are you aware of anyone interested in collaborating. We're looking for something that we can use ourselves and thus contribute to crafting a better experience around the software.

Definitely, rocket.chat. It's a proper opensource company and their mobile app could use a lot of love.

Hi @fairpx, Mattermost team here, we'd love to have your help!

Here's a page to learn about all the ways the community can contribute: https://about.mattermost.com/contribute/

I think I heard that the matrix people are looking for ux/ui people to improve Riot. https://matrix.org

Do note that matrix.org is the homepage for Matrix, which is more about the protocol itself. https://riot.im is probably more relevant for design / UI / UX work.

Note that they will need UI/UX experience more and more as time goes on, especially if Purism's Librem 5 is fully funded.

yup, we are! if you’re interested in helping us (we’re the decentralised e2e encrypted open option) then would love to talk: i’m matthew at matrix.org.

Ok, I'll bite. Is this actually a thing??

> You texted that dude about the weird thing you like to do with silicone ice trays and that admission will remain in the bowels of the Match Group forever.

Reply on news.ycombinator.com