5 ms·

As a Keybase user for a number of years I'm very happy with the platform. I'm probably part of the silent majority who use Keybase and have been genuinely happ

by ahnick 7y ago

As a Keybase user for a number of years I'm very happy with the platform. I'm probably part of the silent majority who use Keybase and have been genuinely happy with it and don't speak up when others have complaints. I use it for personal messaging and for my business and it has been great. I think Keybase's position on this is on point. This is spam and needs to be dealt with as such. It's no more an issue than with email. Anyone can send you a virus or harassing message in your email, but where is the angry mob of people beating down the doors of every email provider? There is certainly a problem that needs to be addressed, but lets not blow this up into something it is not. Keybase's spam controls will continue to mature as it grows.

lucb1e 7y ago
Is there any reason you chose Keybase over other solutions? From my perspective, it's like Wire but without the video calling or end to end encryption, or like WhatsApp but without the network effect, or like Slack but without a number of features. I don't really understand Keybase's selling point.
- Gaelan 7y ago
  > 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."
  - lucb1e 7y ago
    The app is only end to end encrypted if you trust the server to give you the right keys from the beginning (it's E2EE meets TOFU): since there is no way to verify what information (the "sigchains") the server sent to your device (no safety number like in signal, encryption key like in Telegram, fingerprint like in Wire, or whatever you call it), you have to trust the server. The app does verify that nothing changes, so the server has to consistently lie to the device, and to app clients only because a command line client could verify the keys. Then again, since very, very few people do or can do this verification, and since the verification tutorial in the documentation is relatively complex and broken (an api call doesn't return a signatures field the tutorial relies on) and nobody seems to have noticed, it's probably a safe bet for an attacker that compromised the server to just MITM all devices of some users without being noticed. 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-i-verify-keybases-end-to-end-encryption-between-me-and-a-friend https://security.stackexchange.com/questions/222055/how-can-...
    - ahnick 7y ago
      Sorry, but doesn't the client check the published keys itself? According to this document the client verifies the key that has been published on twitter or wherever else the user you are interacting with has publicly confirmed his/her identity. https://keybase.io/docs/server_security/following https://keybase.io/docs/server_security/following 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?
      - lucb1e 7y ago
        I didn't connect my account to Twitter or HN or anything, I just have a Keybase account to chat with a friend and wanted to check whether it's secure. 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.
        ahnick 7y ago
        Yes, supposedly the client scrapes it using the website. They have a number of third party integrations they do this for. It's actually a point of contention for them to add more third parties within the community. (People wanted LinkedIn and various other services) Going forward they want it to be the other way around and have third parties to start integrating with Keybase. (https://keybase.io/docs/proof_integration_guide https://keybase.io/docs/proof_integration_guide) Yeah, feel free to message me to test it out. My proof on twitter is here -> https://twitter.com/xan_nick/status/860495425920524290 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 https://keybase.io/ahnick) Definitely interested in your results.
- ahnick 7y ago
  There is no video calling, but I already have other solutions that I use for that. Keybase is end-to-end encrypted as mentioned in the other comment, has good multi-platform support, and is free. The fact that the user can revoke a device if it is compromised is excellent. I also have intentions for using it as a secure SSO ID across company applications using the API(https://keybase.io/docs/api/1.0/intro https://keybase.io/docs/api/1.0/intro). (Basically replacing how some companies use Active Directory) For me the secure identity and communication part of Keybase is a critical base layer that no one else really gets right. I can have a new hire create a Keybase account and use that to securely exchange documents (e.g. w-4 allocation, health insurance, etc.) two weeks before they are even part of the company. The only long-term downside to Keybase for me is it is a centralized cloud service run by a single company and the application is not open source. What I really want is a decentralized open source version of Keybase that's operated as a global network that lots of companies/individuals ran nodes for and you paid for your use of the network. That way I'd be more certain that it will be around in 10 years time.
  - lucb1e 7y ago
    Regarding "Keybase is end to end encrypted", it's sorta true but comes with an asterisk. I answered the sibling comment who asks that question directly: https://news.ycombinator.com/item?id=21741466 https://news.ycombinator.com/item?id=21741466 It's a relatively minor issue though (and one they could fix at any moment, it's not a crypto flaw but a verification flaw), so it's probably fine to send sensitive data over it. Definitely better than what most people use :)
Porthos9K 7y ago
I deal with email spam by dumping all emails from non-whitelisted addresses in the spam folder. My phone has an app to auto reject calls and texts from non-whitelisted numbers. If somebody wants to contact me, they can damned well get my consent first. If they can't be bothered to do that, then they have nothing of value to say to me.

by ahnick 7y ago

lucb1e 7y ago

Is there any reason you chose Keybase over other solutions? From my perspective, it's like Wire but without the video calling or end to end encryption, or like WhatsApp but without the network effect, or like Slack but without a number of features. I don't really understand Keybase's selling point.

Gaelan 7y ago
> 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."
- lucb1e 7y ago
  The app is only end to end encrypted if you trust the server to give you the right keys from the beginning (it's E2EE meets TOFU): since there is no way to verify what information (the "sigchains") the server sent to your device (no safety number like in signal, encryption key like in Telegram, fingerprint like in Wire, or whatever you call it), you have to trust the server. The app does verify that nothing changes, so the server has to consistently lie to the device, and to app clients only because a command line client could verify the keys. Then again, since very, very few people do or can do this verification, and since the verification tutorial in the documentation is relatively complex and broken (an api call doesn't return a signatures field the tutorial relies on) and nobody seems to have noticed, it's probably a safe bet for an attacker that compromised the server to just MITM all devices of some users without being noticed. 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-i-verify-keybases-end-to-end-encryption-between-me-and-a-friend https://security.stackexchange.com/questions/222055/how-can-...
  - ahnick 7y ago
    Sorry, but doesn't the client check the published keys itself? According to this document the client verifies the key that has been published on twitter or wherever else the user you are interacting with has publicly confirmed his/her identity. https://keybase.io/docs/server_security/following https://keybase.io/docs/server_security/following 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?
    - lucb1e 7y ago
      I didn't connect my account to Twitter or HN or anything, I just have a Keybase account to chat with a friend and wanted to check whether it's secure. 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.
      - ahnick 7y ago
        Yes, supposedly the client scrapes it using the website. They have a number of third party integrations they do this for. It's actually a point of contention for them to add more third parties within the community. (People wanted LinkedIn and various other services) Going forward they want it to be the other way around and have third parties to start integrating with Keybase. (https://keybase.io/docs/proof_integration_guide https://keybase.io/docs/proof_integration_guide) Yeah, feel free to message me to test it out. My proof on twitter is here -> https://twitter.com/xan_nick/status/860495425920524290 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 https://keybase.io/ahnick) Definitely interested in your results.
ahnick 7y ago
There is no video calling, but I already have other solutions that I use for that. Keybase is end-to-end encrypted as mentioned in the other comment, has good multi-platform support, and is free. The fact that the user can revoke a device if it is compromised is excellent. I also have intentions for using it as a secure SSO ID across company applications using the API(https://keybase.io/docs/api/1.0/intro https://keybase.io/docs/api/1.0/intro). (Basically replacing how some companies use Active Directory) For me the secure identity and communication part of Keybase is a critical base layer that no one else really gets right. I can have a new hire create a Keybase account and use that to securely exchange documents (e.g. w-4 allocation, health insurance, etc.) two weeks before they are even part of the company. The only long-term downside to Keybase for me is it is a centralized cloud service run by a single company and the application is not open source. What I really want is a decentralized open source version of Keybase that's operated as a global network that lots of companies/individuals ran nodes for and you paid for your use of the network. That way I'd be more certain that it will be around in 10 years time.
- lucb1e 7y ago
  Regarding "Keybase is end to end encrypted", it's sorta true but comes with an asterisk. I answered the sibling comment who asks that question directly: https://news.ycombinator.com/item?id=21741466 https://news.ycombinator.com/item?id=21741466 It's a relatively minor issue though (and one they could fix at any moment, it's not a crypto flaw but a verification flaw), so it's probably fine to send sensitive data over it. Definitely better than what most people use :)

Porthos9K 7y ago

I deal with email spam by dumping all emails from non-whitelisted addresses in the spam folder. My phone has an app to auto reject calls and texts from non-whitelisted numbers. If somebody wants to contact me, they can damned well get my consent first. If they can't be bothered to do that, then they have nothing of value to say to me.