15 ms·

Keybase's New Key Model

187 points by aston 11y ago

david_shaw 11y ago
Woo-hoo! I'm a fan of Keybase (although, I'll admit, I've received barely any encrypted communication from the outside world). The first version of their product did a whole lot to open up secure communication to "the masses," by simplifying strong encryption into an easy-to-use app. I'm glad that the Keybase team decided that they didn't want to stop there. I'm not sure that I'll use the new keying system (my use case isn't very risky), but I do think that a lot of people will. In my opinion, the more people that have access to easily-used crypto, the better.
- malgorithms 11y ago
  > "I'm not sure that I'll use the new keying system (my use case isn't very risky)" To be clear, you'll be using this system automatically if you install Keybase on your phone or desktop. It'll just work, and you'll have a private key on that device. As you add devices, you'll collect keys. If you remove a device, that public key will no longer be a part of your identity. If you want to use PGP on one of those devices, you can. And you can strongly connect it to your other keys, as the graphs in the post show. This should be easier. From a "regular" non-PGP user perspective, you needn't think of this as managing keys, or adopting a more advanced key system. Instead you would just be managing your devices and installing Keybase. That's our hope anyway. (Disclosure: I'm one of the people working on the project - https://keybase.io/chris https://keybase.io/chris - thanks for the kind words about the project)
  - david_shaw 11y ago
    That's awesome -- and thank you for the clarification. I'm primarily a user of the webapp, although I have the CLI application on a server (hence not using mobile stuff, multiple machines, etc). I'm a big fan of your product, and recommend it broadly -- great work so far!
  - deleted 11y ago
    [deleted]
phasmantistes 11y ago
This is fantastic. Thanks, Keybase! I've kept my private key on a single device because that's the easiest way for me to secure it... but it means that I haven't used keybase to actually secure communications much because that device is my nice big linux desktop... not my handy laptop or phone or any of the other devices that I spend more time communicating from. Really looking forward to the Android app.
zokier 11y ago
Doesn't PGP subkeys already essentially solve the problem of requiring shared private key on devices? Its not immediately obvious what the main benefits of their solution are.
- subway 11y ago
  I'd like to know how they plan on dealing with subkeys -- my Keybase key is an ed25519 key kept offline, with a set of RSA subkeys generated directly on a Yubikey. This lets me use my key on an Android device (via Open Keychain), or PC (via GnuPG's smart card interface.) I don't want additional NaCL keys hanging around on 'online' machines outside of a secure element such as a smart card.
  - jmgrosen 11y ago
    > my Keybase key is an ed25519 key Could you explain how you did this? I was under the impression it was impossible because Curve25519 encryption isn't implemented yet.
    - subway 11y ago
      The offline key isn't used for encryption, only signing. In this case, signing the subkeys, which are used for encryption (or auth, or signing). Really not all that different from past days of having a dsa key with an el gamal subkey for encryption.
- oconnor663 11y ago
  I don't think it's possible to issue subkeys that can create further subkeys, or revoke each other. You have to use the master key for that, which means going back to your safety deposit box or the center of the Earth or wherever it is you keep it. We don't want to make people do that, so we can't represent your set of devices as subkeys of a single PGP key.
- e12e 11y ago
  I wonder about this too. I'm not even sure what this feature is supposed to do? As best I can gather, this ties signing to keybase.io (which is anchored in a GPG-key). But it's unclear to me how this is an improvement for users. If you sign anything with a nacl sub-key, that can't be verified with gpg? It's not even clear if this will work off-line, when keybase is down, when keybase have revoked your account...? > Technically, though, this is not a normal 2fa: the devices will share a secret with just each other. This is exactly 2fa: two devices sharing a secret? Normally your idp and your TOTP app/token share a secret, now two of your devices share a secret? I very much welcome someone hammering out a standard equivalent to GPG, but based on NaCL, that is: have a master key (off-line), have a private-sub-key (on-line, protected by smart card/pass phrase), enable further sub-keys -- and a companion tool (set) for verifying up the chain (like gpg2 --verify file.asc, but with file.asc being backed by a (device) sub-key, signed by the private key, signed by the "master" off-line key -- and allow for revoking "from this key and down" (eg: I lost my phone, revoke phone-key, my laptop got hacked, revoke my sub-key, and all device keys...)). But I'm not sure if that is what keybase is trying to do? I'm not even sure if it really makes sense to keep backwards comparability with GPG -- the main thing would probably be to be compatible with GPG agent and smartcards. For most everything else, I think a new standard would be a good thing. Perhaps with some kind of bridge, for easier transition (eg: nacl-gpg --verify file.asc, which gives similar output/return-codes to gpg, while file.asc can be signed by a "nacl-key" trusted by a gpg key. But the complexity would probably make for a less secure system until everyone could just move on to the new standard).
zyxley 11y ago
So... there are no actual links on this page to anything that describes Keybase. The only way to get directly to the site homepage is to edit the URL. This is pretty annoying if you're somebody who doesn't already know what Keybase actually is.
- nickpsecurity 11y ago
  That's a good point. They should put a link up top or something so people that stumble on this can get to main site. It's a best practice for a reason. The link to the blog in general being at the bottom is strange, too.
- on_ 11y ago
  I think blogs really overdo the amount of links and nav they have (this trend is changing to minamalist now) but this is a bit too minimalist. They have a tiny footer with a link back to the blog, so they do have it, but a person curious what keybase.io is, would likely want to head to the homepage before reading a company update top to bottom to find that link.
- unethical_ban 11y ago
  I notice many blogs and wikis have this problem. It's like they have a separate piece of software for that component of their site, and don't bother to integrate it with their main page.
- mirimir 11y ago
  Well, I know what Keybase is. But the page was so empty looking that I stopped reading, and checked out Noscript and Privacy Badger for blocked stuff and errors ;)
nickpsecurity 11y ago
I don't use Keybase yet as I haven't evaluated the assurance and usually don't rely on VC-funded, startup tech for critical stuff. That said, I've enjoyed the Keybase articles so far and this is no exception. Way I see it, companies like them will keep experimenting until they figure out what approaches work in terms of usability, adoption, and potential for strong security. And then experienced, security engineers can build a stronger version of it. :) Look forward to seeing what they brainstorm next.
- on_ 11y ago
  i think keybase (or something like it) is going to be huge. Instead of email, sites like reddit and HN will use PGP keys for identity instead of email. I don't use keybase because 1) I'm behind 12K people for their private beta 2) I know how to run gpg --gen-key
  - aianus 11y ago
    If you'd like a invite, shoot me an email at aianus@coinbase.com and I'll send you one.
    - on_ 11y ago
      Brilliant. Sent. Thanks a 10^6.
    - aianus 11y ago
      All out :)
  - grkvlt 11y ago
    > I don't use keybase because [...] I'm behind 12K people for their private beta Sadly, this is the main reason most people (including me) aren't using it. I'd love to try it out, but until I can get a log in, I'm just going to ignore it. They are throwing away a lot of good-will by making these announcements, then when users go to the site they get turned away because they aren't one of the blessed few with an invite. If I don't get access soon, I'm going to file them under 'ignore', since it seems like I've been trying to get an account for years, now ;(
aianus 11y ago
Can somebody explain the difference between NaCl and PGP and why I want device-specific NaCl keys instead of device-specific PGP keys?
- adrusi 11y ago
  Well traditional PGP key-management software expects exactly one key per identity, so using per-device PGP keys would establish each device as a separate identity. This is not what you want. I'm not an expert, but I'm sure there are other good reasons.
  - pflanze 11y ago
    The user identifier for PGP keys is the User-ID (name and email address), and you can have any number of PGP keys for one. GnuPG lets you search for a User-ID (or part thereof) with --list-key, the same is true for key servers. Each key can sign each other's identifier. What do you think is missing?
- garrettr_ 11y ago
  I didn't design this so I can't say for certain, but from reading their post there are a couple of benefits that NaCL confers over PGP for generating per-device keys. The most important benefit is probably that NaCL keys are 256-bit keys based on ECC (specifically, Curve25519), which means these keys are stronger, faster, and actually more secure than the strongest keys commonly used in PGP (4096-bit RSA keys). Critically, they are much smaller and therefore easier to communicate between people/devices. While their ideal workflow is to communicate keys by scanning QR codes, they currently need an alternative workflow to communicate keys between desktops (and will always need an alternative for users who can't scan QR codes for whatever reason). The "Paper keys" section of the blog post discusses this at length, and shows an example of a Paper Key: "death punch correct staple battery horse clearly cherry picked words yeah moo car lisp" They are probably generating this (Diceware-esque) string by splitting the 256-bit key into n-bit segments, using each n-bit segment as an index into an array of words, and then joining the words to form a "sentence" that encodes the value of the key. 14 words is already pretty unwieldy, as they acknowledge in the blog post. Imagine how bad it would be if you had to encode 4096 bits instead of just 256! That was probably the most important motivation for Keybase to use them. Other motivations may have included: * ECC is generally considered more future-proof than RSA * NaCL is a small library and therefore is probably easier to incorporate into a variety of clients rather than the behemoth that is GPG/libgcrypt. * NaCL is the new hotness, PGP is old and busted
DannoHung 11y ago
I don't really understand key base. Is there a more elaborate explanation of how it works somewhere?
- malgorithms 11y ago
  The simple idea is that it's a directory mapping public keys to social accounts. If I know you as a Twitter user, I might want to send you an encrypted message. Or if I get a message from you that's signed, I might want to know that you're a certain Hacker News user. If I download some source code, I'd like to know it was signed by someone who has Github account X, and write access on example.com. And so on. Historically, a few people using PGP would do this identity mapping, at least in one direction, by posting a PGP fingerprint (of their public key) on their, say, Twitter profile . Of course, this only went in one direction. To achieve a bidirectional proof, they would also have to post a signed statement going in the other direction, too, stating they were in fact that twitter user. (Otherwise you couldn't start with a message and conclude which Twitter user sent it - multiple people could claim this.) Keybase started as a hobby project to make these posts structured and formal for PGP users. We just wanted to make this kind of thing easier, so we made a directory to hold the signatures going in the other direction, and a reference client that would look up these announcements and verify them. The other specific advancement is that these signatures have been put into a data structure designed to prevent the server from lying by omission or forking - a big problem that exists with historic key servers. If you remove a key, what's preventing the server from not admitting that? Or what's preventing the server from giving Alice and Bob a difference experience from Charlie and Diane? Anyway, that was the first idea behind Keybase. To make a better directory and walk people through these proofs. What we realized - and what has gotten us both (a) extremely smart developers to join us, and (b) funding - is that there are deeper problems beyond the identity establishment....problems that can be solved in 2015. Those two problems are (1) pretty sucky clients for public key crypto (at least from the perspective of non-programmers), and (2) key management issues. The first is something we have experience with, as our team has worked on a lot of successful projects. And let's be clear, lots of teams could solve this, if given the resources. The second is something we feel can finally be solved thanks to mobile phones. Phones and watches and other small devices allow you to provision new keys easily, because 2 devices can be brought together. That wasn't easy in the past. All this is now possible without understanding what a key is. Or worrying about how to store and move one around safely. That's the new goal: actual crypto clients. For signing, verifying, encrypting, decrypting, and sharing. You can read the front page of keybase.io for some more info, but it's somewhat out of date and talks mostly about PGP. This will change when our clients are further along and we're seeking more beta testers.
akerl_ 11y ago
So what happens to the existing GPG-using folks?
- adrusi 11y ago
  They clarify that PGP support will continue to function as is at the bottom of the article.
  - oconnor663 11y ago
    Also, now you can have multiple PGP keys tied to your account.
akerl_ 11y ago
So I just noticed that the new client beta installs a launchd service when installed via homebrew: https://github.com/keybase/homebrew-beta/blob/master/kbstage.rb#L36 https://github.com/keybase/homebrew-beta/blob/master/kbstage... Digging into the code now, anybody know what this is for / why it's silently adding that? EDIT: so, looks like it adds a launchd file to run `keybase service`, which is helpfully described here: https://github.com/keybase/client-beta/tree/master/client/go#run-the-service https://github.com/keybase/client-beta/tree/master/client/go... This seems to do all kinds of things, including running an RPC server and interacting with keychains: https://github.com/keybase/client-beta/blob/master/client/go/service/main.go https://github.com/keybase/client-beta/blob/master/client/go...
- cjbprime 11y ago
  (Hi, I work at Keybase!) There's a document describing this client/service split here: https://keybase.io/docs/client/client_architecture https://keybase.io/docs/client/client_architecture
  - akerl_ 11y ago
    So the existing client works just fine without a long-running service and interacts with my gpg-agent to handle my passphrase. As a user, what does this new keybase service get me vs just letting the already persistent gpg-agent handle things?
    - grey-area 11y ago
      It's also aimed at users who don't use gpg.
  - mrsteveman1 11y ago
    Sounds a bit like gpg-agent. Do you have plans to support OpenPGPCard devices directly?
mtgx 11y ago
This reminds me - is Google's End-to-End still going somewhere or has Google "virtually killed it" (by not caring about it anymore as they do with many of their products)? Yahoo's CISO promised to implement it for Yahoo, too, but I think the guy who promised that left the company.
- darkr 11y ago
  Seems to still be receiving commits as of a few days ago > https://github.com/google/end-to-end https://github.com/google/end-to-end I was waiting on smartcard support in that project myself
tty7 11y ago
wow, please put a link to https://keybase.io https://keybase.io on your blog header.
- StavrosK 11y ago
  And also add a blog header.
hydandata 11y ago
I have 9 invites and none of my friends want them. If you want one let me know @hydandata.
po 11y ago
Since the keybase people are probably here reading, can I make a suggestion? Please change your logo from a shifty-looking character to something that inspires more confidence. I actually think the character in the logo is cool and I love your artwork but I just think the logo sends the wrong message. Google Chrome's private browsing mode does the same thing... Identity management and encryption should strive to be associated with concepts of strength, integrity, legitimacy, trust, cleanliness and safety. There is nothing shady about it and we shouldn't need a guy in a trench coat to represent the idea that we should be able to confirm that our friends who are communicating with us are who they say they are and not imposters. Let's focus more on the trust part and less on the sleuthing in the dark part. Sorry, just my $0.02... I only tell you because I want you to succeed.
- devit 11y ago
  I vote for an angel holding a key (to be drawn using a fantasy/videogame art style, not a religious one).
  - twic 11y ago
    How about a snowflake made out of keys? This is why you should never let hackers design a logo.
- mostafah 11y ago
  What’s wrong with the fox? I like their logo. A lot of big, mainstream brands have fun-looking mascots. They may have to redesign and improve it as they grow, like everybody does, but I don’t see it necessary to replace it completely.
  - po 11y ago
    Yeah I like it too... as a character it's fun and silly and everything I like about being a developer. What I don't like about it is exactly as I said: too shifty looking. As you say, it's time to redesign and improve it. It doesn't have to go away and it could remain the company mascot if they wanted. I would hope it does. (also, I'm not sure it's a fox? is it?) I actually feel a bit bad saying it and sad this is the top comment right now since it's a fairly minor point and way less important than what they are doing. I just think you have one chance to make a first impression about what your company stands for and the logo is a big part of that. In fact it's one of the parts that is most likely to end up representing your brand on other sites. Looking at their site, I think they care about that a lot and put a lot of effort into it so I hope this comes off in the best possible way.
benwilber0 11y ago
The real problem is that no one gives a shit
benwilber0 11y ago
Keybase has no altruistic incentive to broker safe PKI. They're just another for-profit-scammer-of-your-private-key
- mirimir 11y ago
  Keybase does not need your private key.
Corrado 11y ago
It looks like we knocked keybase.io off the net; all I'm getting now are 502 Nginx errors. Does anyone have a mirror of this blog post?
- nerdy 11y ago
  Yep; same issue here an hour later. Google cache: http://webcache.googleusercontent.com/search?q=cache:vneH1nuQcSsJ:https://keybase.io/blog/keybase-new-key-model http://webcache.googleusercontent.com/search?q=cache:vneH1nu...
- akalin 11y ago
  It should be back up now.
deleted 11y ago
[deleted]
jaysoncena 11y ago
probably off topic but what library was used to render the graph?
chinathrow 11y ago
I've said it before and I say it again: - For security focused websites, it's a no go to include 3rd party domains for any content. The fine folks at keybase responded well last time and moved the font files to their own servers (thanks!). This time, they host images at S3 and therefore leak metadata about their visitors directly to Amazon.
green7ea 11y ago
That's really good news and I'm really excited about keybase's future. I'm curious though why they chose to use NaCl instead of libsodium [1]. I was thinking of doing a crypto app a while back and did some research and libsodium seems to be a more portable and recent (removed deprecated code) version of NaCl by the folks at dnscrypt. Maybe I missed something in my research? [1] https://github.com/jedisct1/libsodium https://github.com/jedisct1/libsodium
- catwell 11y ago
  "NaCL key" is a generic term, you can probably use them with libsodium, like you can use "PGP keys" with GPG. By the way, libsodium has the same maintainer than dnscrypt (and Pure-FTPd) but he does not work for OpenDNS anymore (afaik he works for OVH, but libsodium is his personal project).

187 points by aston 11y ago

Woo-hoo! I'm a fan of Keybase (although, I'll admit, I've received barely any encrypted communication from the outside world). The first version of their product did a whole lot to open up secure communication to "the masses," by simplifying strong encryption into an easy-to-use app. I'm glad that the Keybase team decided that they didn't want to stop there. I'm not sure that I'll use the new keying system (my use case isn't very risky), but I do think that a lot of people will. In my opinion, the more people that have access to easily-used crypto, the better.

malgorithms 11y ago
> "I'm not sure that I'll use the new keying system (my use case isn't very risky)" To be clear, you'll be using this system automatically if you install Keybase on your phone or desktop. It'll just work, and you'll have a private key on that device. As you add devices, you'll collect keys. If you remove a device, that public key will no longer be a part of your identity. If you want to use PGP on one of those devices, you can. And you can strongly connect it to your other keys, as the graphs in the post show. This should be easier. From a "regular" non-PGP user perspective, you needn't think of this as managing keys, or adopting a more advanced key system. Instead you would just be managing your devices and installing Keybase. That's our hope anyway. (Disclosure: I'm one of the people working on the project - https://keybase.io/chris https://keybase.io/chris - thanks for the kind words about the project)
- david_shaw 11y ago
  That's awesome -- and thank you for the clarification. I'm primarily a user of the webapp, although I have the CLI application on a server (hence not using mobile stuff, multiple machines, etc). I'm a big fan of your product, and recommend it broadly -- great work so far!
- deleted 11y ago
  [deleted]

phasmantistes 11y ago

This is fantastic. Thanks, Keybase! I've kept my private key on a single device because that's the easiest way for me to secure it... but it means that I haven't used keybase to actually secure communications much because that device is my nice big linux desktop... not my handy laptop or phone or any of the other devices that I spend more time communicating from. Really looking forward to the Android app.

zokier 11y ago

Doesn't PGP subkeys already essentially solve the problem of requiring shared private key on devices? Its not immediately obvious what the main benefits of their solution are.

subway 11y ago
I'd like to know how they plan on dealing with subkeys -- my Keybase key is an ed25519 key kept offline, with a set of RSA subkeys generated directly on a Yubikey. This lets me use my key on an Android device (via Open Keychain), or PC (via GnuPG's smart card interface.) I don't want additional NaCL keys hanging around on 'online' machines outside of a secure element such as a smart card.
- jmgrosen 11y ago
  > my Keybase key is an ed25519 key Could you explain how you did this? I was under the impression it was impossible because Curve25519 encryption isn't implemented yet.
  - subway 11y ago
    The offline key isn't used for encryption, only signing. In this case, signing the subkeys, which are used for encryption (or auth, or signing). Really not all that different from past days of having a dsa key with an el gamal subkey for encryption.
oconnor663 11y ago
I don't think it's possible to issue subkeys that can create further subkeys, or revoke each other. You have to use the master key for that, which means going back to your safety deposit box or the center of the Earth or wherever it is you keep it. We don't want to make people do that, so we can't represent your set of devices as subkeys of a single PGP key.
e12e 11y ago
I wonder about this too. I'm not even sure what this feature is supposed to do? As best I can gather, this ties signing to keybase.io (which is anchored in a GPG-key). But it's unclear to me how this is an improvement for users. If you sign anything with a nacl sub-key, that can't be verified with gpg? It's not even clear if this will work off-line, when keybase is down, when keybase have revoked your account...? > Technically, though, this is not a normal 2fa: the devices will share a secret with just each other. This is exactly 2fa: two devices sharing a secret? Normally your idp and your TOTP app/token share a secret, now two of your devices share a secret? I very much welcome someone hammering out a standard equivalent to GPG, but based on NaCL, that is: have a master key (off-line), have a private-sub-key (on-line, protected by smart card/pass phrase), enable further sub-keys -- and a companion tool (set) for verifying up the chain (like gpg2 --verify file.asc, but with file.asc being backed by a (device) sub-key, signed by the private key, signed by the "master" off-line key -- and allow for revoking "from this key and down" (eg: I lost my phone, revoke phone-key, my laptop got hacked, revoke my sub-key, and all device keys...)). But I'm not sure if that is what keybase is trying to do? I'm not even sure if it really makes sense to keep backwards comparability with GPG -- the main thing would probably be to be compatible with GPG agent and smartcards. For most everything else, I think a new standard would be a good thing. Perhaps with some kind of bridge, for easier transition (eg: nacl-gpg --verify file.asc, which gives similar output/return-codes to gpg, while file.asc can be signed by a "nacl-key" trusted by a gpg key. But the complexity would probably make for a less secure system until everyone could just move on to the new standard).

zyxley 11y ago

So... there are no actual links on this page to anything that describes Keybase. The only way to get directly to the site homepage is to edit the URL. This is pretty annoying if you're somebody who doesn't already know what Keybase actually is.

nickpsecurity 11y ago
That's a good point. They should put a link up top or something so people that stumble on this can get to main site. It's a best practice for a reason. The link to the blog in general being at the bottom is strange, too.
on_ 11y ago
I think blogs really overdo the amount of links and nav they have (this trend is changing to minamalist now) but this is a bit too minimalist. They have a tiny footer with a link back to the blog, so they do have it, but a person curious what keybase.io is, would likely want to head to the homepage before reading a company update top to bottom to find that link.
unethical_ban 11y ago
I notice many blogs and wikis have this problem. It's like they have a separate piece of software for that component of their site, and don't bother to integrate it with their main page.
mirimir 11y ago
Well, I know what Keybase is. But the page was so empty looking that I stopped reading, and checked out Noscript and Privacy Badger for blocked stuff and errors ;)

nickpsecurity 11y ago

I don't use Keybase yet as I haven't evaluated the assurance and usually don't rely on VC-funded, startup tech for critical stuff. That said, I've enjoyed the Keybase articles so far and this is no exception. Way I see it, companies like them will keep experimenting until they figure out what approaches work in terms of usability, adoption, and potential for strong security. And then experienced, security engineers can build a stronger version of it. :) Look forward to seeing what they brainstorm next.

on_ 11y ago
i think keybase (or something like it) is going to be huge. Instead of email, sites like reddit and HN will use PGP keys for identity instead of email. I don't use keybase because 1) I'm behind 12K people for their private beta 2) I know how to run gpg --gen-key
- aianus 11y ago
  If you'd like a invite, shoot me an email at aianus@coinbase.com and I'll send you one.
  - on_ 11y ago
    Brilliant. Sent. Thanks a 10^6.
  - aianus 11y ago
    All out :)
- grkvlt 11y ago
  > I don't use keybase because [...] I'm behind 12K people for their private beta Sadly, this is the main reason most people (including me) aren't using it. I'd love to try it out, but until I can get a log in, I'm just going to ignore it. They are throwing away a lot of good-will by making these announcements, then when users go to the site they get turned away because they aren't one of the blessed few with an invite. If I don't get access soon, I'm going to file them under 'ignore', since it seems like I've been trying to get an account for years, now ;(

aianus 11y ago

Can somebody explain the difference between NaCl and PGP and why I want device-specific NaCl keys instead of device-specific PGP keys?

adrusi 11y ago
Well traditional PGP key-management software expects exactly one key per identity, so using per-device PGP keys would establish each device as a separate identity. This is not what you want. I'm not an expert, but I'm sure there are other good reasons.
- pflanze 11y ago
  The user identifier for PGP keys is the User-ID (name and email address), and you can have any number of PGP keys for one. GnuPG lets you search for a User-ID (or part thereof) with --list-key, the same is true for key servers. Each key can sign each other's identifier. What do you think is missing?
garrettr_ 11y ago
I didn't design this so I can't say for certain, but from reading their post there are a couple of benefits that NaCL confers over PGP for generating per-device keys. The most important benefit is probably that NaCL keys are 256-bit keys based on ECC (specifically, Curve25519), which means these keys are stronger, faster, and actually more secure than the strongest keys commonly used in PGP (4096-bit RSA keys). Critically, they are much smaller and therefore easier to communicate between people/devices. While their ideal workflow is to communicate keys by scanning QR codes, they currently need an alternative workflow to communicate keys between desktops (and will always need an alternative for users who can't scan QR codes for whatever reason). The "Paper keys" section of the blog post discusses this at length, and shows an example of a Paper Key: "death punch correct staple battery horse clearly cherry picked words yeah moo car lisp" They are probably generating this (Diceware-esque) string by splitting the 256-bit key into n-bit segments, using each n-bit segment as an index into an array of words, and then joining the words to form a "sentence" that encodes the value of the key. 14 words is already pretty unwieldy, as they acknowledge in the blog post. Imagine how bad it would be if you had to encode 4096 bits instead of just 256! That was probably the most important motivation for Keybase to use them. Other motivations may have included: * ECC is generally considered more future-proof than RSA * NaCL is a small library and therefore is probably easier to incorporate into a variety of clients rather than the behemoth that is GPG/libgcrypt. * NaCL is the new hotness, PGP is old and busted

DannoHung 11y ago

I don't really understand key base. Is there a more elaborate explanation of how it works somewhere?

malgorithms 11y ago
The simple idea is that it's a directory mapping public keys to social accounts. If I know you as a Twitter user, I might want to send you an encrypted message. Or if I get a message from you that's signed, I might want to know that you're a certain Hacker News user. If I download some source code, I'd like to know it was signed by someone who has Github account X, and write access on example.com. And so on. Historically, a few people using PGP would do this identity mapping, at least in one direction, by posting a PGP fingerprint (of their public key) on their, say, Twitter profile . Of course, this only went in one direction. To achieve a bidirectional proof, they would also have to post a signed statement going in the other direction, too, stating they were in fact that twitter user. (Otherwise you couldn't start with a message and conclude which Twitter user sent it - multiple people could claim this.) Keybase started as a hobby project to make these posts structured and formal for PGP users. We just wanted to make this kind of thing easier, so we made a directory to hold the signatures going in the other direction, and a reference client that would look up these announcements and verify them. The other specific advancement is that these signatures have been put into a data structure designed to prevent the server from lying by omission or forking - a big problem that exists with historic key servers. If you remove a key, what's preventing the server from not admitting that? Or what's preventing the server from giving Alice and Bob a difference experience from Charlie and Diane? Anyway, that was the first idea behind Keybase. To make a better directory and walk people through these proofs. What we realized - and what has gotten us both (a) extremely smart developers to join us, and (b) funding - is that there are deeper problems beyond the identity establishment....problems that can be solved in 2015. Those two problems are (1) pretty sucky clients for public key crypto (at least from the perspective of non-programmers), and (2) key management issues. The first is something we have experience with, as our team has worked on a lot of successful projects. And let's be clear, lots of teams could solve this, if given the resources. The second is something we feel can finally be solved thanks to mobile phones. Phones and watches and other small devices allow you to provision new keys easily, because 2 devices can be brought together. That wasn't easy in the past. All this is now possible without understanding what a key is. Or worrying about how to store and move one around safely. That's the new goal: actual crypto clients. For signing, verifying, encrypting, decrypting, and sharing. You can read the front page of keybase.io for some more info, but it's somewhat out of date and talks mostly about PGP. This will change when our clients are further along and we're seeking more beta testers.

akerl_ 11y ago

So what happens to the existing GPG-using folks?

adrusi 11y ago
They clarify that PGP support will continue to function as is at the bottom of the article.
- oconnor663 11y ago
  Also, now you can have multiple PGP keys tied to your account.

akerl_ 11y ago

So I just noticed that the new client beta installs a launchd service when installed via homebrew: https://github.com/keybase/homebrew-beta/blob/master/kbstage.rb#L36 https://github.com/keybase/homebrew-beta/blob/master/kbstage... Digging into the code now, anybody know what this is for / why it's silently adding that? EDIT: so, looks like it adds a launchd file to run `keybase service`, which is helpfully described here: https://github.com/keybase/client-beta/tree/master/client/go#run-the-service https://github.com/keybase/client-beta/tree/master/client/go... This seems to do all kinds of things, including running an RPC server and interacting with keychains: https://github.com/keybase/client-beta/blob/master/client/go/service/main.go https://github.com/keybase/client-beta/blob/master/client/go...

cjbprime 11y ago
(Hi, I work at Keybase!) There's a document describing this client/service split here: https://keybase.io/docs/client/client_architecture https://keybase.io/docs/client/client_architecture
- akerl_ 11y ago
  So the existing client works just fine without a long-running service and interacts with my gpg-agent to handle my passphrase. As a user, what does this new keybase service get me vs just letting the already persistent gpg-agent handle things?
  - grey-area 11y ago
    It's also aimed at users who don't use gpg.
- mrsteveman1 11y ago
  Sounds a bit like gpg-agent. Do you have plans to support OpenPGPCard devices directly?

mtgx 11y ago

This reminds me - is Google's End-to-End still going somewhere or has Google "virtually killed it" (by not caring about it anymore as they do with many of their products)? Yahoo's CISO promised to implement it for Yahoo, too, but I think the guy who promised that left the company.

darkr 11y ago
Seems to still be receiving commits as of a few days ago > https://github.com/google/end-to-end https://github.com/google/end-to-end I was waiting on smartcard support in that project myself

tty7 11y ago

wow, please put a link to https://keybase.io https://keybase.io on your blog header.

StavrosK 11y ago
And also add a blog header.

hydandata 11y ago

I have 9 invites and none of my friends want them. If you want one let me know @hydandata.

po 11y ago

Since the keybase people are probably here reading, can I make a suggestion? Please change your logo from a shifty-looking character to something that inspires more confidence. I actually think the character in the logo is cool and I love your artwork but I just think the logo sends the wrong message. Google Chrome's private browsing mode does the same thing... Identity management and encryption should strive to be associated with concepts of strength, integrity, legitimacy, trust, cleanliness and safety. There is nothing shady about it and we shouldn't need a guy in a trench coat to represent the idea that we should be able to confirm that our friends who are communicating with us are who they say they are and not imposters. Let's focus more on the trust part and less on the sleuthing in the dark part. Sorry, just my $0.02... I only tell you because I want you to succeed.

devit 11y ago
I vote for an angel holding a key (to be drawn using a fantasy/videogame art style, not a religious one).
- twic 11y ago
  How about a snowflake made out of keys? This is why you should never let hackers design a logo.
mostafah 11y ago
What’s wrong with the fox? I like their logo. A lot of big, mainstream brands have fun-looking mascots. They may have to redesign and improve it as they grow, like everybody does, but I don’t see it necessary to replace it completely.
- po 11y ago
  Yeah I like it too... as a character it's fun and silly and everything I like about being a developer. What I don't like about it is exactly as I said: too shifty looking. As you say, it's time to redesign and improve it. It doesn't have to go away and it could remain the company mascot if they wanted. I would hope it does. (also, I'm not sure it's a fox? is it?) I actually feel a bit bad saying it and sad this is the top comment right now since it's a fairly minor point and way less important than what they are doing. I just think you have one chance to make a first impression about what your company stands for and the logo is a big part of that. In fact it's one of the parts that is most likely to end up representing your brand on other sites. Looking at their site, I think they care about that a lot and put a lot of effort into it so I hope this comes off in the best possible way.

benwilber0 11y ago

The real problem is that no one gives a shit

benwilber0 11y ago

Keybase has no altruistic incentive to broker safe PKI. They're just another for-profit-scammer-of-your-private-key

mirimir 11y ago
Keybase does not need your private key.

Corrado 11y ago

It looks like we knocked keybase.io off the net; all I'm getting now are 502 Nginx errors. Does anyone have a mirror of this blog post?

nerdy 11y ago
Yep; same issue here an hour later. Google cache: http://webcache.googleusercontent.com/search?q=cache:vneH1nuQcSsJ:https://keybase.io/blog/keybase-new-key-model http://webcache.googleusercontent.com/search?q=cache:vneH1nu...
akalin 11y ago
It should be back up now.

deleted 11y ago

[deleted]

jaysoncena 11y ago

probably off topic but what library was used to render the graph?

chinathrow 11y ago

I've said it before and I say it again: - For security focused websites, it's a no go to include 3rd party domains for any content. The fine folks at keybase responded well last time and moved the font files to their own servers (thanks!). This time, they host images at S3 and therefore leak metadata about their visitors directly to Amazon.

green7ea 11y ago

That's really good news and I'm really excited about keybase's future. I'm curious though why they chose to use NaCl instead of libsodium [1]. I was thinking of doing a crypto app a while back and did some research and libsodium seems to be a more portable and recent (removed deprecated code) version of NaCl by the folks at dnscrypt. Maybe I missed something in my research? [1] https://github.com/jedisct1/libsodium https://github.com/jedisct1/libsodium

catwell 11y ago
"NaCL key" is a generic term, you can probably use them with libsodium, like you can use "PGP keys" with GPG. By the way, libsodium has the same maintainer than dnscrypt (and Pure-FTPd) but he does not work for OpenDNS anymore (afaik he works for OVH, but libsodium is his personal project).