
Keybase's New Key Model - aston
https://keybase.io/blog/keybase-new-key-model
======
po
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.

~~~
mostafah
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.

~~~
mangeletti
What fox? The logo looks a lot more like some sort of a criminal Berenstain
Bear (see [http://www.nelvana.com/content/assets/shows/berenstain-
bears...](http://www.nelvana.com/content/assets/shows/berenstain-
bears/gallery/357/BB006b_SA_02_big.jpg)).

I agree that the logo insinuates that you're probably sneaking around doing
nefarious things, if you're interested in encrypting your messages.

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

~~~
garrettr_
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

~~~
posixplz
PGP may not support ECC, but then again, who the hell uses PGP over GnuPG?

[https://www.gnupg.org/faq/whats-new-
in-2.1.html#ecc](https://www.gnupg.org/faq/whats-new-in-2.1.html#ecc)

------
akerl_
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...](https://github.com/keybase/homebrew-
beta/blob/master/kbstage.rb#L36)

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...](https://github.com/keybase/client-
beta/tree/master/client/go#run-the-service)

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...](https://github.com/keybase/client-
beta/blob/master/client/go/service/main.go)

~~~
cjbprime
(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_
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
It's also aimed at users who don't use gpg.

------
zyxley
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.

~~~
mirimir
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 ;)

------
zokier
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
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
> 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
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.

------
nickpsecurity
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_
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

~~~
grkvlt
> 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 ;(

~~~
on_
> this is the main reason most people (including me) aren't using it.

Most people don't know what PGP/GPG is, probably know less than nothing (have
misconceptions) about encryption, and don't even realize why a service like
keybase.io would be helpful, much less that it exists.

What I love about this community is that there are people like aianus below
who have early access to stuff like this, and being part of this community
will engender them to help you. I like this service because people outside of
this community will get involved after they work out the kinks. People getting
invites are developers and tech-centric people who likely have other keys
anyway and are testdriving the software.

The biggest way forward for keybase would be Facebook or Twitter allowing you
to integrate your key into the service.

> it seems like I've been trying to get an account for years, now ;(

The keybase github account was created 2 years ago on sept 6 ;). Someone below
will likely help you out if you email them.

Thanks aianus. Appreciate the invite.

~~~
nickpsecurity
It's actually a bad idea and parent post is right: they need to open it up to
more people even if still limited or with a warning that features might
change. The reason has to do with their goal of making something usable for
widespread audience. Asking what GPG-loving techies and HN readers think about
usability will not tell you if your grandmaw or average employee will find it
usable. I remember the studies on PGP surprised cryptographers in that what
they thought was understandable (esp icons) were really confusing to end
users.

So, they need to go ahead and get a diverse audience to spot problems early
on. For sure, they should stick to a patient audience that knows they're
helping something evolve rather than using a finished product. Still need to
broaden and diversify it, though. I'd start with the 10,000+ volunteers on
that waiting list.

~~~
on_
I disagree. I believe there strategy is not,

> Asking what GPG-loving techies and HN readers think about usability

Although, many of us do UX or appreciate and can accurately review it, they
want the GPG-loving techies to evaluate their security and software. This
isn't exactly a social network, you can't move fast and break stuff, and just
push flaming builds and iterate. This has to launch to the public with
bulletproof security. This is because in 3 years they want "Log in with
Keybase.io" on every website instead of "Log in with Facebook" and they want
secondary authentication for twitter and facebook to leverage their keys. So
they have to convince people and those companies they have security pretty
well figured out.

I understand where you are coming from and I would like it if they rolled out
quickly. They could maybe even do it tomorrow, I don't actually know but so
far it seems to work well. However, the public isn't really clamoring for this
anyway, because they don't even know what it is. I was even surprised how old
keys were. You can see elon musks e@x.com key from the early 90's on the MIT
keyserver and some are much older than that. Not even everone on HN has keys I
bet, so the public isn't as anxious as you or I might be ;). I hope they
release soon though.

~~~
nickpsecurity
"they want the GPG-loving techies to evaluate their security and software."
"This has to launch to the public with bulletproof security."

How is merely using Keybase.io a security evaluation? It isn't. Security
evaluation is all kinds of activities with specialized skill working on
source, interfaces, debuggers and so on. You do that _in parallel_ with
testing of usability, performance, reliability, and so on. So, they need the
security evaluations but also need users running it through paces for other
reasons. They can and should do both.

"This isn't exactly a social network, you can't move fast and break stuff, and
just push flaming builds and iterate."

Whose asking for that? I believe I said patient, filtered user-base that are
clearly told it is a work in progress given to them for evaluation.

"I understand where you are coming from and I would like it if they rolled out
quickly."

I'm not even asking for that. I'm just saying they need to seriously increase
their user-base and with more non-technical, privacy-focused users. What input
they're receiving before launch needs to be as diverse and representative of
what they'll receive after launch. They can still cap the user count or be
selective. Closed with 10,000+ person backlog or wide open in full production
is a false dilemma. Heck, maybe even a room's worth of people from each likely
demographic, skill level, target platform, and so on. Will help spot many
issues coming from each before production.

"Not even everone on HN has keys I bet, so the public isn't as anxious as you
or I might be ;)"

I should be clear that I'm not factoring in the general public at all: they'll
continue using Facebook Messenger, etc for private communications because it's
cool, convenient, cheap, whatever. I don't waste time trying to push privacy
tech, esp key management, on the public any more past improvements to
infrastructure or tools they already use. Strong security/privacy is and
always was a niche. However, as Keybase's vision realizes, the niche is
potentially larger than techies with GPG or stuff in keyservers: people who
would use it if it was simpler & less technical at interface. So, I advocate
they get more of that audience into their user-base for feedback.

~~~
on_
Sorry mate, I was having a laugh with the social network bit, but I think we
are both just saying the same thing. The product is in Alpha. It isn't ready
yet. I just downloaded it and it says "This product is in Alpha". They will
then move to private Beta then Beta then launch. So I think they will do what
you are asking, but they are further behind.

I guess my point was that they have a really long release cycle because this
is a security project. Regardless, I have 9 invites so I am considering
allocating a few to some non-technical friends now to get their take.

~~~
nickpsecurity
Curious, how did you go from behind 12k people asking for an invite to having
9? I figured aianus got you one but nine is some progress in a short time. ;)

~~~
on_
Chris Coyne (co-founder of keybase.io) seems to send them to new members.
Unless he was on here, which is possible, I have no reason to suspect I
received special treatment. It actually is fairly smart because you can grow
your base by an order of magnitude and if you have set the culture of the
people you invite, the site will blossom that way. I sent you an email to ask
if you want an invite. If you get back to me I will send you one.

------
green7ea
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
"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).

------
phasmantistes
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.

------
david_shaw
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
> "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
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!

------
tty7
wow, please put a link to [https://keybase.io](https://keybase.io) on your
blog header.

~~~
StavrosK
And also add a blog header.

------
mtgx
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
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

------
Corrado
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
Yep; same issue here an hour later.

Google cache:

[http://webcache.googleusercontent.com/search?q=cache:vneH1nu...](http://webcache.googleusercontent.com/search?q=cache:vneH1nuQcSsJ:https://keybase.io/blog/keybase-
new-key-model)

------
akerl_
So what happens to the existing GPG-using folks?

~~~
adrusi
They clarify that PGP support will continue to function as is at the bottom of
the article.

~~~
oconnor663
Also, now you can have multiple PGP keys tied to your account.

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

~~~
malgorithms
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.

~~~
natrius
_> If you remove a key, what's preventing the server from not admitting that?_

Can you point me to somewhere I can read about Keybase's solution to this
problem?

~~~
malgorithms
These 2 docs together will explain it:

[1]
[https://keybase.io/docs/server_security](https://keybase.io/docs/server_security)

[2]
[https://keybase.io/docs/server_security/merkle_root_in_bitco...](https://keybase.io/docs/server_security/merkle_root_in_bitcoin_blockchain)

The tl;dr: Removal statements are signed into a chain of all public
announcements you make (each references the last), and each link also
references the root of the site's merkle tree - a tree which includes
everyone's chain. The root of that tree is written to the bitcoin blockchain
multiple times per day.

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

------
chinathrow
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.

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

------
benwilber0
The real problem is that no one gives a shit

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

~~~
mirimir
Keybase _does not need_ your private key.

