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.
I agree that the logo insinuates that you're probably sneaking around doing nefarious things, if you're interested in encrypting your messages.
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.
(get it, it's a key-bass ... whew)
This is why you should never let hackers design a logo.
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
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...
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...
There's a document describing this client/service split here: https://keybase.io/docs/client/client_architecture
Do you have plans to support OpenPGPCard devices directly?
This is pretty annoying if you're somebody who doesn't already know what Keybase actually is.
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.
Could you explain how you did this? I was under the impression it was impossible because Curve25519 encryption isn't implemented yet.
Really not all that different from past days of having a dsa key with an el gamal subkey for encryption.
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).
Look forward to seeing what they brainstorm next.
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 ;(
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.
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.
> 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 email@example.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.
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.
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.
I kind of got that. Picturing "move fast and break stuff" applied to security would be a hilarious concept. So long as it was the competition doing it. :)
"Regardless, I have 9 invites so I am considering allocating a few to some non-technical friends now to get their take."
Now that's a good idea. Might help so long as they're the kind of people that go through extra trouble for privacy or control of their data. You'll know it's the case if they ask "what is a" or "how do you" on something everyone assumed was obvious. If that moment doesn't come, the UX team was really good. ;)
Awesome, I brought this up last week:
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).
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.
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.
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 - thanks for the kind words about the project)
I'm a big fan of your product, and recommend it broadly -- great work so far!
I was waiting on smartcard support in that project myself
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.
Can you point me to somewhere I can read about Keybase's solution to this problem?
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.
- 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.