This comment may be of interest (we could release server code at some point, and I will take this as a vote), but I hope people reading this aren't distracted by Signal's flaw here.
[edit: chilled a bit!]
...
I get why you showed up here, but you're really not addressing the point of the post at all, and in fact you're trying to distract with the suggestion that Signal's publication of that code protects people from this flaw. It doesn't. At all.
Wow, that's a pretty hostile (and accusatory) response to a fair ask. This is one (small) step removed from accusing someone of shilling/astroturfing.
Let your product stand on its own merits. If you have a good reason why you won't open source Keybase's server implementation, own it. Don't undermine requests to open source the code by publicly accusing people of supporting a competing product.
The person you're replying to didn't make an argument in favor of Signal - or any other competing product, for that matter. In my opinion, your response is actively distracting from their request.
I think it's worth meditating on the tradeoffs of your system design. Nothing is perfect.
Signal is trying to do the best that it can, and I really think that the starting line in writing secure software is open sourcing the whole thing from top to bottom. Anything less isn't auditable.
Note: I edited this post to make the language more addressable. I love the work Keybase is doing, but I want them to open source their server.
Your comment would be much better without any allusions to this person's affiliation. Just answer the question directly without casting aspersions. You seem confident in your answer, so that shouldn't be hard.
I mean other than coquettishly dropping a tantalizing hint by saying 'yet?'. That's nice, but insufficient.
That's a very useful property, because even if the server is open source, that doesn't guarantee that what the Keybase team is actually running in production matches the source they've released.
So I would say a system where the clients don't (and don't need to) trust the server, even if no server source is publicly available, is still strictly better from a security standpoint than a system where the clients do need to trust the server, and source is available. (Assuming, of course, that the design of the system as a whole is sound, and that clients have been audited to ensure that they follow the design of the system correctly.)
It is better to not even have to think about looking at the server-side code.
The best case would be there is no “server” at all, but that’s the Internet we have to work with today to enable the usability and user experience they are going for.
Keybase looks really really cool, and I would love to use it, but I can't in good conscience recommend something that is cagey about the half-open nature of their product, especially when the server. It is by definition "man-in-the-middle"-ing all your data, and if you can't inspect it you can't reasonably trust it.
That is the point the article is making, and that's what it sounds like the Keybase client is doing--not trusting the server by relying on client-side encryption rather than storing keys on the server.
The fact that you can change keys and see old messages without the other party sending them to you using your new key points to serious problems with these other apps. It seems the Keybase client rightly considers the channel insecure.
With those apps, you throw away the crypto and just start trusting the server: (1) whenever you switch to a new phone; (2) whenever any partner switches to a new phone; (3) when you factory-reset a phone; (4) when any partner factory-resets a phone, (5) whenever you uninstall and reinstall the app, or (6) when any partner uninstalls and reinstalls. If you have just dozens of contacts, resets will affect you every few days."
I guess I don't have "dozens of contacts", but getting a new phone/resetting a phone isn't really that common of a thing in my circle. I feel like for the average user, they wouldn't do this with their phone more than like once every year or two. So I guess if you have like 600 people you talk to on these apps regularly then that works out to daily, but for me at least this isn't that big of a deal and was pretty much understood from the outset.
""" There's a very effective attack here. Let's say Eve wants to break into Alice and Bob's existing conversation, and can get in the middle between them. Alice and Bob have been in contact for years, having long ago TOFU'ed.
Eve simply makes it look to Alice that Bob bought a new phone:
Bob (Eve): Hey Hey
Alice: Yo Bob! Looks like you got new safety numbers.
Bob (Eve): Yeah, I got the iPhone XS, nice phone, I'm really happy with it. Let's exchange safety numbers at RWC 2020. Hey - do you have Caroline's current address? Gonna surprise her while I'm in SF.
Alice: Bad call, Android 4 life! Yeah 555 Cozy Street.
So to call most E2E chat systems TOFU is far too generous. It's more like TADA — Trust After Device Additions.1 This is a real, not articifical, problem, as it it creates an opportunity for malicious introductions into pre-existing conversation. Unlike real TOFU...by the time someone is interested in your TOFU conversation, they can't break in. With TADA, they can. """
The quote you linked is relevant because it means that you can't simply ignore this problem; resets are fairly common, common enough that you can't just delete the key-loser's account (for example). However it doesn't have anything to do with the actual security flaw (if we want to call it that, it's really more of a UX / messaging problem) being discussed.
Now this is an anonymous contact. There is no way that we will authenticate in meatspace. So I said "sorry", and pointed out that they should have shared a public GnuPG key with me before triggering a reset.
Indeed. Or, "TA-DAA"! (trust after device addition/alteration, again)
I'm not comfortable with this "secure" device held key.
Maybe a private key that's pass-phrase derived could anchor the trust? So that the device key just becomes a trusted sub key/cert? With maybe a 30 day validity before renewal. (renewal ux being: please enter your pass phrase to insure continued integrity...)?
But even if you do that well, you still have a MITM attack at registration time. The surface area is very small here, but a state or even corporate backed individual could certainly afford to perform such an attack. If there is no specific target, hacking an Apple store or a Best Buy to spoof all registration traffic and substitute your own would probably catch a lot of fish in your net.
> You must now reestablish identity, and in almost all cases, this means meeting in person and comparing "safety numbers" with every last one of your contacts
Perhaps the alert could be a little more alerty and in red and read something along the lines of "Hey! Your buddy's safety code has changed, make sure they sound normal and aren't acting weird and creepy asking for information"
What income bracket is your circle? Just going to reminisce a bit here...
I come from a family business that used a lot of manual labor from the local neighborhood here in south Queens, NYC. I spent a lot of time with guys in late teens and 20's, mainly black and hispanic kids looking to make some decent side money. They came from low income backgrounds and were poorly educated. This leads to a very unstable life where money really is scarce.
They frequently changed phone numbers due to: "crazy" ex, owes money to scary people, owes child/alimony support, owes the government, commits crimes and uses frequent burners, did jail time, or the #1 reason; out of minutes and no money to put on the prepaid plan. They used prepaid plans as they could refill accounts using cash at physical phone stores or check cashing stores because they don't have a computer or bank account. No phone service means no internet. Most of those guys were good people who I got along with just fine. Ignorance really is a terrible thing.
High enough that they can afford an iPhone but low enough that they treat it like a treasure they don't want to have to replace unless they've had it at least five years.
I'm surprised at your suggestion that lower income people would be more likely to go through phones. I could definitely understand this for cheap flip phones on a pre-paid plan, but it was my understanding that Signal and WhatsApp are smartphone-only apps, so I figured lower income people especially wouldn't be flying through phones that cost hundreds of dollars.
It's not to common with me, and I just notify my contacts know I'm about to do it under my old key before I switch, so they know a warning is coming. Then I just reverify next time we meet.
I'd probably be more diligent if I actually had something to hide, but I don't, so I'm not.
I have about 15 people on signal an I've seen a reset once or twice maybe in total.
If a new device has shown up, your messages will be blocked from being sent until you verify the new device. To be fair, it is too easy to blaze past the warning -- and it can happen often in large rooms. As a result, it's a little bit cumbersome at the moment, but with device cross-signing coming down the pipe and the new verification system (which is much better than Signal's IMHO -- you just check both devices have the same string of 7 emoji on their screen) it's getting a lot better.
And the problem with SSH that was pointed out in the article is funny now because of cloud services where servers are constantly being destroyed, so keys are changing frequently, unless you save and persist that private key for the server in your configuration. Which I’ve realized a lot of companies are simply not doing, which leads to people straight up ignoring key verifications in their ssh config.
At AWS this meant we had to hop to a different gateway for each region, and then onto the (stateless) production host which was recreated from scratch on every deployment... There's no way a human was going to keep all those keys straight, and everyone just disabled SSH host verification.
Isn't keybase just doing something similar to subkeys for devices?
Keep the master safe, if you need to revoke a subkey, no big deal.
With cross-signing, this will get even easier because cross-signed devices will be automatically trusted.
I started testing "Matrix" using the "Riot" app on Android and the web-frontend ~4 weeks ago and so far things look good, which I think is fantastic!!!
I was especially happy to see that I could not read messages posted prior to me entering any encrypted chatrooms => gave me a real "good general feeling".
The "Riot"-app for Android (using it on SailfishOS) is so far quite intuitive and it did never crash so far. Battery consumption is relatively heavy (I used to charge my phone once per week, now it's once every ~3-4 days) but I guess that other users that have more frequently an active Internet connection (because of other apps) will be impacted less.
All in all I'm beginning to think to try to push it to my friends - I think that the first attempt might be to use an encrypted group chat for special themes (e.g. discussions about algorithms, stock market discussions, etc..., all what we do not dare to post in Whatsapp) to have a technical advantage vs. Whasapp & Co. .
It also solves a problem that Keybase has which is that all new devices are automatically trusted (so a compromised device can just register more devices to avoid being blocked). To be fair, this makes for a pretty bad UX -- and the Matrix folks are working on cross-signing to make this easier -- but it is very useful for a user to be able to detect new devices to be detected (especially their own).
because then you just end up with less people on the system, so you'll talk to them over unsafe channels.
keybase's opinion is definitely my opinion so im a little biased there, but so far i can't think of anything that's better than making the reset occurs as rarely as possible by using multiple devices for recovery.
Unless your willing to open a bug and be a pest for 2 weeks (and still have access to your old phone/leave it registered) I wouldn't plan on retaining your messages or keys across phones. Its a huge weak point of Signal.
Last time my phone died, I lost all of my Signal group memberships, because the app is incapable of transfering those to a new phone without backup... and it's also incapable of doing the backup automatically. Those UX choices continiously baffle me - it's like authors didn't learn anything from the failure of PGP.
Even if the backup works, the process is rather tricky. You have to get the backup file into a specific directory on the new phone BEFORE you open signal. There's no "import from backup option". If you mess up, you have to uninstall, then do the file copy.
There are issues like this going back years.
But it is a bit silly that you need to manually move the file from the old phone/backup location to the new one without some in-app option to do so.
In the interest of transparency I also use Keybase for things as well. The problem I ran into with Keybase my first go-round was I lost any ability to restore my account after I hadn't used it for about 9 months. That is mostly my fault for not having more bases covered, but had I had anything notable I would have wanted access to I would have lost it at that point. As an end user I don't feel that Keybase competes in the same manner as Signal. Since I'm an Android user Signal is 100% transparent to my normal use handling both SMS/MMS and Signal messaging. Keybase isn't a drop in replacement with that in mind. I realize this isn't the norm for iPhone users. Regardless, my question is: are many people using Keybase for messaging? About half my contact list uses Signal, yet I only have ever communicated with two people via Keybase.
For transferring backups from one phone to the other, I used Xender. Probably best to just transfer with an sd card, though.
It would be nice if this could be done on smartphone clients, but that pretty much requires leveraging some sort of "trusted key store" external to the app. (Which I'll admit may exist on some platforms, to varying levels of trust. How feasible and acceptable it is for this use case, I honestly do not know.)
on Windows: File, Preferences, Contacts - Import all signal groups and contacts from your mobile device. ... ... It is unclear what else gets imported.
For the rest of us, it seems that doing it on occasion is still worth it. As I understand, Signal is designed to never indicate over the wire who has checked safety numbers. Thus, a MITM anywhere on the network creates a risk of becoming discovered, which is a cost in itself.
I use signal to chat with my wife. I'm glad it offers good enough protection that my country's secret service is whining endlessly that it can't get in. I'm glad our inappropriate jokes don't easily become public.
At the same time, I'm sure that a determined and competent adversary could compromise my phone without needing to break signal's encryption or engineer fairly sophisticated mitm attacks.
I'm fine with that level of security, and don't want a more annoying UI when a device is reset. Because even with the current setup, the chat protocol isn't the weakest link anymore.
Somehow, nearly every article on the subject completely misses this, and instead keeps moving goalposts on reasonable endpoint security.
And I think it's not so binary as care/don't-care about being hacked. You might care a bit, but how much do you care? Just as important, what is your threat model?
Speaking from my experience getting journalists and political campaigns set up with signal in 2017-2018, the early scary key change warnings were off-putting to people and made them reluctant to continue with the messenger. At the time, I was in contact with 100-150 people via signal and quickly ran out of patience with anyone who insisted on a safety number check. But the UI at the time encouraged that level of paranoia.
I continue to believe that making key changes as painless as possible for users is the correct approach as long as there are ways to harden this behavior in the settings, for the benefit of the far smaller set of people to whom MITM attacks are a credible threat.
I'm OK with the compromise that Signal has made with key management -- there are people that I really care to have private communication with, and people who I prefer to have private communication with. I verify the former, and don't bother with the latter unless we happen to be bored together in the same room.
On a side note, thanks for your efforts over the last two years!
Thanks very much for the kind words!
But it's not all or nothing. Signal could do better at improving their UX to reduce the number of key changes people make in practice. If they did, they could probably make the prompt slightly more scary (but not Keybase-level scary) – but even if they didn't change the prompt, the mere fact that users wouldn't see it as frequently means they'd be more likely to pay attention when they did.
In particular, according on other posts in this thread, the backup/restore mechanism that allows transferring a key between devices currently has poor UX, only works on Android, is buggy. Obviously that should be fixed. Once that's done, they should make the app actively prompt you to transfer the key as part of the setup process, using a QR code scanned from either the previous phone or a linked computer. You would still have the option not to do so, and some users would inevitably choose that option (if only out of laziness), but if transferring the key is seamless enough, a decent fraction of users would do it.
But isn't Keybase's solution precisely about ensuring that this doesn't happen? If you change your phone's SIM card, the phone still remembers its secret key.
The same should be applicable to browsers, I think. When logged into your bank, you should be able to click a button that says "Make this website use paranoid security" or similar, which would apply very strict policies that prevent most HTTPS attacks, and maybe even enable protection against phishing and similar domains, or something.
I don't know why apps keep painting users into a corner with one generic option rather then giving them more choices.
edit: If I don't get an autofill option from LastPass, I'm incredibly skeptical if it is the right site.
Widespread adoption of MitM-capable encrypted messaging active collection and targeted surveillance.
If they forget their password, they can re-upload it from a validated device with a new master password.
Requiring existing devices to be actively involved in provisioning a new device prevents all of this.
And if it's not a 2FA device, the victim can use 2FA to push a disavowal of the old keys and set up new keys. That's an ugly and server-centric solution, but "halp I got hacked" is going to be an ugly case no matter what.
All security is compromise though. And I think Apple has done something amazing with what is provided given their install base.
Would be cool to see what the numbers are for reverifications.
One time i got a postcard from a friend with their safety number on it and nothing else. I recognized their handwriting to complete the loop.
The following questions are not intended as attempts to poke a hole on the requirement for out of band verification. Do you meet in person and speak in whispers or show some code that's hidden from the view of others (and cameras)? Or do you use a voice call or SMS (both expressly designed to support surveillance)? Or do you use another end to end encrypted app or email (if yes, how do you verify the keys for that)?
I love Keybase for this aspect, but something I don't like about it is its device name handling. They don't allow decommissioning old device names, so I end up having 'MyLaptop' 'MyLaptop 1' 'MyLaptop 2'...
The goal is a 1-1 mapping between devices (keys) and these names. So whenever we need our UX to talk about a key, it can talk, safely, about it in terms of device names. Once committed to your chain of signatures, "Laptop-Warhol" means a specific device key, and it can't be used again. So, for example, if one of your Keybase installs wants to tell you "oh, Laptop-Warhol just added a new device, iPhone-Vangogh" then it doesn't need to look like this: "Key 34858234589234895897234598734 added key 90123845890230948234234324."
If Laptop-Warhold could mean multiple devices (keys), well then we'd need to start talking about the keys. Which is a nightmare for usability.
A lot of this decision was driven by something we've seen with apple devices. Every now and then I'd get a popup on my computer - say when updating iOS - that said something like "you just started using iMessage on a new device, 'chris's iphone'. if you don't know what this you should freak your shit out." well - it has basically said that so many times with the same names over again, that I can safely assume that it's a near-useless warning.
Note I mean unique to you; 2 different users on keybase can name their devices the same.
Generally speaking...it's been a goal from the beginning that names on keybase are meaningful. Similarly if you look up "chris" in in our merkle tree (which is pinned to bitcoin) that leads to a deterministic chain of signatures. inside that chain, where I mention "work-imac-warhol", you're guaranteed to see the same answer as I am. So "chris" is as good as a key fingerprint or safety number. And so is my device name.
Maybe some people are more irritated by that than others (I'm certainly former-type), perhaps consider "advanced" to remove existing names for those who knows what they are doing?
If a user reuses MyMainPhone, just call it MyMainPhone|1 internally, and don't render this in the UI. Then tombstone MyMainPhone|0.
For the former, you can use Wire, which allows you to sign up using an email address (from the desktop). It also syncs conversations across devices and is end-to-end encrypted. You can just share your name or username with others for them to find you.
For the latter, Telegram uses a phone number for registration/activation, but you can set a username and send that to others (or better, share a https://t.me/<username> link). Anyone who's not in your contacts list would never be able to see your phone number, even if you're in the same group chat. They can use your username to tag you in chats or message you privately. (General commentary about Telegram's encryption is out of scope for the point)
I ended up landing on Wire and so far have found it to be really good. You can register with phone number but it is not required and you can register with an email instead.
If you give people a way to click "yes/accept/run" and they are determined to accomplish what they think is their intended task, they will just blow through any warnings.
npm here being exceptionally secretive on what it will install as dependencies as it can reach tens of thousands packages very quickly.
Actually I tried to install the app a couple of days ago.
But there is no version on F-Droid and the version on Play Store has Firebase Analytics baked in
Is there a plan for a clean F-Droid version?
Keybase uses root privileges only for making the magic /keybase directory available, where you can access your KBFS files (the redirector allows different users on the same system to see their own files). Keybase and KBFS run as unprivileged daemons (via the systemd user manager where available).
As giancarlostoro mentioned, you can unpack the .deb file and run the binaries out of there. If you put the binaries in your $PATH, you can even symlink the systemd unit files to your ~/.config/systemd/user and use the systemd user manager to manage your custom Keybase install. Note that the KBFS mount will not be accessible at /keybase, but instead at another location writable by your user (see https://keybase.io/docs/linux-user-guide#configuring-kbfs).
Finally, our build script at https://github.com/keybase/client/blob/master/packaging/linu... builds all components and assets without root and lets you handle the packaging and install after that.
If you have questions or more custom use cases, feel free to join the keybasefriends team to talk about it or make a GitHub issue!
"Good" is better than "best" if "best" is not available seems obvious, but it certainly isn't true in a lot of cases. If I tell you that X secure and you trust it to be secure, when it actually has problems -- that might be worse than me telling you that X is not secure.
People are bad at evaluating risk. If I want to pass notes in class and don't want my teacher to know what the note says if I get caught, then rot-13 is probably "good enough". But if I'm a whistle-blower for a government agency, my security needs are quite a bit higher. We can never make a perfect app, but I'm not sure I could define what "good enough" looks like for the general populous. It's completely reasonable to me that different groups have different opinions on the matter -- and I think that's a good thing.
Sorry I never used Whatsapp, so it's really really hard to understand what are those features that people keep arguing about that are missing or so much easy of use on that application. I use Signal and Keybase regularly and I don't find them lacking.
So any write up anywhere talking about those misterious and amazing features and user friendly UI that only Whatsapp has?
Ultimately, while people may have very little trust for the government in general, the one thing that people do trust the government for is establishing identity. We use government ID papers to establish our right to work, to open bank accounts, to enter legal agreements, and to cross borders. Why should communications be any different? We don't need to trust the government with the content of the communications (and we shouldn't), by not providing the government with the private keys. But why can't I get the government to sign a public key for me?
The issue it raises is whether people will eventually get locked out of society if the government decides to get antagonistic with somebody by revoking their public key and refusing to issue a new one, given a society where such a scheme is popular. But we don't have any sort of such protection today - the government can seize your passport, seize your driving license, freeze your bank accounts. A society in which the government solves identity issues for the digital age is only a net improvement over the status quo.
Best not to open that particular can of worms.
First, under "The Full Security Picture" heading in this article, it's claimed that forward secrecy is supported via time-based exploding messages. Pages 19 and 20 of the NCC report explain that, "The default chat protocol does not allow for forward secrecy since the same keys can retain indefinitely on a users device." So forward secrecy is not assured by default under this chat protocol, is that correct?
The NCC report goes on to say that, "Exploding messages introduce mechanisms for message deletion and forward secrecy; however, it is not clear to the user that keys and messages could remain on their device beyond the period specified during message creation." I interpret this to mean that there is a way to assure forward secrecy - which is exploding messages - but you're not making that explicit in this announcement. This seems a little disingenuous to me because in your FAQ, the first answer criticizes Whatsapp for compromising forward secrecy using the backup feature, but you don't have forward secrecy enabled by default in your chat protocol.
Likewise, this announcement makes a point of mentioning how other apps require you to trust the server due to resets, and why trusting the server is bad. But page 20 of the NCC report explains that, "While the default Chat encryption protocol does provide for message confidentiality and integrity, it does not provide for security in the face of device and server compromise, as keys and ciphertext are stored for a potentially indefinite period of time." So is it correct to say that unless users specifically enable exploding messages for their conversation (which is not the default), they actually do need to trust the server?
There are also a few drawbacks to the ephemeral messaging scheme NCC found that I think should be explicitly disclosed, because they don't require too much technical detail:
1. There is no deniable authentication on the default chat protocol. While exploding messages provide deniable authentication, this property fails in a group with more than 100 participants. It's fair to question whether that's a realistic place to expect deniable authentication, but it should probably be called out.
2. Exploding messages are based on the local client's system clock. Therefore it's possible for an exploding message to be indefinitely retained on another device by e.g. manipulating the local time.
___________________
1. https://keybase.io/docs-assets/blog/NCC_Group_Keybase_KB2018...
Correct: forward secrecy isn't on by default. We think there's a trade-off here. With forward secrecy, your old messages won't be visible on a new device, but users want this since Slack (and others) make it seem natural. However, you can opt-in to forward security on a per-message or per-conversation basis.
The report says "device and server compromise." Decryption keys never leave the user's client. What they mean is if: (1) the server's stored data is compromised; (2) your phone is also compromised; and (3) the messages weren't marked ephemeral; then the attacker might be able to read past messages, even if the user tried to delete them (i.e., did Keybase really delete the ciphertexts?). This line of reasoning is correct and one of the primary motivations for key ratchets. I don't think the report is claiming that users need to trust Keybase's server in general. They do need to trust Keybase to delete messages that are marked deleted, which would mitigate the attack above if conditions 1 through 3 are met.
We'd rather focus on the positive solution to the problem (which Keybase has implemented), rather than just pointing a giant finger at any other services which have the problem we're trying to address. I think I personally will sleep better tonight this way.
Still we want this conversation to continue.
Note that even with this, any new device added using the paper key still generates its own independent private key. Having per-device private keys is important to be able to revoke devices, and to be able to track which devices were responsible for any given action.
This will fail when AI software gets really good at imitating voice in real-time during casual talk, but we're not there yet (or - if that is my threat model, I'll find an out of band way to verify)
It’s a very worthy goal to make these events rare and scary so that users might actually bother reading those numbers out loud to each other.
"Keybase, we have a problem." https://freehuman.fr/posts/20238f40da8b01357816236af097d2ae
Maybe user /kbModalduality can
1. A server runs KBFS which syncs data with the server. No one could stop you from disabling it on startup and running wherever you need it.
2. Any app running without AppArmour/SELinux or outside of network namespace could get your real address. Latter is relatively easy to set up, I'm running VPN by default and all the apps inside are running only in the namespace with VPN tunnel device.
3. Last time I checked I could make my own package.
4. I don't have time to check it atm.
5. Link for audit results is somewhere in the comments on this post.
6. Works with uBlock on.
7. Some paranoia rant without looking how KB works: it's push/pull mode, all messages are stored as files you could sync.
8. Based on previous points.
9. Each connection is under TLS. Plaintext messages could be read via RAM, and if someone could read it, KB would be the last problem.
10. You could make your own.
11. Fixed. #ls -l /keybase would show you the symlink KBFS_NOT_RUNNING to /dev/null, but shows correct directories under user running the app.
12. Hello GDPR.
13. Like everyone in the world does.
14. Bad outro.
https://keybase.io/docs-assets/blog/NCC_Group_Keybase_KB2018...
Funny enough, I have ranted to friends/coworkers about sysadmins completely replacing machines and not telling anyone. How do I know it happens? BECAUSE OF THIS EXACT WARNING.
"Did you though, or did you just scroll down here?"
Keybase's example Cozy Street is not a MITM attack (i.e. an attacker has inserted themselves between two parties and can get the plaintext), it's just impersonation.
If it was a real MITM attack both Alice and Bob would get rekey notifications, unless they both confirm whenever they get a rekey notification a MITM attack is possible.
I also think that crypto is stuck in the early 90s by thinking real world meetups are the only way to authenticate keys. If you know what your chat friend sounds and looks like, willing to submit a video, and don't think your adversary can fake such a proof, a simple video of you reading your pubkey/safety number is sufficient. Is that scalably practical? no but it is possible.
That said: keybase is doing cool novel work, I commend them for advancing the state of the art.
That way everybody can use somehow e2e encrypted messages, but if you really care about the security you validate your keys and get a real trusted e2e encryption.
I wish they would take my money as a customer. I don't want to see them to away.
