I feel like keybase is great as a key-management platform and _that's it_. I found it to be a fairly pain-free way to manage a pgp key, and the ability to associate it with a public social media identity is super cool. I don't really get why all the other features are needed, and if there's a better platform to do key management easily across devices I'll jump ship in a heartbeat.
It's pretty good for end-to-end encrypted chat and file sharing. I've used Telegram, Signal and Wire in the past, but I've found Keybase to be the best for my needs.
The cryptocurrency wallet feature is not useful for me, but it hasn't really impact me in any negative way, so I don't mind it.
It’s only useless if you don’t know what perfect forward secrecy is and would rather complain than look it up. Yes, this feature is provided by Telegram and Signal (probably WhatsApp too). It makes it so someone who compromises your key can’t read all past messages. It’s pretty important. Future secrecy (key compromise doesn’t grant access to all future messages) is also important. Keybase only has forward secrecy for its exploding messages.
These are why I’d never use Keybase to chat even though it’s better than Signal from a usability perspective.
If an attacker obtained the ciphertext of the message, they are under no obligation to delete it just because it "exploded" on your device. They can hold onto it as long as they want, then if they ever get your key, they can decrypt it.
So, firstly the comment you're replying to specifically says that Keybase _does_ use PFS for exploding messages. I'm going to assume in good faith that you've simply misread the comment but I'll circle back on this because the technical details are interesting.
1. For _other_ Keybase messages without PFS it's open season. Say Alice sends you a normal Keybase message right now about murdering her husband Bob. Keybase will ensure Alice provides keys to decrypt that message for your iPad, iPhone, the MBP and your old Thinkpad. This way you can read the message from any of your devices. Convenient.
Spooks can record Alice's encrypted message and get it back if they at /any/ subsequent point obtain the Keybase device key for your iPad, iPhone, MBP or Thinkpad, for example as a result of seizing it for some other reason. Maybe it's next week, or next month, or next year, or in ten years time. The device may never have received these messages, maybe it was switched off, or they've since been removed. Doesn't matter until the key is replaced.
In contrast a PFS system would discard the keys as soon as they'd been used to decrypt stuff, and agree new keys for subsequent messages. Signal's double ratchet does this for every single message back and forth. "I killed Bob" (new key) "You did what?" (new key) "I was so angry I just stabbed him" (new key) "Shit. Now what?" (new key) and so on.
2. Actually though "exploding" messages are another Keybase compromise. Visually it seems like they blow up instantly when the time limit expires right? Gone. But cryptographically it takes up to a month or so for the bomb to "explode". Suddenly it's more like you wrote the message in chalk on an outside wall rather than it instantly "exploding". This was easier for their multi-device large group stuff. That's right, your 1 hour exploding message about the lawsuit was optimised for cases where you'd need to share it with a 500 person group who all have multiple devices. That makes sense right?
Always with "exploding" messages the actual expiry is implemented by some software explicitly deciding to throw ephemeral data away. Signal's ratchet makes doing so constantly the unavoidably the correct software engineering choice, otherwise your code leaks endless old keys because of the ratchet. But Keybase only throws away "ephemeral" keys after at least a week, chances are if you're a multi-device user there are some fortnight old "ephemeral" keys in one of your systems right now. A Keybase exploding message you got on the 1st of December with a one hour "fuse" on it is still actually readable now using keys from that device. Huh. The Keybase UI doesn't make that apparent at all.
Actually his comment is quite useful and tells you enough to know notnto use it if security is actually a concern. Without PFS (Perfect forward-secrecy) someone who obtains a key or brutes/reverses one has theoretically unlimited time to do so and gain access to all future communications with that key because the key isn't Ephemeral.
Compared to WhatsApp and Signal that's bad, they both use a well-thought out security model.
As for Telegram, well, Telegram is Telegram.
It's up to the reader to decide what "theoretically unlimited time" means in this case with regards the adversary.
> I feel like keybase is great as a key-management platform and _that's it_.
I agree, although I'll freely admit I haven't tried to use the other features all that much.
However, I do find myself a little uneasy with the key management aspects too. The official keybase CLI package being ~500mb when installed, the background server, etc concerns me. The alternative of using curl with a heap of largely inscrutable commands seems unworkable¹.
I wonder if anyone has worked on an alternative, and easy to inspect, client to interact with keybase for just the key management aspects?
1. I largely used the curl method, but suspect very few others would.
I don’t enjoy the key management part of Keybase and don’t find it particularly strong, but why do you think the curl method is inscrutable? The entire payload (basically a JSON blob plus a signature) is there for you to see instead of a binary client that could do god knows what (even if you have the source code it’s probably harder and at least slower to understand than the final payload sent over the wire). I would say the curl method is actually the most inspectable one.
Inscrutable may have been a little strong, but just having a re-test here shows me a nine argument curl call in some paths. I'm not saying you can't inspect it, but there is a lot going on there.
I think we're in agreement that a huge binary client is worse, but I'm suggesting there may be a middle ground with a small/simple open source client just for the key management aspect. That said, it does of course rely on people actually looking at the source of such a client ;)
The parameters are mostly server states. What’s interesting to you should be “what am I signing” (since that’s the only part they didn’t provide you in the first place) and it’s a JSON blob that’s fairly understandable.
A small client is still going to send the same payload.
I signed up for Keybase during the alpha because I liked the idea of PGP-verified identities on different web properties (and I still do). However I uninstalled their client when it was “upgraded” to a Mac app complete with a kext for a goddamn FUSE mounted at all times (that and the fact that the client was somehow spamming my DNS server). But at least the chat service makes sense for part of their user base. Then came the crypto nonsense....
I guess being a free keyserver and identity verification service (they frequently check all your signed messages across all linked web properties) just isn’t a viable business model.
Lots of services are great key management. What I'm waiting for is encrypted (or at least signed) email between myself and literally any company on the internet communicating by email.
"can you just email me a copy of your passport photo and these 5 other things i need to completely verify your identity to banks and so on"
errrr .... no ?
Individuals are arguably not fussed. But surely business can get behind some better levels of encryption / verification ?
I wouldn't bother waiting. Just use a web site to transfer anything important and give up email for this purpose.
A hard problem with email is that there is a boundary inside the address itself. How can anyone know this is steve@example.com? Maybe an outside authority can verify it's really @example.com but if I thought this was Steve and it's actually Tammy then I'm unhappy anyway.
For your purpose you probably don't think you care. You don't know whether custserv@example.com or customer@example.com or jenny.smith@example.com is the right email address to be telling you that your complaint is being confidentially processed anyway. But what about steve-the-plumber@gmail.com ? Does it matter if this is really from Steve or the mail actually came from tialaramex@gmail.com ?
Because the web doesn't have this authority boundary the Web PKI can actually assure you of a meaningful fact to a worthwhile degree. This is really https://example.com/. Is example.com really your local plumber Steve? Are they legally authorised to repair your gas appliance? Are they crooks? We can't answer those things. But we can tell you this is definitely example.com
I found it convenient for syncing private git repos between machines. But now that gihub allows private repos for free, maybe that's not so useful anymore?
