1. 23

I would like to know your opinions and what is your experience https://keybase.io/. What do you think about it?


  2. 11

    keybase the command line tools are alright - I still prefer using good old gpg. The service itself is nice since I think it makes pgp more accessible.

    On the other hand keybasefs, the encrypted filesystem they have in beta, is pretty awesome. Rather than having to walk someone through how to use the keybase toolset or the gpg toolset (roll a keypair, publish their public key, etc), you have them sign up, verify themselves, install the package and you are ready to share files securely between them or between multiple people. Now all I have to do to share sensitive info with people is to create a directory (mkdir /keybase/private/me,them) and drop the file in there. For sharing with multiple people it is the same process, although the directory would be /keybase/private/me,them,third_person.

    It’s pretty neat.

    1. 3

      I’m gonna have to look into KBFS now, it seems pretty slick. PGP doesn’t make file sharing hard, if you know PGP, but it would certainly be nice to not have to explain PGP to people before sharing a sensitive file.

    2. 8

      I think Keybase has the potential to be really big, if executed well. Tying together and unifying disparate identities is pretty cool as it is, but the real value proposition IMO is in facilitating certain kinds of (secure) exchange between them. They’ve started doing this with the Keybase File System (KBFS).

      Here’s an example, supposing we live in the not-too-distant/improbable future where one can claim ownership of Lobsters identities on Keybase. I’m just going to pick random users from this thread; maybe I want to share a file - encrypted and signed - with rauryan. No sweat:

      $ cp my-file /keybase/private/jtobin,rauryan@lobsters

      The above would work even if rauryan hasn’t signed up for Keybase yet; the file will be accessible to the user who signs up for Keybase and proves ownership of rauryan’s account on Lobsters (by posting a signed claim in his Lobsters profile).

      This functionality exists right now for users on Github, Twitter, Reddit, etc. I see gamache has a Twitter account listed in his profile, so I’m literally going to copy a file to our shared folder right now:

      $ cp message.txt /keybase/private/jtobin,gamache@twitter

      Gamache should be able to check our private shared folder now (assuming he is on Keybase and has claimed ownership of the @gamache account on Twitter) and see a secret message.

      I think this has a ton of potential when you consider really user-friendly Bitcoin/Ethereum/etc. integration that I’m sure Keybase has on their radar. The following would be pretty cool, non?

      $ keybase send btc 0.01 pobrien@lobsters
      $ keybase propose some-ethereum-contract.sol jtolds@lobsters
      1. 3

        I tried to get them to add lobsters support a year or two ago (we’re a more natural audience for this than hackernews) but they weren’t interested. Maybe we should try again.

      2. 5

        I’ve used it a few times. I think the main issue that prevents me from using it more is that when I go to reach for it, I’m usually trying to send private key material to another developer, and then remember that GPG transferred stuff doesn’t have forward secrecy. If keybase.io had a way to transfer information to another user with forward secrecy, that’d be so sweet.

        1. 1

          Well, KBFS doesn’t have forward secrecy, but the saltpack standard does - see the ephemeral keypair generation in the header section. So you can’t have FS inside the keybase filesystem, but for individual files encrypted with the keybase CLI you can.

          1. 1

            post-it and fire, still undisputed champ of secret distribution

          2. 5

            I don’t think about it much. It’s basically pgp.mit.edu for 2016 – a place where I can look up public keys for people with an internet presence.

            1. 8

              I wish they had an actual keyserver.

            2. 5

              I think it’s well executed and they’ve really thought about the user experience of signing and verifying messages. I’ve signed up over a year ago yet I have never actually used it: it’s not solving a problem I have. I’ve never needed to verify anyone’s identity or sign a message to them. I’m not saying those aren’t useful and vital functions for some people but I just don’t encounter those use cases day to day.

              1. 3

                I’ve been a bit iffy on using it, it seems like it’s most practical when tying together several social media identities as proven, and I don’t really want there to be a definite connection between who I am across services. (I don’t necessarily want to maintain a “brand” like a lot of people in this sector do. ?) I don’t mind giving people a way to look up a key for sending me messages on each service separately though.

                1. 2

                  I don’t actually use my keybase key for encryption of much. I’ve sent a few test messages, but I already have encryption keys wholly in my control that I tend to use more frequently. What I do use keybase for is as an identity verification - I have those keys, they’re mine, and they’re published. If there is a signed keybase verification post on one of my accounts, it could only have come from me. There’s value in that, to me, even if I don’t use the key for anything else.

                  As far as the platform goes, it works, and I like that it’s easy to use for a newbie. The only reason I don’t really use it for encryption is that I am already used to using other things.

                  1. 2

                    I really like the idea: use a common-sense definition of “identity” to help you find the public key for someone you know. Everything else (the crypto) seems to be built on top of standard gpg.

                    I used their library to play with a “tar” (ask your parents) replacement last year: https://github.com/robey/4bottle

                    1. [Comment removed by author]

                      1. 1

                        Could you please explain why?

                        1. [Comment removed by author]

                          1. 5

                            Keybase is pretty much a keyserver with a different protocol. It also removes the need for things like key-signing parties, which are not only hard to do effectively, but don’t really scale. The purpose isn’t to promote other sites, the purpose is to use those other sites, which have a concept of identity ownership, to provide some means to verify that the owner of a key is who they say they are. If you trust github.com/apg is me, and apgwoz HN and Twitter are me, then Keybase can help you verify the proofs I’ve placed on those services.

                            As for the central nature of it – a read only mirror would be possible. And, really, I’m not sure how this is any different than pgp.mit.edu, a centralized directory of public keys.

                            1. [Comment removed by author]

                              1. 2

                                That’s true! But just posting the public key doesn’t really establish any trust in it…

                                1. 3

                                  Does Keybase solve this? Putting my key on Github proves that the key belongs to the Github user in question (malevolence on Github’s part notwithstanding). Is Keybase’s method to prove that a key belongs to a {twitter,hackernews} user more secure in any way?

                                  1. 3

                                    Keybase doesn’t store your public key on Github, or ask you to at all. It stores a verifiable signed statement, that can be used to prove that a person in control of the Github account is the same as the controller of the Keybase account. Because Keybase supports signing statements and posting them on other platforms as well, I can verify that the same key produced all of those signatures – and if it did, be reasonably sure that the same actor is in control of them all (which may be a malicious actor of course – but this is no different than someone with a fake id showing up to a key signing party).

                                    Keybase then, basically, stores a chain of all of these actions (for all it’s users): who you’ve tracked on Keybase, that you’ve changed your identity on Github (probably done via revocation and signing another statement), that you signed your twitter account, that you own this domain, that you ______. All of which is verifiable cryptographically.

                                    I’m sure I fucked something up in the explanation, but they do have documentation about all this…

                                    1. 1

                                      Keybase doesn’t store your public key on Github, or ask you to at all. It stores a verifiable signed statement

                                      I’m trying to understand whether it’s any more secure than adding identities such as “github!foo” and “twitter!bar” (choose your syntax) to your key, and then posting the key to Github. Keys are always self-signed, so they should count as verifiable statements.

                                      Storing a chain of all these actions is a good argument, perhaps, but again, I wonder if it adds anything except the ability to revoke individual accounts. And even that I’d rather store in the key itself somehow.

                                      As an aside, signing parties with government-issued IDs never made sense to me. I don’t care what your legal name is, I just want to know that you’re the same apg I talked to on lobste.rs.