> like Wire but without the video calling or end to end encryption
I'm not quite sure what you mean here, but Keybase does have end to end encryption—I think they're trying to position themselves as "Slack with end-to-end encryption."
I'm not quite sure what you mean here, but Keybase does have end to end encryption—I think they're trying to position themselves as "Slack with end-to-end encryption."
Note that the blockchain magic does nothing because the app doesn't verify it, and if it did, it would have to be a normal bitcoin client, which would take lots of traffic, storage (even with SPV, you need all the block headers), and shifts the trust to a lot of third parties instead of one (so that's quite trustworthy and great for my grandma that doesn't verify keys, but personally I'd prefer to just check a key in favor of running a bitcoin client on my phone). But that's not implemented yet so this point is moot anyway. And if I'm not mistaken, one needs to compute the merkle tree completely, that is, hash all sigchain of all Keybase users (imagine they become popular and you have to download a literal billion sigchains and hash them all together on a phone) to match it against the final value you get from the blockchain.
Finally, someone brought up verifying keys with another device. I'm not sure if that works. It might, depending on how the key exchange works and if it forces you to verify something in the app. If you don't, I mean, in the situation that the server spoofs your sigchain (MITM) to your friends, it can do that between your devices as well and report whatever value it used for the merkle tree to your command line client so everything checks out.
So it's not completely broken, but trusting the server on first use is m a lesser guarantee than all other E2EE software, and the fix is really simple so I don't get why they don't implement it (note that I don't mean to hint that they're indeed MITMing and that's why they don't let people verify it; I genuinely don't understand why not allow people to do this, I see no reason). My best guess is that they either didn't think of the scenario themselves (and NCC also missed it, which makes sense since they verified the crypto and code and not how a normal user would actually verify this in the UI) or they don't want to admit now that it depended on closed source servers being trusted all along.
Relevant question: https://security.stackexchange.com/questions/222055/how-can-...
My understanding is in the event of a server compromise in the beginning then the fake public key for the user that the malicious server would be sending would be easily detectable due to this client side check that is occurring. Whoever is behind the MITM attack would also have to compromise Twitter and all other places the user you are chatting with has published, no?
I guess this could work though, from the app I can indeed configure third party accounts (I guess in some next step, it'll tell me what to tweet to prove it). Assuming my phone generates the proof locally, that would prove it without doing manual verification, unless both Keybase and Twitter collude to attack us (or an attacker compromised both or sent NSLs to both), so that seems extremely unlikely.
Does the Keybase client check this by itself though? It seems a bit odd, the app connecting to third parties, but it could be. Like, I'd find out your IP address by adding a website proof where I host a text file.
We can test this if you want? Then I'll pcap my phone and see, while adding you, if my client connects to whatever third party you have configured.
Yeah, feel free to message me to test it out. My proof on twitter is here -> https://twitter.com/xan_nick/status/860495425920524290. You should also see it verify my HN and github, which I also have connected. (https://keybase.io/ahnick) Definitely interested in your results.
I looked at two things: DNS results in case there is a quick win (like a lookup for Twitter) using `tshark -e dns.qry.name -Tfields -r /tmp/pcap | sort -u`, and when there was no Twitter lookup to be found, I looked into IP traffic using `tshark -r /tmp/pcap -e ip.dst -e ip.src -Tfields | tr \\t \\n | sort -u`.
None of the IP addresses belong to Twitter in terms of reverse lookup or whois info. Since api.twitter.com (like *.twitter.com, as far as I can find) is hosted in its own IP range, that pretty much concludes the test already, but I dug into each IP address just in case they use some endpoint I don't know about.
The only IP which it talked to in the right time window and I couldn't attribute to a particular app was 52.216.100.45, which (SNI tells me) is AWS S3. Does Twitter uses AWS S3 and does Keybase connect to that directly without going through api.twitter.com? Seems strange.
The other IP addresses my phone talked to in the right time window are either pre-established connections (it would have to keep a permanent connection open to Twitter, and since I didn't add anyone for a while, that would mean it keeps a connection to Twitter open whenever I open the app... I would say we can rule that out) or attributable to other apps like Spotify (I am indeed playing music).
TL;DR it doesn't seem to check your Twitter proof.
Btw mobile.twitter.com is also hosted in their own range (104.244.40.0/21), so I would have spotted that if it had been contacted when I tested it.
It should be trivially verifiable by yourself: just watch what requests your device is making. And the app itself is open source, so you should be able to trust it.
---
> It should be trivially verifiable by yourself
Yeah sure, once you realize that third parties are required for security.
This shifts the root of trust from just Keybase to Keybase + a third party. That's not quite what I would call end to end encryption, at least not if there is no fallback to checking the keys manually. That's just not what the word means to me, even if the risk is sufficiently low that I guess it can be considered equivalent.
So I'm not saying it's a bad thing. If indeed all chat apps had such a scheme where third parties vet the keys, i.e. if it were commonplace to have to compromise two or more companies' servers before you can MITM someone successfully, it would be a huge improvement over the current state. Keybase is definitely being innovative here. It's just not how it's marketed (namely as being a secure chat in and of itself), and I hadn't realized that this might be what they mean when they write "end to end encrypted [but only if you sign up with a trusted third party!]".