4 ms·

Personally, I love Keybase and it is my #1 choice for communicating with a few people, but bugs are far too frequent for me to consider it for a business. It's

by corin_ 7y ago

Personally, I love Keybase and it is my #1 choice for communicating with a few people, but bugs are far too frequent for me to consider it for a business. It's getting better, but not close being business ready imo.

lucb1e 7y ago
I've been using Wire on iOS, web, desktop (electron), and Android, and Keybase on Android and desktop (cli). Both are not great but Keybase is definitely the more buggy. Wire on Android, on the other hand, is also quite unusable due to its battery drainage. And both are pretty much unusable on desktop: Keybase is a CLI (not even a TUI) and Wire is Electron. I'd prefer a TUI over Electron but it's not even a TUI, so I guess Wire wins this round. Keybase also doesn't have a web client, which is why I have experience with the command line client. I think that says enough in and of itself. 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.
- DuskStar 7y ago
  > 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?
  - lucb1e 7y ago
    > 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.
    - DuskStar 7y ago
      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?
      - lucb1e 7y ago
        > 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.
    - rakoo 7y ago

by corin_ 7y ago

lucb1e 7y ago

I've been using Wire on iOS, web, desktop (electron), and Android, and Keybase on Android and desktop (cli). Both are not great but Keybase is definitely the more buggy. Wire on Android, on the other hand, is also quite unusable due to its battery drainage. And both are pretty much unusable on desktop: Keybase is a CLI (not even a TUI) and Wire is Electron. I'd prefer a TUI over Electron but it's not even a TUI, so I guess Wire wins this round. Keybase also doesn't have a web client, which is why I have experience with the command line client. I think that says enough in and of itself. 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.

DuskStar 7y ago
> 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?
- lucb1e 7y ago
  > 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.
  - DuskStar 7y ago
    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?
    - lucb1e 7y ago
      > 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.
  - rakoo 7y ago