Shameless plug: I wrote a little guide[1] how to use keybase.io and GPG to sign git commits. It was posted on HN a while ago[2].

  "Ironically, only the first commit is signed."

[1] https://github.com/pstadler/keybase-gpg-github [2] https://news.ycombinator.com/item?id=12289481

Meta-HN-Comment: Annoying how HN locks post voting & commenting and you can't repost the link either. Anyone know what HN's reasoning on this is, or for that matter, why there's not a meta-HN?

(If my use of meta is unclear, see how Stack Exchange uses it.)

I don't know why HN locks voting. I think it's about preserving history - that was the reason given for the short time available to unvote or undown a comment. (In this thread https://news.ycombinator.com/item?id=12073675 )

HN has a duplicate detector. You're allowed to repost things that are on topic and that didn't get much conversation, so long as you don't do it too much. That link got > 100 comments and > 200 votes, so that counts (I think) as substantial discussion. https://news.ycombinator.com/item?id=7544123

HN doesn't have a meta because META == DEATH.

I'm tempted to set up a totally unofficial unsupported HN Meta community on Imzy, but it's probably a bad idea.

Have you read Jeff Atwood's Meta is Murder, and his subsequent Listen to Your Community, But Don't Let Them Tell You What to Do? meta.stackexchange.com and its sister sites have as far as I can tell been very successful.

We use it at work to share tmate (https://tmate.io/) sessions. I wrote a shell script to save the session to our mutual shared private keybase directory: https://github.com/sukima/dotfiles/blob/master/home/.bin/tma...

I use it to encrypt messages to friends / customers via Facebook messager, Slack, or public forums when I'm dealing with sensitive data.

A few of my friends use this (which I wrote): http://lettergram.github.io/AnyCrypt/

You may ask, "when do you really deal with sensitive data?" My answer, is a lot more often than you think... The cool part about encryption, is I can use it over an insecure line to communicate. For example, I can post encrypted text here and only people I wrote it for can read it.

You might want to be careful with intentionally publicizing encrypted data, since it might only be secure for a limited time. Computation becomes cheaper over time (making brute force more feasible) and new vulnerabilities in the encryption algorithm can be found.

Totally agree, I assume the average HN reader knows this.

Regardless, ill try to be more careful in the future.

That is definitely one interesting thing about keybase.io: it does not provide forward secrecy in its encryption tools.

However, I think it is an interesting concept for identity proofs.

Do you right click every time you want to send a message? It seems like a great application for large block messages like an email but the Facebook messenger example seemed a little klunky, why not switch a secure instant messaging platform to save those additional steps?

I send messages like this sometimes, it's a handy way to send an encrypted message every now and then and also doubles up well as a "if you're using your PC with someone else, or have it hooked up to the TV in your lounge room you might want to look at this later" notice.

I saw keybase.io as a public key directory which makes it easier to find friends, family and colleagues public keys. That´s my intended use of Keybase.io. I haven´t actually used it yet for anything serious, although I´ve found ways to use PGP public/private keys to encrypt and decrypt local files on Mac and Windows, e-mails using mailvelope or keybase.io so that should take care of everything. But if people don´t adopt it I´ve got no use for it. And people around me didn´t take to Keybase as such it´s just sitting there so that maybe eventually I can use it. Right now it´s kind of useless.

At my company we use Keybase to help us validate keys for new employees as we bring them into the fold, since the company is 100% remote. We also use KBFS for some tasks as well. You can see more in the article I wrote for our company blog about our using of GPG + Keybase + Git + Hub for commit signing + KBFS at https://eligible.com/blog/commit-signing-with-git-hub-keybas...

I used it once - to coordinate a project ownership transfer with a person not typically using pgp. Explicit message "this person is XYZ on GitHub" helped.

Sharing secrets with remote co-workers. It's easy enough to use that I can expect pretty much anyone to be able to figure it out in real-time.

Ditto. Remote and non-remote, secrets and other slightly-less-but-still-somewhat secret files. Before that we handled it via 1Password, but it's so handy to just `cp` the files to the private/you,co-worker folder and do whatever you need with the files.

Sharing .env files full of secrets to bootstrap a project. Typically just dev credentials, not production, but still a nice way to hand those semi-sensitive data around easily, and without committing them to git.

I use it to sign my git commits.

Never really thought about using it to share credentials but I might give that a try.

Feature Request: I'd love an easier way to find the keybase accounts for my friends on twitter.

Oh, one more feature request. I'd like to be able to verify the identity of people on Venmo.

I use it as the primary way to exchange secrets with others.

This isn't regular use as I don't regularly have secrets, but I've used it to exchange passwords, 2FA QR codes, and other sensitive data like this, with people with whom I'm remotely communicating with.

Internally (I work at Keybase) we use it even more for the opposite. We do use it for secrets, but very often we put public info into KBFS we want to verify.

As an example, a number of us use it to address pain points around SSH. I keep this: /keybase/public/chris/keys/ssh.txt (you can see them on keybase.pub/chris/keys/ssh.txt ), and I keep all my known hosts as a reference in another file (that one in my private directory)...so when I'm SSH'ing to a machine from a new one I never have to say yes to connecting to a fingerprint I haven't actually verified. If I don't recognize a fingerprint then in turn I contact the appropriate party using Keybase, get a confirmation, and then add it to my file.

I'm bringing up SSH because we're thinking of making SSH public keys an important part of Keybase and curious if others share the same pain point. You mentioned a bunch of team uses and wondering if this was part of your use too.

Haha, hello from https://keybase.io/twitchax!

This is interesting, and I am super glad that you are here, haha. I am about to (in 2 hours) give a presentation on keybase.io for a MS-level cryptography course. I like all of the features, but I was curious what the primary goal was.

I see a lot of people mentioning the encryption tools (which are awesome and easy-to-use); however, I cannot help but think that keybase.io is really about identity proofs and signing. Would you say that this is the case?

If so, are there any plans to, say, add driver's licenses, passports, or other documents to a user's signature chain? There are some countries which actually give citizens public/private keys for cryptographic purposes like voting, etc.? I ask about this specifically because my professor is Josh Benaloh (author of the Benaloh cryptosystem [https://en.wikipedia.org/wiki/Benaloh_cryptosystem]), and one of his major passions is voting and identity proofs for internet users.

Thanks for joining in, by the way!

Bonus question if you have time: any thoughts about forward secrecy as part of the encrpytion stack in keybase.io?

This is a great idea. Right now my team has an onboarding script we maintain in a Git repo and we prepopulate a separate known_hosts file with our validated keys, but from that point forward each person maintains it themselves. It'd be nice to see some automation around SSH key validation. For instance, if from Keybase we could publish our SSH public key and additionally have some sort of facility to integrate with OpenSSH locally so we can use the NACL functions to maintain a signed/verified copy of a known_hosts file locally.

The known_hosts file is kind of a weak point for SSH security when using public key auth, and I'd love to see something external that can improve upon this.

Interesting use case. I suppose you could put photos of yourself, or any other bits of information that you want to be able to say is provable as having been provided by you.

We've used it a couple of times recently to share credentials with a remote team.

Interesting...any reason you chose it over other options?

Other options - like team password managers?

It was kind of ad hoc thing; it's free and was easy to setup.

Yes, I was just curious if ease-of-use was one of your primary goals.

A run a small app development studio, and have a couple times a month where a client needs to share login credentials to iTunes Connect, Google Play Dev Console, Facebook, etc.

In those situations, I just give them my Keybase public encryption page, and have them enter the credentials and then send me the cypher text. Works fantastic, and much better than just sending via plain text over email or Slack.

Allowing people to verify my message came from me without needing to setup PGP themselves. They can just use /verify and throw my message into it. By using the signature consistently it raises red flags when a post of mine isn't signed or doesn't verify.

Of course - this assumes Keybase has not been compromised, but that isn't an attack vector I worry about.

The point of keybase is to distribute trust in them across multiple (social) trust-statements, so you don't even need to trust them Their implementation is supposed to check all those twitter/github/dns trust statements to verify the message.

That only works if the message is coming from somewhere that can be linked with Keybase. Say for example I sign a message on Voat rather than Reddit. Then what? There exists thousands of sites that can't be paired with Keybase.

Pasting a message into /verify is a lot easier for people than installing GnuPG and verifying it themselves. Still faster and more user friendly even if they already have GnuPG installed.

Offsite backups. I use duplicity to back up my ownCloud servers data directory to my kbfs private directory. There's not a lot of free storage from kbfs, but I don't need much.

[edit] Otherwise, I haven't really found a use for it since setting it up. Would probably be really useful if a tonne of people used PGP, but they don't.

I use it as a simple way to share credentials over insecure channels.

I use keybase.pub to host a whole hugo [1] site. It was very easy to put it together. Updating it is just a hugo + rsync to my keybase public folder.

I also stash some dotfiles in my private folder, and it's extremely handy for sharing signal desktop client safety numbers with other crypto minded friends. I use it for my ssh public keys as well.

I've also used it for snippets with coworkers (secrets or no, it's really nice to be able to sent python /keybase/private/foo,bar/test.py in a chat window, and it can be directly pasted without needing to share the script, or relocate the paths in the command.

I feel like I've naturally developed tons of ways of using it at this point. I'll probably come to depend on it, soon enough.

[1] https://gohugo.io/

Publishing My Private Keys: http://nullprogram.com/blog/2012/06/24/

My previous company was looking into using it as a place to store the app's public key for that user and find other users of the app (with their public keys) while being able to verify them.

At the time, Keybase didn't have the appropriate APIs to allow third-party integration like that. I haven't checked if anything happened on that front since.

I use it to authenticate and encrypt sensitive messages to friends online, over insecure channels.

It holds my git-signing key. That's all I do with PGP atm.

We use it to distribute public and private key pairs. The aptly-named "public" and "private" folders are quite convenient for such things.

Off topic, but related: I have some keybase invites available, and I'm sure others do as well. Contact info in my profile if anyone would like one.

just discovered it, looks like an interesting attempt to solve exchanging public keys. feels wrong to put public keys in a cloud solution like this---

Why wrong? Is there a difference you see between a cloud service like this and PGP keyservers?

Not OP, but there are all these places that are tied quite strongly to my identity. Why not tie my PGP key to them in an explicit and centralized manner.

you shouldn't put your private key in the cloud..? ..or maybe it is considered acceptable these days? theoretically--if you put your private key in cloud, and you pass the passphrase you give everything to the man in the middle for decrypting, but also give them the possibility to impersonating you.

The private key can be stored in the cloud but is decrypted client-side with JS. If you have nefarious JS running (like from some evil extension), there is a risk, but there is not the opportunity for man-in-the-middle.

You don't have to put your private key on Keybase servers to use Keybase.

Seamless secure file sharing with decent identity authentication - https://keybase.io/docs/kbfs

it's only secure if you can ensure that no one has tampered with your keys. if your keys are generated behind a service like this, how can you know that you are safe?

You can use Keybase without their ever seeing your private key.

It's an easy way to exchange public keys and to introduce people to crypto.

kbfs is pretty sick but I mainly use it for my git signing key :)

It's a nice idea but not really well-implemented.

Why do you say that?

Not the parent, but a major issue with it is, it's slow.

  mike@snake:/keybase/public/mickeyc$ time ls
  index.html

  real	0m1.156s
  user	0m0.000s
  sys	0m0.000s
  mike@snake

The current client is not a syncing client like Dropbox/ownCloud, it's a network fs client.

I don't know if the slowness is due to the requirement to access the network, or the crypto, or whatever, but it will remain a toy unless they do something about it.

I understand it's very much a beta though, so that's ok.

Okay, that's understandable, but how do we know this is an implementation-level problem rather than a fundamental problem?

https://keybase.io/docs/kbfs - "Performance: We've made no performance optimizations yet. There's a lot of low-hanging fruit."