Hacker News new | past | comments | ask | show | jobs | submit login

> Keybase is a CLI

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?

> Keybase has a relatively functional electron app

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.

Keybase isn't centered around a PGP key, each account is like a web of devices and cross-verifications of different proofs. All of this is stored and verified locally. When you open a chat with "rakoo on keybase" you can be sure that all messages are encrypted to me because the keybase client will have used the equivalent of my public key. The same process allows us to exchange files, or share a git repository hosted on keybase. There is no specific "chat" account, it's just part of the account.

> you can be sure that all messages are encrypted to me because the keybase client will have used the equivalent of my public key

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.

That's not how keybase works. Keybase doesn't send you encryption keys you blindly trust. It only sends you a bunch of data structures allowing you, the sender, to verify that your correspondent really is who they claim they are. All verification of the proofs is done on the client. That means that your client is going to fetch all the sites allegedly linked to that account and do a verification locally. Because of this, if keybase ever receives a court order, there must also be a court order for Twitter, GitHub, Mastodon, all the websites that are linked to this account.

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...

Oh gotcha - the lack of visibility into the verification codes could be an issue, but IMO it's like signal or any other encrypted chat app - the complexity is hidden from the user, but the identities are still verified. All of the client code is open source and so you could dive in to see how verification is handled, but why should you need to? And what code could the app show you that a malicious app running a MITM attack couldn't?

> what code could the app show you that a malicious app running a MITM attack couldn't?

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.

Applications are open for YC Winter 2020

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact