malgorithms

Blog author from Keybase here. Always game for a Hacker News discussion!

There's a subtle point I cut from my post for simplicity reasons, but which feels perfect for HN. I've been convinced by Mazières and the Stellar team that the classic "blockchain" works great for native tokens but is extremely dangerous for anything with counterparty redemption. For example, imagine the shitshow after a truly contentious fork, if there are tokens which are supposed to be redeemable with a counterparty.

Let's say Deutsche Bank had put €1 billion into colored coins on Bitcoin. Suddenly, after a fork (e.g. bitcoin vs. bitcoin cash), there would be €2 billion IOU's in the wild. The people on each side of that fork would not roll over and die, and it's not simple to say "Oh, whoever Deutsche picks wins." Or even "Whoever has the strongest chain wins." I have a hard time imagining a company would ever take that risk. I worry big companies would never dare to put anything real-world redeemable directly onto, say, Bitcoin or Ethereum, for this reason. They'd just get sued over and over again.

The Stellar federated consensus story (HN debates about SCP below [1][2]) has Deutsche Bank as an actual player on the network. If you want DB redemptions then you would include them in your trust lines / quorum slices, and if Stellar fell apart and became partitioned, you would stay on DB's side. All said, it seems significantly faster and more stable for cryptocurrency-to-real-world mappings, both for the consumer and counterparty.

Fun discussions:

[1] https://news.ycombinator.com/item?id=9341687 -- of particular note, because it has David Mazières, Vitalik Buterin, and Greg Maxwell all weighing in.

[2] https://news.ycombinator.com/item?id=16125920

Actually, heck, to illustrate all this, I just made a team called `hners`, for "anyone who loves Hacker News." It's an open team. You can join straight from my profile in the Keybase app, or by running `keybase team join hners` in your terminal. Come say hi.

[edit: switched to team name hners]

Oh cool - wasn't really expecting to see this one on HN! The changes here are all a result of "iterating" on our product. Since we work in cryptography, it's not usually the case we can move fast. But this mini-blog post outlined some quick changes we could make.

Stuff we learned from testers:

(1) In many ways, Keybase's chat is like Slack (except encrypted!), but unlike Slack, our user database is public and connected to known identities. So there was an opportunity we were missing, namely to teach people about teams they might be interested in, run by people they are interested in. Seems obvious now, but we had our blinders on.

(2) A large "open" team still makes sense on Keybase, even though anyone is allowed in. It's worthwhile because sender authenticity is extremely valuable. Protection from phishing attacks has been driving a lot of our team signups/migrations...especially in the cryptocurrency space.

If there are any technical questions about these changes or how teams work on Keybase, happy to answer them here. As you can tell from my HN profile, it can be proven I'm keybase.io/chris .

The outpouring of positive energy (on HN!) is really inspiring. Everyone on the Keybase team is feeling good about our work right now, so thanks!

We believe the right long-term answer for Keybase is finding a way to charge large corporations and offer pretty much everything else for free. Obviously there would have to be some paid tier if you really wanted 10TB of storage or something, but very few people want that right now. We're still just getting started.

Of course to achieve our goal, we'll also have to find a way to distinguish communities - which we'll want to use Keybase for free - and companies.

Many of us on the team have come from ad-supported businesses and we really, really never want to do that again. I personally guarantee I will never be a "publisher" again. Fortunately that just can't work with Keybase, so no fears there.

But charging for anything on Keybase right now would be a big mistake. We only have ~180,000 users, and we want to bring crypto to everyone. That basically means making products we believe are better.

Another way of looking at your concern: I think if we were charging right now, it wouldn't actually decrease the odds we disappeared in a few years. It might distract our attention from working on the best product and cause our bloody demise. So maybe we're not choosing the path that gives you the highest impression of safety, but I think we actually are.

Keybase team member here. Interesting fact: git doesn't check the validity of sha-1 hashes in your commit history. Meaning if someone compromises your hosted origin, they can quietly compromise your history. So even the fears about data leaks aside, this is a big win for safety.

From an entrepreneurial perspective, this is my favorite thing we've done at Keybase. It pushes all the buttons: (1) it's relatively simple, (2) it's filling a void, (3) it's powered by all our existing tech, and (4) it doesn't complicate our product. What I mean by point 4 is that it adds very little extra UX and doesn't change any of the rest of the app. If you don't use git, cool. If you do, it's there for you.

What void does this fill? Previously, I managed some solo repositories of private data in a closet in my apartment. Who does that? It required a mess: uptime of a computer, a good link, and dynamic dns. And even then, I never could break over the hurdle of setting up team repositories with safe credential management...like for any kind of collaboration. With this simple screen, you can grab 5 friends, make a repo in a minute, and all start working on it. With much better data safety than most people can achieve on their own.

I'm on the Keybase team and as you can see we jumped to sponsor a small block. We participated in this for two reasons:

(1) shazow (co-author) was also the author of the official Keybase Chrome and Firefox extensions, and he did an amazing job. We'd gamble on anything he does. The space we bought wasn't that expensive from a company perspective, and it was an educational experience. And maybe it will draw us attention.

(2) Holy crap, it's really impressive a dapp like this is possible with Ethereum. If it hasn't sunk in yet how this thing works, really read the FAQ and stop to think about it. As shazow and ontoillogical said, "there's no backend!" and "It's immortalized!"

There is an analogy here to the slippery-slope of attention-getting ads on the Internet. Once upon a time an ad was just a static (not even animated) banner of a certain size and shape. 468x60 was one of the earliest, IIRC. Advertisers invented new formats ("skyscrapers", "xl-leaderboards", "300x250", and so on), and also they got animated, and then they started expanding outside their areas, and so on; each new ad temporarily performed literally dozens of times better than the previous due to shock value.

A year or two after a new, more intrusive format became ubiquitous, its performance would fall back to the old format's, and, worse, the old format would fall even further because it was too subtle. So in the long run, the money would stay the same, but the pages got uglier, formats got crazier. The game theory is clear: everyone is incentivized to upgrade to the new formats, but once there, no one is better off (neither the publishers nor advertisers), and the readers themselves are far worse off.

We're seeing this now with traffic signals: if every crosswalk in the world is replaced with this 3D version, we'll see a temporary boost in safety, but in the long run it may return to normal and in my opinion, our world will be uglier. I don't like our public spaces covered in optical illusions.

In my area I've started to see red lights that are so bright you are temporarily blinded at night if you look at them. And they've even begun attaching strobing white LED's to the center of some of them. I would guess these perform great in short-term studies. Just like flash ads with games in them.

When we started Keybase, it was a hobby project to address shortcomings of PGP. Max and I both had just downloaded software packages and wanted to verify them, and it took us hours. At least one of them was bitcoin; I recall staring in awe as Max showed me the countless Gavin Andresen impostors on the popular PGP key servers.

We really thought we'd stick up the Keybase directory, make some basic scripts, and move on.

Upon further review and growing popularity, we realized we'd hit a nerve but only solved one of 3 problems related to public key infrastructure.

(1) the identity problem; this means think of a PERSON, and end up with a key. This really is what started Keybase. It was made possible because of how identity has changed in recent years. Whether you're following a famous developer or you're looking up your own sibling, odds are in 2017 you know a public definition of them: a Twitter account, Reddit account, Facebook, etc.

When attacking point 1, we made it a lot more than just posting a fingerprint. We needed these proofs to be bidirectional. It's not just that you should be able to start with a Twitter account and get a key; you should be able to start with a signed statement and end up on the Twitter account. We also attacked revocation and other issues.

But really, there were 2 big missing pieces:

(2) multi-device key management; the OLD shitty story was having one private key that you moved around from device to device. This was never an acceptable solution for most people. What the heck is a private key? How do I move it around? What if just one of my devices is compromised? And so on.

In 2015 when we decided to commit to Keybase, smartphones were poised to solve this. They solved this by guaranteeing that whatever 2 devices you have, you can always bring them together. So you should never have to move a private key around again. In the mobile era, you can bring 2 devices together and declare they're both you. Technically, underneath the surface, device #2 generates its own key pair, and device 1 signs the new public key, and device 2 countersigns this, and all this goes into an immutable chain (by signing the hash of the last identity change).

This means you don't need to understand what a key pair even is. It feels roughly the same as when your bank tells you to grab your phone in order to log in.

And if you have a compromised device, your identity isn't destroyed.

This was the 2nd thing we wanted to tackle.

Finally, to address your point, number 3.

(3) all the GUIs around PKI really kind of sucked. There were some standalone chat apps that were good, but nothing that got people building a real graph of keys and identities, so they can do whatever else they wanted. For a PKI to work, people needed usable software on every platform. And it couldn't be constrained to people in your phone book, where you needed to securely exchange a phone number first.

We think the basics of a usable PKI are:

   (1) to know who you're talking to (and to trust teams)
   (2) to be able to share data, securely, on any platform

If Keybase offered that, whether or not it felt like a "Slack-killer," you could secure all the other aspects of your life. Everyone uses different crypto powered apps now: SSH, IPFS, Signal, bitcoin, ethereum, etc., and it's so annoying to get started. Keybase actually makes all of them easier, because you can think of a person and talk to them about it. Then you can move on to transferring that cryptocurrency, accepting that server fingerprint, establishing that OTR chat (and checking security codes without meeting in person), etc.

We really felt that only by solving all 3 problems would a general PKI ever take off.

`keybase chat api --help` gives a bunch of examples. There's more possible than what that suggests, but it should be a good start. We'll expand the docs soon.

We have already written a number of internal bots at Keybase. We have one that posts all our github commits into a channel, for example.

Yes, you can be the initial owner and then add other people as owners (or admins). From there you could downgrade yourself to a regular user - or if they're owners, they could downgrade you.

They could also kick you out. I've done this a few times today. We reserved a number of team names for known tech companies, and when they've asked, I've created the team myself, added a couple of their managers as `owner`s, and then they've booted me.

You can think of the team's sigchain as just a string of signed announcements. You can sign someone else in as owner.

Answer to your edit: team names are not private, as their hashes can be found in our merkle tree, which anyone is free to mirror or lookup. So if you name your team `foobar` someone would be able to hash foobar and look it up, and yes, prove it exists. This is a feature, not a bug :-)

But if you picked a team name with very high entropy, then I guess that would be semi-private in that it would be undiscoverable by brute force.

It'll come after some improvements to team management and chat. But it isn't that much work, technically. KBFS is already running on your phone and understanding the filesystem... (your phone helps rekey data when needed.) It's just about building an interface around it. Which is no small task. It needs to be good. Hopefully soon.

we pushed it behind teams, but we'll do it soon. 2 things we want to work on shortly:

(1) switching to short-term exploding message mode (what you would expect from OTR), so your messages can be read and then disappear. And devices don't cache them. This has inconveniences, especially for team chat, but it's what you might want in certain sensitive situations or certain DM's.

(2) a message auto-deletion policy for the team. This is different, and it's been requested by some testers.

nope! We feel pretty strongly this is the right answer.

There are so many conveniences around a global team name. Any time we played through the mental exercise of ambiguous names, it led us back to the deep pains of reading out loud security codes or fingerprints, or relying on some kind of hard-to-use web of trust around trusting people and then their vouching for teams. (note people, too, have unique names.)

With our testers, I've already had so many conversations about team names. If it's an in-person conversation it's validated entirely without looking anything up. If it's digital over an alternative medium - then the sharer doesn't have to go look up their team's identifier in order to talk about it. Everything is easier.

Also, I'm not that cynical by nature, but I've had a lot of conversations with people about security since we started Keybase. People don't check codes. From encrypted chats to SSH server fingerprints (ugg!) -- people don't check them. If a team name can be equivalent to one, but the cost is that the space is limited, it's worth it.

I guess in summary: why is a name better than a fingerprint? It can be memorized without effort. It can be visually or verbally reviewed without effort. And it often has meaning.

Blog author here. In the interest of keeping the post more of a summary, we left the cryptographic details to our docs. Here's a link to that: https://keybase.io/docs/teams/index . We're happy to answer questions here.

This really is an exciting product for us. Once you can define a team, cryptographically, without server trust, a lot of other things follow. We'll be launching some of those things in the coming weeks.

Also left out from the blog post: teams (and chats) can be controlled through a local API, so pretty much everything in Keybase can run in the form of a bot, also without trusting Keybase servers. Cheers to crypto!

Keybase is! | NYC | SF | CHI | On-site. We're building crypto for everyone, and we're making our tools/apps for cryptography and secure teamwork on all platforms: iOS, Android, macOS, Windows, and Linux.

Our software is open source, written in Go and ES6; our apps' interfaces are built in modern Electron/React/React Native.

https://keybase.io/jobs

TL;DR: Remove old paired devices! I just went through this this week with a 2013 Wrangler. Here's what fixed it for me: deleting the other bluetooth devices from the radio. It had my old iPhone and my brother's iPhone. Neither was anywhere nearby, but when I tried to pair with my new iPhone, it wouldn't work. I tried multiple times over multiple days. Finally, as a test I just removed the other 2 phones from the profile. It paired perfectly after that and has worked since.

I almost forgot another interesting use of this second feature: package managers and binary distribution. Knowing that version 1.2.3 of some app was published a month ago is nice. Also nice is knowing that for the last month it's the only version 1.2.3, and everyone in the world has been getting the same one.

Like everything else Peter Todd does, this is very impressive and extremely useful.

And I think it's almost what we need at Keybase for timestamping our own database. I figured I'd record here what's important to us in a timestamping service, because I have a feeling (if we're reading it correctly), OpenTimestamps doesn't yet do quite what we'd want.

What we would love:

- to announce that our database has hash H at time T.

- to make all our announcements discoverable to prove we aren't making parallel database announcements around time T.

The latter feature doesn't matter if your only goal is proving data existed on a certain date. Say you want to prove you wrote a story, great, just post its hash. But feature 2 is important if you're also trying to convince people that you aren't telling other people other stories at the same time.

Random examples of someone wanting the second feature:

- a newspaper or website might like to prove that yesterday's headlines or stories were X,Y and Z, and that they were the only stories yesterday. How can we know they didn't publish 1,000,000 different headlines or variations of the stories, just to cover all the possible big news of interest, and then point at the 3 interesting ones later? Or later point at the ones that paint their editorial perspective a certain way?

- a money manager / fund might like to prove they can make good stock picks, so they announce their 10 predictions for the year, and later, when they publish their predictions, you can verify they were their only 10 predictions.

- on Keybase we're trying to prove that we're not maintaining 2 different databases for all our users. If you ask who keybase/chris is, Keybase is giving the same answer to everyone in the world, and not accidentally leaving, say, a revocation off the end of my announcements.

- a government might like to prove that its laws were exactly X at time T, and there weren't some extra ones slipped in as optional extra laws later.

- proof you truly love only one.

This all seems to require an authentication method for posting things, and a way for the timestamp server's data structure to be traversable to a poster's announcements, so you know you're not missing anything.

Right now at Keybase we do this by burning money from a specific address, an address known to be our announcement address. It's clunky. But it achieves that goal: someone can know they're seeing all our announcements. This is expensive and annoying to maintain, and it would be nice to see a general package that manages this kind of thing.

So consider this a vote for v2 supporting parties putting signed statements into open timestamp server! Or a request for clarification, if it already works this way.

(Thanks Peter and others who worked on this! very cool stuff.)

edit: formatting

From the beginning of Keybase, we considered this specific user flow very important.

(1) if there's no one on keybase who matches your "assertion", say a certain twitter account or HN account or whatever,

(2) the keybase app encrypts it just for yourself, but signs a message (for yourself) declaring the assertion

(3) when someone proves that assertion publicly, by joining keybase and connecting an account, they are announcing and proving ownership of key(s), and proving publicly they have control of that account and keys

(4) the keybase server wakes up your app and tells it to verify your assertion is now satisfied, and

(5) your app checks the announcement by actually visiting Twitter and then, if the crypto is good, rekeys the data - there's nothing for you to do other than to have the app running, since the human steps were already done back when you made the assertion by writing the message.

Depending on how loosely you use the term, this is a type of TOFU (trust on first use): you're trusting that the assertion provider, say, Twitter, doesn't steal an account out from underneath one of its users, or the user doesn't lose control of her/his account. Note that this would be publicly discoverable because all announcements are written publicly to Keybase's merkle tree.

This is just about the best imaginable key establishment we can think of without meeting in person. It's certainly better better than, say, trusting a key service to map a phone number to a public key. And it's safer than posting PGP fingerprints or public keys on Twitter - in that case there's no way to tell if everyone else is getting the same answer as you.

edit: formatting

yes, but to be clear: an identity proven by your PGP key is still considered "you" for chat/KBFS, as your device keys have transitively said that PGP key is you. So (1) PGP proved twitter (or whatever), then (2) PGP signed in a device key (which counter-signed), and therefore (3) device key can read KBFS/chat that is sent to you by your Twitter name.

yup!

Almost 100% correct :-)

First part: if you lose or wipe a phone and want to reprovision, the lost device's private key is GONE. It will not exist in some icloud backup. When you provision your new device, the Keybase app will make fresh keys. To make that device yours, you'll need to either (a) bring together another keybase device, or (b) enter a paper key. When you do that, the old key will sign your newly generated key, and the new key will countersign. The old key will also be used to decrypt and reencrypt access keys for your data, so you can get to your old messages and files. Your data will live on. So even in an extreme example: if you write data in KBFS or send a chat message, provision a new device, and then revoke all your old devices, you'll still have the data on the new device. Assuming at some point you always held at least one of your private keys.

The general rule of thumb here is as long as you don't lose all your devices (and in this sense you can think of a paper key as a device), you won't lose your files in kbfs/chat.

The reason the answer above wasn't 100% correct: the revocation of a device (by another) does not trigger an identity re-proof, even for proofs made by the revoked device. Why? well, the original identity announcement is in a well-ordered signature chain of your announcements, and at the same time you remove it, you also have the power to remove your twitter or other proofs. By choosing not to do that AND leaving up your twitter announcement, it's pretty clear you're still you. This isn't like PGP where revocations and statements are floating around and could be ordered in any-which-way.

1. key X adds key Y

2. key X adds twitter

3. key Y revokes X (leaving twitter proof)

the twitter proof is considered still valid in Keybase's logic. Because 1,2,3 exist in a signed chain and Y had the power to remove twitter but chose not to.

One final point we've made in multiple places: your PGP key is part of your identity on Keybase (like your Twitter account or HN account), but it isn't used as a key in Keybase chat or the filesystem for a variety of reasons. So really, your Keybase-data is protected by your devices+paper keys. Just don't run out of them!

Oh HN, so much for a soft-launch! (But thanks for all the positive comments on here.) We've been testing Keybase a lot with iOS and Android testers and we quietly released into the app stores last night. In many ways it's an MVP focusing on: (1) Keybase chat, and technically important (2) your phone acting as an additional device key, so you can easily provision new desktop computers.

There are still some things missing from the app, such as the ability to browse your encrypted files (KBFS), although the app actually has KBFS running inside it. So we're close on that front. Also, provisioning is still a bit clunky.

Possibly interesting to HN: Keybase is one of the only large apps we know of which exists on all 5 platforms (iOS, Android, macOS, Linux, and Windows) and which was programmed almost entirely in Go. Except for the chrome, which is react/react native. Source code for all platforms at https://github.com/keybase/client

If you're an HN user and give it a try, please send us feedback. It's `Gear Icon > Feedback`. We read all the feedback.

and for now if anyone hits this, just use the invite code `zcash`. We've left that bypass code working since our recent blog post.

we knew we needed a logo redesign no matter what; the old didn't scale well. The new one looks good at small sizes - say in a menubar or as a small icon. Of course that's just an opinion, but our team is happy with it. In old displays (think 72dpi), our new one isn't perfect, but most devices in the future will be high dpi.

As for brand messaging: the thieving kangarooster was suggestive of spy-like activity, which was playful but many people thought it sent the wrong message.

I personally like the message of the key in the hair...I mean I haven't thought it through in some deep way, but it's sort of like seeing a pencil in someone's hair: it's suggestive about their personality, and a pencil is an easy-to-use tool. A key in there feels good like that, like you can just grab it and use it easily. But that's just my own personal, previously unshared, take on why I like it.

For program-to-program talking, use the "dev" channel, in a topic of your choice. (By default --topic-type=chat and changing it to dev keeps it out of the GUI)

For example:

  keybase chat send friend1,friend2\
   --topic-type=dev\
   --topic-name=KEYBASE-SYSOPS\
   "server-restart [reason:hot and bothered]"

I'll never see this in the GUI but you and your friend1 and friend2, can access the messages through the chat API. The topic-name can be whatever you want, and it allows you to structure messages into channels.

----

If you're using the JSON api - which makes more sense if you're programming it - take a look at `keybase chat help api` to see some examples of how to structure the JSON going in. Anywhere you see a `channel` object, you can add `topic_type` and `topic_name` to them. Both should be strings.

We didn't design Keybase's chat API to match any messaging standard, but the number of calls into it are very few and flexible, and we're open to change.

As it is right now, I imagine it would be very easy to write a library that acts as a bridge to other interfaces, if that's of interest.

There are calls to see into your "inbox" which is the set of conversations, read messages, even peek at unread messages. And of course send messages, too.