Comment by NateLawson | Hacker News Reader

Comment by NateLawson | Hacker News Reader

Parent Full thread

Here are two things you say in the same paragraph:

  By providing the low-level API, application developers
  can make an informed decision on what that "box" looks 
  like to them, or relying on cryptographically skilled 
  developers to produce libraries (ala KeyCzar, ala NaCl) 
  to do that for them.

and

  ... neither do I think this API should include the 
  kitchen sink, bathtub, robe, and matching slippers
  in order to be useful and applicable for many web 
  developers.

In other words, you're claiming that some few skilled cryptographers will produce a safe, high-level API (eventually) and the low-level API is already useful to many web developers. The implication is that many web developers can do something that is both useful and safe with only the low-level API.

My experience has shown that to be the exception much more than the rule. Put another way -- I've never reviewed a system implemented by developers experienced with cryptography that hasn't had at least small flaws. The carnage created by validating the practice of novelty crypto protocol design to many developers may be astounding.

I think you're too sanguine about the potential damage to users by this API. That's the problem with externalities. It's not the developers who hurt themselves with this "chainsaw", it's the end-users who are hurt by those developers.

  In other words, you're claiming that some few skilled 
  cryptographers will produce a safe, high-level API 
  (eventually) and the low-level API is already useful to many 
  web developers. The implication is that many web 
  developers can do something that is both useful and safe 
  with only the low-level API.

I was not trying to suggest that only the low-level API is sufficient. I think there's no question that for some segment of potential use cases, they would be unquestionably better served if their hand was held all the way through, that that the crypto protocol and exchange was fully dictated for them. I think that's true for just about any use of crypto.

However, if we only provide a so-called high-level API (what I've been terming as box/unbox, and which is conceptually similar to what Keyczar, Nacl, or even JOSE offer), then I think there's even an larger number of known and possible use cases that simply cannot be implemented. That's why I believe it's more useful to provide a low-level API.

I think perhaps there are unrealistic expectations on what this is trying to do or who this is trying to serve. It's not trying to save the world from bad crypto. It's attempting to bring to the web platform what has existed in native code for 3+ decades - pitfalls and all.

I'd also be concerned about the argument going the other way - if we only provided a high-level protocol & API, then developers would need to implement whatever protocol specified atop the existing low-level primitives (OpenSSL, PKCS#11, CNG, etc). There, just as well, the risk is that people will get it wrong - or that 'others' will write libraries to do it right. You can't escape from the fact that crypto is hard, and that there is always going to be a segment of developers who will simply not get it right.

Ryan, Brian, David:

You guys are working on something important, for better or worse.

Have you ever arranged to sit down with people who have spent time breaking cryptosystems? You're talking to a couple here (Nate is far more qualified than I am), and I saw on the mailing list you bounced the ball back and forth with Zooko --- who, while more a builder than a breaker, is at least pretty cognizant of real-world attacks.

You also had the RUB critique of the API, which saw no response on the mailing list.

Is this API something that is likely to ACTUALLY HAPPEN? If it is, why can't we just arrange to get people into a room to talk to them about what goes wrong when devs get tools like this?

The most dispiriting thing I see happening here is parties talking past each other. Let's force the issue.

You're talking about http://lists.w3.org/Archives/Public/public-webcrypto/2012Sep... , right? I replied, and also tried to clarify in a follow-up message on http://lists.w3.org/Archives/Public/public-webcrypto/2012Sep...

As far as "arrange to get people in a room" - that's exactly what we're trying to do, and exactly why we solicit feedback. While the Hacker News engagement is great, and so is Twitter, I suspect that I'm missing 90% of the discussion because nobody is sending mail to where we asked - public-webcrypto-comments@w3.org - and so no one in the WG is having a chance to engage and discuss.

Again, we're not trying to design a cryptosystem here, as far as a "secure messaging protocol" goes, least of all because no one who submitted feedback during the months of time spent when it was a W3C Community Group and chartering into an actual WG did anyone actually give a use case where their needs would be met with such an API.

Definitely, the best place for concern and criticism will be the mailing list, and that's the whole point of the wide canvas and call for feedback.

My main complaint was your implication that large numbers of JS developers ("many") would benefit from this low-level crypto API in the browser. I think it will have the opposite effect, leading to a million differently-broken encrypted message protocols, encouraged by the browser offering just enough rope to shoot the users in the foot.

You don't really address this issue, but point to what you claim is the greater good: more freedom to implement any protocol the dev pleases. In your opinion, the gain from this is worth the cost of a few million compromised users (story out yesterday: Pandora doesn't manage keys for encrypting cookies properly due to a developer choice).

The only problem with this argument is that there is no limit on browser JS developers' freedom today. They can implement anything they want, plugging in AES ECB blocks wherever they want.

For example, consider Meebo, which sent a JS RSA implementation plus the key itself as a substitute for SSL. There was nothing wrong with their JS implementation of raw RSA (as far as I remember), but the whole problem was that crypto doesn't work if the key and cipher implementation are both modifiable by an attacker.

I find it funny that you agree with me in the end:

  You can't escape from the fact that crypto is hard, and 
  that there is always going to be a segment of developers 
  who will simply not get it right.

The goal is not to prevent every failure, but reduce the number of devs who will fail. The way to do this is to offer high-level APIs that reduce the number of such victims.

Currently, the W3 API will victimize millions of users via any clever developer who has read Applied Cryptography. With a high-level API, you reduce that set of devs to those who are determined to get it wrong (e.g., post private keys on their website today). I think you agree that's a smaller set (though how much, I don't know).

The W3 low-level API will encourage more flaws while offering no improvement over the current JS security model. The fact that you can do things like Meebo (but with higher performance and cred with managers that "it's the standard"), is a net loss of security, not gain. Too bad.

Reply on news.ycombinator.com