malgorithms

The problem with this is that, from the buyer's perspective, the price is almost always the same when using a credit card or alternative. And with a credit card, the buyer gets rewards back, typically 1% or so. So, sadly, using a credit card continues to have more protections, costs less, and has deferred payment. I don't think this is a good thing, just saying. I hold some bitcoins, but I never buy anything with them. It costs more.

This is a good question: generally if all you know about someone is their twitter name, and that's it, then a compromise of their twitter account could lead to a compromise of their key announcement.

Even this case is mitigated because of the timestamping: a compromise would have to be a public compromise on an ongoing basis, and everyone in the world would have to see the same compromise, including the alleged twitter holder. Tracker statements add to the timestamping: when someone runs the Keybase client and tracks them, they sign a statement saying on date X twitter user Y had that public key and they checked it.

The second advantage is that a person is typically a sum of many identities. Consider a known developer who signs code using their Keybase announced key. (Let's say Jeremy Ashkenas does (does he?) - anyway, he's on Keybase as https://keybase.io/jashkenas). His public key is announced on his Github and Twitter accounts, both of which are known. He signs those statements with the matching private key. If you ask Keybase for his key, you get 3 things: Keybase telling you what it is, Twitter agreeing with you, Github agreeing with you, and bitcoin telling you everyone in the world has gotten the same answer for those 3 accounts for the last few months. And CLI tracker statements timestamping, too.

Cool site! Max Krohn (https://keybase.io/max) and I are meeting with some people working on various PGP projects in Germany in April, and one of the things on our personal agenda is the ideal future of key distribution. We don't really want to be a sole place to look up these keybase-style social media proofs. We also don't think they belong inside the keys themselves.

One complication: looking up a key by email and trusting 3rd party verifications is philosophically pretty different from what Keybase is doing. So we have to figure out how to resolve this. For example, we don't even have an email based lookup at all (!), because we have no way of letting a client verify it's true. I don't know if we can be convinced to change this. We're looking forward to Yahoo's and GMail's work on their E2E projects because it may help verifying email addresses publicly.

And to be clear: we're not in the email business, so we want Keybase-style key proofs to be useful to mail clients like Whiteout. We'd like to work well with everyone.

This is important: since PGP is also used for signing software, and in that world, this kind of compromise can be even more dangerous. The Tor example is great. Also, check out how many keys are on MIT's PGP keyserver for Gavin Andresen of the bitcoin foundation.

Back in 2013 I downloaded bitcoind and spent like an hour just trying to figure out if it was legit or not.

Two things we're particularly proud of at Keybase are (1) that there's no server trust of these proofs, and (2) we pin the entire state of the directory to the bitcoin blockchain, to prevent forking. [1]

In other words, if you ask for Twitter user X's public key, your client can check that proof on twitter itself (rather than trusting that a key server did it for you, like it would with email proofs), and it can trust a hacked/coerced server isn't hiding something specifically from you, such as a revocation. The latter is particularly hard to protect against. It also gets timestamping: you know the world has been seeing the same public key for Twitter user X for many months or years.

[1] https://keybase.io/docs/server_security/merkle_root_in_bitco...

[update] I gave mey a bunch more invitations, but I can be hit up on twitter (https://keybase.io/chris) for HN users wishing to jump our invitation queue, which is large.

Here's the doc on that: https://keybase.io/docs/server_security/merkle_root_in_bitco... . Since users on Keybase append their "announcements" (proofs, username announcement, etc.) to a public signature chain which is verifiable, the Bitcoin merkle step is designed to prove that Keybase is (a) showing everyone in the world the same thing, and (b) not omitting anything from the ends of people's chains.

A question for the designers (Paul?) about verifiability. In the software world you can effectively choose from 2 levels of review. You can (1) review the source code of a project and convince yourself it's fine. Or (2) you can assume/hope that experts have done that, download the software, and just verify you have an identical copy of what everyone else is reviewing. (Ideally using signatures of the authors and reviewers.)

Almost everyone who cares does step 2, assuming they do anything at all. Very few people are qualified or bother to review source code, but everyone who performs step 2 can feel pretty safe, as long as a release is big enough that it's getting reviewed by experts.

So, what's the hardware equivalent? If I'm not capable of reviewing the schema of this hardware, but someone I trust says "this is great", how do I at least know the one I bought is identical to the one she/he bought (or built) and reviewed? How do I verify the components? This seems like a difficult problem.

This is great.

Still, if we start arguing that maybe your government is the bad guy, certainly we won't convince the government. Also we won't convince the people who blindly trust the government.

Therefore, it might actually be most productive to avoid point number 2, as valid as it is, and take as premise that the government & Apple are both currently good guys. And then still convince a secure golden key is a bad idea.

With this in mind, the closest I dared to get was the discussion of the future. Governments do change. Whoever has access to your golden key might be a bad guy tomorrow, or invaded by a bad guy.

Btw, I even took out a whole section about questionably lawful warrants before publishing. For this reason.

In addition to intimacy increasing over time, it's also a very continuous change. So people aren't really thinking about how it's changing. They're just doing it.

Author of the post here. (Thanks, Jeremy.)

There are many details I avoided in the essay that people will get sidetracked on. Such as whether Apple is actually doing it right or not. This is discussed and speculated on elsewhere. And right now I'm far more worried about a world in which they're legally prevented from trying. When the FBI starts talking about our kids getting kidnapped, I think bills start getting drafted.

There are tangents I think HN would've cared about, but which would've been a distraction. For related controversy, Keybase - which I work on - lets users symmetrically encrypt their asymmetric keys, and store that data on our servers. We also let you do crypto in JS. Many hate this! Many love it! But I want to be legally allowed to write this kind of software and release it without a backdoor.

It's hard enough when we all fight about implementation details and security vs. convenience. It'll be a real crap show when we know for certain that security has lost. I'll go program video games or something. Or just play them.

Agreed!

Also, given the successful character extraction, and the knowledge that (1) the font doesn't change, and (2) they're just translated and rotated, I think performing those operations on the individual characters could've yielded a pretty perfect success. Simply try a whole bunch of shifts and rotations on a given character until it matches a reference, almost exactly.

To elaborate, a nice thing about Iced is the simplicity, even inside flow logic, to refactor async code.

  # serial
  for uid, i in uids
    await load_user uid, defer users[i]

All I do is move the await:

  # concurrent
  await for uid, i in uids
    load_user uid, defer users[i]

As you can imagine, this would be radically different JavaScript, yet it's (1) easy to read Coffee, (2) easy to refactor, and (3) runs on any browser.

The ES6 stuff is new, and I can't use it because I'm writing for both Node and the browser, but can someone tell me how the above refactor would go?

I think the great thing about IcedCoffeeScript + the ESC library is how it fits into more complicated flow logic, while allowing easy refactoring. Max doesn't really get into the otherwise impossible examples in his post.

Even if you're firing off RPC's awaiting in the middle of a loop or switch statement, you can move logic around just by shifting individual lines. Consider how simple this looks:

   for user_id in user_ids
      await load_user user_id, esc defer user
      user.whatever()
      # etc., with user

Writing that in plain Coffee or JS is impossible; using a pure async library is sort of possible but impossible to refactor.

It's imaginable that there's a very short-term deadline affecting a deal. But remember: that puts the side with the deadline at a disadvantage, not an advantage. Consider these examples: really needing to sell something for the money, desperately needing someone to fill a job, needing to use a scarce item in the short term, etc. If one of these is happening for real, then the offer they make will have to be compellingly high and convincing, demonstrating their position of weakness. If someone offered you 5X your normal rate and explained they needed a job done this weekend, that's not a negotiation strategy on their part.

But feigning indifference and giving you a short-term deadline for an offer you're unsure you can beat -- that's just a negotiation move, and personally, I would call them on it. Again, I don't want to be responsible for failed application of this :-)

The distinction is this: "exploding" typically refers to a very short period of time, designed to prevent shopping the deal, extensive legal review or advice, or exploring other options. A legitimate deadline for an offer wouldn't be called exploding if it spans many weeks and lets a participant fully understand it.

A dear friend and excellent negotiator told me that when he gets any kind of short-term exploding offer, the first thing he does is verbally reject the deadline. And the second thing he does is ignore the deadline and offer feedback only after it has passed.

I've seen him employ this many times in practice and it has always worked out. I don't want to be responsible for anyone losing a deal, but remember: when someone offers you an exploding offer, it's because they really, really want you to take it. If anything, it should be a sign there's (a) more time to be had, and (b) plenty of room on the terms.

Any deadline claim has to be concrete and believable. The start of the YC program is a good example.

Cool - the notes are very educational. I love this kind of thing: "This must NOT be more than 12 characters long and character 9 cannot be X"

Related: Daimler has a PGP policy. Whoever works on their email likes to get things done.

Last year I emailed a car dealer who worked for Mercedes Benz USA, and I got an auto-reply from Daimler that my signature was unacceptable because the expiration date on my key was too far in the future, and they wouldn't deliver my message at all, unless I fixed it.

I know the salesperson had no idea what was going on with this - but as soon as a contacted him with a signed message and a shorter-term subkey I generated just for them, his outgoing messages started being signed too.

Then, a month ago, I got a notice from Daimler that my key was expiring and I needed to get a new one on file with them.

I've been signing emails as a policy for awhile, and it's the only experience of this sort I've had.

yes, the premise here is that the Keybase server can be caught lying. If you want twitter user X's public key, Keybase can tell you the key and which tweet to look at to verify it. Then you can check it yourself. OAuth doesn't allow this.

Totally appropriate. I should say that we don't really want to be in the business of building general crypto apps ourselves, but Keybase identity proofs can make a bunch of things possible. Anything from financial transactions (send a BTC to twitter user X and know it's going to an address they control) to data access (let Keybase/github/twitter user Y access this server/file/whatever). The idea here is that any app can (1) ask Keybase for a user's key and identity proofs, and then (2) verify it all.

The API is not done, btw. If another call is needed, and you're really serious about building it, we will expand the API.

Yes; here's a tl;dr: for a given user, all of their signatures form a chain of signed statements, where each one points at the previous statement. They don't have to be the same kind of statement: your identity proofs, your tracker statements, etc.

And then each user's chain is itself pointed at in a leaf node of the signed merkle tree. (The tree is signed by Keybase).

So you as a client can verify any individual's personal signature chain, and you can verify Keybase's merkle tree. Finally, and this is the more subtle connection, each user's signature chain has statements about the merkle tree itself, so you can verify all these users are seeing the same Keybase-signed merkle tree.

I should add that we're not fundamentally opposed to some kind of query language in the API requests, but most of our API objects lend themselves pretty well to just passing a list of fields you want. The above technique is very simple and seems to work well.

Aside, it also has cross-origin support (as does search), just added for anyone who wants to interface with Keybase on another web page, in the front end.

An update on Keybase, since it was chosen as the example. The API now supports field declarations. For example, these all work:

   https://keybase.io/_/api/1.0/user/lookup.json?username=chris&fields=basics,pictures
   https://keybase.io/_/api/1.0/user/lookup.json?username=chris&fields=basics,pictures,profile
   https://keybase.io/_/api/1.0/user/lookup.json?username=chris&fields=basics,public_keys

This change was intended from the beginning, but we are still in alpha. It was a quick addition, so the HN post made it timely. The nice thing is that this isn't just a client-sensitive change. Loading a user's info is module, so those above examples should be faster and less work for our server than getting everything about someone.

Happy to see one of our Keybase API responses used as the example here. I can share our intentions with that API call in the long run, and how it'll end up smaller, which is especially important for mobile devices.

The dictionary describing the user you requested comes back with some high level sub-dictionaries in it: "profile", "basics", "public keys", "pictures", etc., and the API replies, currently, with all the data to which you're entitled. This is quite huge as Tim mentioned in his post.

Server-side we have a module for loading user information, which allows you to request which of these fields you want when loading a "user object". For example, on a certain page of the site we might load a dozen users but only need [user.BASICS, user.PICTURES], so that's the only data that will be loaded.

The API simply doesn't expose this filtering mechanism, yet, as calls the API hit [user.ALL] which is a combo of everything available about a user. So, in essence, all we need to do to trim these down is allow you to pass a filtering parameter.

Btw, going in the other direction, there'll be a way to query for multiple users at once, fattening things back up :-). So for example you could request just basics + pictures for an array of usernames or userids.

Very cool! Tested my site before and after a patch, and it recognized the fix. A quick UI tip: you should give some indicator while the test is running. I couldn't tell anything was happening while I waited. Even just a spinner gif of some kind.

While we like being #1 on Hacker News, bad (good?!) timing is what earned us this spot.

It will be the case very soon that you can push your key to Keybase and prove all your identities, without ever installing the client the OP dislikes. Technically, you can already, we just need to put together very explicit instructions and documentation that's different for each kind of proof. By ugly necessity, what it takes to prove yourself on twitter is different from github is different from DNS, etc. Documenting the API was our priority coming into this week.

Later this week the site will have very specific instructions on how to prove your identities (even the complicated ones) simply from your shell plus GPG.

Then those who care can verify all those proofs with a script, in a language of their choice. No Node or NPM needed for any of it.

There was some discussion below about "trusting" the Keybase server's definition of the public key that comes back. The goal here is to remove that trust. Software of your choice can download a Keybase user's keys, the links to their proofs.

yes, sorry if that wasn't clear. What I'm saying is that we'll have them documented very shortly. It's a priority for us, which I believe will address the OP's issue.

We'll have documentation on:

- what needs to be in the signed statement

- how to hash the statement for safety on the platform you're posting, if necessary (twitter: yes, github: no, DNS TXT: yes, web domains: no, etc.)

- how to tell Keybase about the statement (API call)

- how to post the statement on Keybase (API call; this is needed in the scenario where it's hashed, twitter style)

These will all be proof specific, which is necessary for reasons you can imagine. Character encodings allowed, where proofs go, what length they can be, etc., what goes into a proof (username?), etc., are all platform specific.

But the goal is that someone can do this with software of their choice.

I can answer this for Keybase: first off, it's not because we can't learn other languages (someone suggested that below). In fact, we spent 10 years programming OkCupid in C++, and we've built some high performance projects in Go. It's hard to imagine someone could program anything even remotely like Keybase and lack the programming skills to do it in a variety of languages.

Anyway, in our case we (1) like the async programming model, and actively use it -- on the server side, our services tend to be modular and actually speak over RPC layers to each other, not just one big ugly web process. Node is great at this.

And (2) in this case, because we wanted to have a lot of shared code among our first implementation of a client, our browser front end, and our server. It worked very well to work on all three with one language. It's worked out.

I personally miss compiling C++. :-)

There's a very good chance we'll end up writing a Go client for Keybase. We might switch the official reference client once the functionality is more locked down.

Lastly: it's really CoffeeScript, not JavaScript. Which is a different can of worms to open on here.

Yeah, thanks for making this issue. (Chris here, one of the two working on Keybase. I commented on that issue recently.) Getting proofs working totally outside our alpha client (and getting them well documented) is something we're working on this week. Keybase will not require running Node at all to interact with it.

There will be 2 ways to "prove" yourself as a programmer on Keybase:

1. running `keybase prove github` (or whatever service) which is interactive; the keybase client can generate the nice statement for you and pass it off to GPG for signing. This is already working.

2. running something in your shell which requires nothing but gpg and standard shell commands. The key elements here are that you need to generate a signed statement connecting your two accounts, and you need to post it on github. This is pretty simple and won't require Node at all.

Oh, and 3. using some other software of your choice that implements 2.

The reason #2 isn't documented yet is that it's a bit more complicated in certain cases. Consider what it takes to perform a twitter proof (click the "show the proof")

https://keybase.io/chris/sigs/DZ9rccBD8u-Att6kQzhHHtw-924s7i...

The signed statement itself isn't hosted on twitter (it won't fit) but needs to be boiled down into an agreeable tweet-sized hash. In order to prove twitter manually, you need to generate this statement, boil it down, make the tweet, and push the statement to Keybase.

All this will come, and our goal with Keybase isn't to require Node or npm for anyone.

On the IM side of things, you should check out OTR (off-the-record messaging): https://otr.cypherpunks.ca/ - in particular check out the top 4 goals mentioned on that page.