1. 16
  1.  

  2. 8

    This is like GitHub, taking a decentralized system with a bad UI and making it dependent on their centralized system for a good UI.

    1. 7

      By far the biggest problem with Keybase.io is the suggestion to upload your private keys to their service. This completely breaks security. I like the ability to easily verify via other channels like Twitter and Github; GPG supports varying trust levels so you could trust a key .

      I suppose the target audience for this service is technical people who are (excusably) put off by the complexity of gpg --help. Ultimately, I hope Keybase helps the existing GPG system rather than attempting to create a silo.

      1. 2

        the suggestion to upload your private keys to their service.

        Not having received my invite yet, I hadn’t realized that was a requirement. That’s not very comforting.

        1. 6

          It’s not a requirement: you can do everything using their command line client, which is open source and doesn’t require uploading private keys. Private key hosting is a convenience thing for using their webapp to sign things.

          I wish they wouldn’t even make private key signing possible, but it isn’t a hard dependency.

        2. 2
          1. 3

            That response is quite concerning – that sort of security/convenience argument is not a strong one, and further it encourages an insecure default to new users of cryptography; which is precisely the sort of user keybase is trying to attract.

            In particular, no matter how well encrypted your key, it is possible that an attacker breaks in, downloads all those keys, and attacks them in-bulk using standard attacks against a large keybase. It’s a massive security hazard and no amount of convenience can justify it.

          2. 1

            That suggestion is part of what makes me suspicious of the entire system. I can’t see how any well meaning, moderately competent security person would suggest such a thing.

            Building a new centralized directory, because “PKI is hard” makes me think that “building a silo” is exactly what they’re trying to do.

          3. 3

            I like his proposal of a curated set of tools for encryption with a friendly UI. Even if it’s CLI.

            I’d also like to see (if there’s not one already) a nice-looking site that educates on the basic concepts and best practices for sending and receiving encrypted messages securely. Something like Bitcoin’s WeUseCoins, for instance.

            1. 2

              @judsonlester Regarding the shell scripts you propose, I’d be interested in helping with an effort along those lines.

              Everyone knows that GPG has a terrible UI, and we all like to rail against bad CLIs, but does anyone have examples of good design principles applied to a complex command-line application? I’d be very interested in any research that’s been done in that area.

              1. 2

                Related discussion of usability & crypto tools suggests that there are very few people with a design background working in this space right now.

                1. 1

                  I think there’s a couple of basic principles that could be usefully applied. I think of the difference between (in Ruby-land) Thor and Rake - Thor encourages “command subcommand argument” style command lines, and goes the extra mile to e.g. colorize output, and output only the details a user cares about.

                  Also: gpg remains a complete implementation of RFC 4880 more than anything else. It’s like the git plumbing - I think there’s a lot of room for porcelain there.

                  I think you could provide a 5 feature implementation (generate keypair, trust pubkey, sign-encrypt-armor, decrypt-verify, revoke keypair) in the form of well-commented scripts so that users can delve into the deeper applications at their leisure.

                2. 2

                  I’ve started a github repo for this project (oh, the irony!) at https://github.com/nyarly/simplekey - /cc @englishm @brunov

                  1. 1

                    I agree with this: “The best light I can see that in is that they’re well meaning, but simply unqualified to design and run a cryptographic system.”

                    The aspects of Keybase.io that aren’t reinventing existing OpenPGP infrastructure remind me a lot of ClaimID.

                    1. 1

                      Which is shut down now…