Re: WebCrypto High-Level API - Why?

On 2013-01-25 16:20, David Dahl wrote:
> ----- Original Message -----
>> From: "Tom Ritter" <>
>> To: "Anders Rundgren" <>
>> Cc:
>> Sent: Friday, January 25, 2013 8:52:57 AM
>> Subject: Re: WebCrypto High-Level API - Why?
>> On 25 January 2013 01:42, Anders Rundgren <>
>> wrote:
>>> I'm not sure what the High-Level API that has been mentioned a few
>>> times
>>> on the list actually
>>> refers to but I guess it is something like Google's
>>> ?
>> The other example is NaCL:
>> Personally I don't understand why we should waste money on making
>>> cryptography useable by "n00bs"
>>> rather than doing what we can making platforms more useful for
>>> those who
>>> actual master cryptography.
>> Couldn't disagree more.  Why did we create standard libraries instead
>> of
>> making all these pesky noobs write their own printf functions, and
>> why
>> didn't we stop with C - what's this annoying "C#"and "Python"? So we
>> can
>> abstract away things that don't matter to most people, and stop them
>> from
>> rewriting the bugs we fixed over and over again.  (Example:
>> BasicConstraints)
> Indeed. For the vast majority of web developers, the actual need is 
> var ciphertxt = ecryptThisStringForBob("hi"); 
> or
> var sig = signThisDataForAlice("data"); 
> That's it. A high level API that keeps the details at bay and private key material out of the DOM will be extremely useful.
> Regards,
> David

The vast majority of developers that builds secure web-applications use HTTPS
which relieve them from signing and/or encrypting in the browser.  Occasionally
they need to connect to other systems in a secure way but this is all happening on
the server-side.  In addition, for communicating with other parties than yourself,
high-level cryptographic APIs only create interoperability issues.

And those who *really* need this functionality can't use it since Web Crypto doesn't
address unbound pre-provisioned keys although these are sort of the de-facto standard.


>> I don't disagree that there's a lot that can go wrong with protocols
>> even
>> when they're using the correct algorithms - but the point of having
>> "box()"
>> and "unbox()" functions is to make it *easier* to create secure
>> anything by
>> giving developers a secure starting point.  You seem to approach
>> security
>> with the mindset of "Make it hard for people to write code - we'll
>> have
>> less code, and the code we have will be more likely to be good
>> because it's
>> written by people who persevered!"  No, we won't have less code,
>> we'll just
>> have a lot of code that the developer *finally* got working, through
>> trial
>> and error, and will never watch to touch again.
>> -tom

Received on Friday, 25 January 2013 15:56:19 UTC