Hacker News Reader

Comment by simias | Hacker News Reader

So, I'm probably missing something but since keybase is built around PGP I assumed that the files I put in my private kbfs would be encrypted with it.

I use a GnuPG "smartcard" (a yubikey) so I'm certain that keybase has no direct access to my private key.

So I've tried "echo test > /keybase/private/simias/secret.txt"

So far it seems to work, the file is here and I can read it.

Then I shutdown keybase, make sure nothing is running and /keybase is unmounted, remove my yubikey and run_keybase again:

    cat /keybase/private/simias/secret.txt
    test

So, what am I missing?

View on HN

keybase uses your gpg key more as a _bootstrap_ to prove your identity, and to then sign your _keybase key_ (which isn't gpg as far as I could tell from the spec).

e.g. you can see I used my GPG key to sign all of my proofs (proving identity), and to also sign my keybase keys which then have signed other keybase keys:

https://keybase.io/travisby/graph

We can view yours at https://keybase.io/simias/graph .

Your device still has worked-key on it which is decrypting secret.txt for you.

Aaah, okay, I actually do remember about that worked-key now. That makes sense.

But then the problem that I have with that is this worked-key is a lot less secure than my PGP key on a hardware token. What I'd like would be for keybase to make those keys depend on my PGP key, for instance by decrypting them at the beginning of each session.

I'm not sure I get the point of these device keys to be honest. Why not simply generate a new key every time one is needed, and then sign and encrypt it with my PGP key?

After all that's basically how basic PGP encryption works, it's encrypted with some symmetric cipher using a random key and then this key is encrypted with the assymetric cipher (sever times if there are several recipients). Nobody has to worry about those "intermediate" throw-away keys, they're just stored alongside the ciphertext.

Most people don't do what you are doing with PGP. In other words you are not in the demographic they are targeting. For their target demographic (people who don't use crypto, or use it poorly), what they are doing is much better than what the people have now.

How so? I don't really get the point of these device keys to be honest.

If anything it seems more complicated than what I'm proposing. People who don't use crypto will probably let keybase manage their private keys (at least at first) so this could be handled transparently.

I mean, you could turn it the other way around. If this system is confusing and unintuitive for somebody like me who is familiar with the details of asymmetric cryptography, how are less technical users supposed to figure it out and understand the trust model?

I doubt the average person on the street would understand what https://keybase.io/travisby/graph means.

The point of a device key is that you can revoke such a key in the event it gets lost and not have people accidentally use it to send you secrets (assuming they use keybase online / are up to date )

But you could do this even if those keys were encrypted with the master PGP key.

I don't have any issues with using sub-keys, it's a very good idea actually, for the reason you mention. I just wish I had the option to tell keybase "never store those keys in cleartext, always encrypt them with the master key". Then it would ask be to decrypt the keys on startup and everybody would be happy (well, at least I would be).

The point of the device keys is that you don't need a PGP key at all. PGP and carrying around a master key securely everywhere is unnecessarily complex for most people. I don't use PGP at all, but I can still use keybase to do encryption/decryption seamlessly across multiple devices which is great.

I was very confused about this as well. I setup an account on my computer a few weeks ago with my yubikey, and since then I have reset my computer, so I decided to install keybase again. Unfortunately it asked for me to approve the new device from an existing one, and didn't offer the option to use my yubikey instead.

I have since emailed support, and they clarified that they don't support yubikeys as the auth layer since there aren't enough users with them for them to justify this work, which is understandable, but I have to say it was pretty confusing.

Reply on news.ycombinator.com