1. 24
  1.  

  2. 20

    This is missing one important piece that Keybase got right - one key per device. Nowdays people have multiple devices. It’s natural that they want to sign or encrypt using any one of them. If the system only allows one key per identity, then users will have to transfer keys, and transferring keys is what puts them in danger. The less the key moves, the safer it is. This just plays against it.

    1. 4

      Agreed, I guess that you can verify new devices by signing their keys from a previously verified key pair. This provides a chain of trust back to this first desktop app for example.

      (Edit: typo 🐾)

      1. 3

        I half wonder if keys.pub (started by an ex-(?) keybase employee) is an attempt at “forking” Keybase in lieu of the Zoom acquisition. This came out very recently, with the Zoom acquisition late last week. Timing wise, it’d make sense, and feature wise – well, yeah, one key per device is great. I guess, even if this conspiracy theory were true, I don’t see it on the “what’s next?” list.

        1. 2

          Interesting because I had the same exact thought: https://github.com/gabriel lists themselves as “formerly keybase” and the project looks identical to keybase in technical aspects. If I had to guess he was the technical mind behind keybase, got annoyed by the acquisition news and rewrote the backend from scratch. First commit is dated 5.12.2019.

          1. 1

            First commit is dated 5.12.2019.

            That seems to invalidate the idea, really. The acquisition just happened, and it would not have been a thing that spanned a year of time. Though, I guess the “shopping for an acquisition” could have happened back then, and he, as a “Founding Engineer,” would have been informed of such a major strategic change (Probably).

            The other possibility is that this was started as a “test bed repo” – we test out ideas here before committing to them in the product, but it’s close enough to the product that we know whether or not it’ll work…

            Either way, the server still isn’t open source as far as I can tell. Would love to see a … as much as a I hate to say it, decentralized block chain, version of this all. sigh

            1. 2

              Ah yes because I too want my key to be rewritten by the person with the most compute power

              1. 1

                Why would it be rewritten? The idea I am after is decentralization. Keybase and Keys.pub (as far as I can tell), have a central server that is closed off, which is a problem as they are now owned by Zoom, who people don’t trust. Keybase uses a Merkle Tree to build a “chain” anyway. Why not distribute it, and provide more “zero trust” mechanisms to avoid this problem? I guess there’s the problem of trusting the validations, but that happens client side in keybase, so.. maybe it’s solved? Disclaimer: I am not a cryptographer, and have not worked through this idea.

                1. 2

                  As I understand it, an actual Merkle tree crypto currency is at the whim of the majority, and if any one interested party could spin up enough devices to become the majority, then they may write the future as they see fit.

                  1. 1

                    Oh yes! Hmm. I see how this could be a problem, BUT, keybase already has a design which requires a signature from a key you own to add a new key, for instance, and (probably?) also to revoke an existing key. So, I don’t think there is a consensus problem? But maybe a malicious actor could refuse to propagate updates that don’t match their special sig verification, making it possible for user revoked keys to still be seen on some replicas? But even then, the user will not encrypt/sign messages with a revoked key, which makes me think that this isn’t a real risk? Am I missing something?

        2. 3

          This is an excellent concept and an aspect I didn’t catch originally. Key management is actually a fascinating topic I should read up on a bit more. Thanks for pointing it out.