Keybase has a relatively functional electron app on Mac and PC that I've used, and presumably also Linux.
> I also haven't figured out how to verify someone over Keybase
Isn't the goal with Keybase to see "this person is accountiknow on Github" and do verification that way?
Oh, then I am mistaken, thank you for correcting me and sorry for talking nonsense.
> Isn't the goal with Keybase to see "this person is accountiknow on Github" and do verification that way?
Yes, but that doesn't help me because my chat account is not cryptographically tied to my Keybase account.
So let's say I sign this statement that I am lucb1e on Github as well as on HN as well as on Keybase. You know and can verify that I have all these identities nicely tied to my PGP key. The person who controls those identities clearly also controls the PGP key. Now comes chat. You start a chat with me, and... magic? I don't know, but there is no verification code that I can use to check that I am really talking to lucb1e on Keybase; nothing that ties it to a PGP key; nothing that ties it to the HN user. My device might be encrypting the data for an entirely different key (whose private part is known either by Keybase or some other (W)MitM ((Wo)Man in the Middle)) and there is no way to check as far as I have been able to find.
But it's not end to end encryption if you can't verify it. Heck, even Whatsapp can do this. Let me cite Wikipedia on end to end encryption:
> Because no third parties can decipher the data being communicated or stored, for example, companies that use end-to-end encryption are unable to hand over texts of their customers' messages to the authorities.
So if Keybase got a court order to intercept your messages, they totally can. Just because Keybase sends you an encryption key, doesn't mean you got the one of your conversational partner: you'd have to do funky stuff (read and interpret the app's memory, or decompile and patch it to show fingerprints) to be able to verify that. That's unauthenticated encryption. It's like clicking past an https warning without ever seeing the warning.
This verification happens everytime you receive new information about your peer; if something has changed it must be new, otherwise a rollback or a change in history is detected. Once your client has made this automatic check you can get a list of the linked accounts and manually check if they are the correct ones; at this point your client can take a snapshot to prove even more strongly that it's the correct one. Those snapshots are shared, so if an account has multiple followers (the name of someone whl manually verified na account) it's that much harder to crack.
If that's not enough, any change to any account is stored in a Merkle tree whose root is thus monotonically incrementing, and tht tree can be retrieved at any time to verify nothing happens. And that root is stored in the Bitcoin blockchain so that any fork is easily traceable. You really have to go out of your way to distribute a compromised key to a client. In the meantime the encryption is end-to-end.
Here's an article about how they protect against malicious attacks against the server: https://keybase.io/docs/server_security
Here's how they store that Merkle root in the Bitcoin blockchain: https://keybase.io/docs/server_security/merkle_root_in_bitco...
I trust the app itself, since you can indeed verify that code, but the idea is that you don't have to trust the (Keybase-managed) server.
So what you'd verify is the encryption key. If we do a Diffie-Hellman key exchange and our shared key is abcxyz, then both phones should show that key. If an attack is going on, the key would have to be one known to the attacker rather than your conversational partner.
Simplified, DH is quite easy: you pick a base number and a modulus (public knowledge), both parties generate a random number (let's call it Rand), they do base^Rand or Rand^base (I forgot which way around), apply the modulus, send the number to the other person, and apply the same exponentiation with the number you received (and apply the modulus). The resulting number is only known to both parties, even though anyone could have observed the public parameters and the numbers that were sent to the other side. If a person wants to intercept this, they need to pick a Rand themselves and do the operations with that, replacing the number that gets sent over with their own. Because they can't know the Rand of either legitimate party, they will necessarily have a different result, and so the resulting encryption key is different. Both parties would (upon verifying their key out of band, for example by holding their phones next to each other in real life) see different encryption keys.
It's not about verifying the source code, but verifying that the server which I'm talking to is not malicious (for example if someone compromised it). That's the one property which makes end to end encryption "end to end" :)
Similar schemes can be made with different types of encryption (Diffie-Hellman is one of a few good methods), but with end to end encryption, the end devices are always the ones that verify each other.
What I'm trying to say is, definitely also try Wire as it's similar but slightly better. I also haven't figured out how to verify someone over Keybase, so it's basically unauthenticated or opportunistic encryption. By comparison, Wire is considered secure enough by my company after doing a pentest on it, which says quite something (most customer's stuff we would run from if we were thinking of using it), and we use it as our main communication platform within the company.