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.
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
We really felt that only by solving all 3 problems would a general PKI ever take off.
> (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
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.
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.
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.
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.
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.
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
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)
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.
Can anyone comment on their 2fa approach to google?
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.
Paper in a fireproof safe is excellent for these sorts of things, or a safety deposit box.
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.
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?
This allows me to have more confidence in recovery, as well as adding more devices, etc.
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.
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.
Doesn’t this sound like a nightmare in terms of social engineering attacks?
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.
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].
Not to be pedantic, but is this normal in a major(?) publication?
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.
Note that they will need UI/UX experience more and more as time goes on, especially if Purism's Librem 5 is fully funded.
My company has been using it for a while.
> 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.