WebCryptoAPI Spec

[elf-pavlik]

WebCryptoAPI Spec

[calvinmetcalf]

Web Crypto has incompatible apis but my native crypto module is in a working state

[fanatid]

@lukechilds there also can be issue in message size which you hashing, if you try calculate hash for few megabytes I think numbers will be much different

[calvinmetcalf]

@lukechilds this project is meant to be a shim for the node crypto api but usable in browserifiable code (or webpack) we are thus constrained by the api of node and when possible (like with pbkdf2) we do use web crypto but for most of the time we can't.

That being said what you are saying is 100% true and I actually wrote a different module that tried to expose a single interface that used the best primitives in the browser or node.

[dominictarr]

This is ridiculous! the native should be ~20 times faster! at the very least 10x faster! I modified those tests to find wether webcrypto was faster... and at 10k input size, it is faster, but only 30% faster.

That we are within this range, just shows that a centralized committee really can't develop nice things. This isn't the first example when user space was better than a web browser core thing https://softwareengineering.stackexchange.com/questions/278778/why-are-native-es6-promises-slower-and-more-memory-intensive-than-bluebird

I would wager that a web assembly implementation could easily beat webcrypto across the board, at any input size.

[lukechilds]

@dominictarr you may find this interesting: https://blog.bitjson.com/just-released-sha-256-sha-512-sha-1-and-ripemd-160-using-webassembly-6179275330c0

[jduncanator]

Yes we have, and its implemented in the random number generator when it exists, but as of now its not reached maturity and is only in leading-edge builds of most browsers. As Mozilla and Google (and I suppose Microsoft in a few years) add support for other functions that getRandomBytes then we can start backing certain functions with the CryptoAPI.

[dominictarr]

yeah. we need crypto before that comes out
(also it's hella weird and complicated compared to node's crypto,
which to be honest, is what you come to expect with standards bodies)
but when it does come out, it will probably be more optimized that any thing
we can implement with pure js, (although, maybe asm.js can help here)

So, certainly falling back to web crypto api where it's available would be a natural move.

Yes, so I'll be sure to get in touch! I think the most important thing is a to enable streaming.
(which I noticed in the spec parts where on hold, awaiting progress on the spec for streams)

[elf-pavlik]

I agree with you comments, and myself mostly think of its performance once implemented in browsers!
I guess other people may wonder about it as well, what do you think about adding small paragraph mentioning it to README?

[dominictarr]

That is a good idea.
crypto-browserify has gotten a lot more serious recently. I should update the readme.

[caedesvvv]

Seems like the way to go is implementing node crypto api using current javascript libraries doing the implementation (like crypto-js or sjcl).

This way we can use a nice api now, with solid implementations, and as soon as native implementation is available in browsers we can use it.

[terinjokes]

Just FYI: Web Crypto API is shipping enabled by default in Chrome M37. https://code.google.com/p/chromium/issues/detail?id=245025#c280

[elf-pavlik]

http://www.w3.org/TR/WebCryptoAPI/ W3C Last Call Working Draft 25 March 2014
If you have any feedback on this spec I recommend submitting it ASAP!

[guymguym]

+1 for using these native algorithms where available, unless it will make it slower :)

[calvinmetcalf]

the web crypto api is entirely async which means it's only really practical for pbkdf2

[dominictarr]

for the streaming apis you could probably make something that still worked, as long as you used them as streams.

[dominictarr]

or, to create a fresh polyfil.

that would probably be good anyway, if you wanted to use libsodium instead of openssl etc

[calvinmetcalf]

The problem is with the sync update method of you didn't need to support
that...

On Thu, Dec 18, 2014, 6:23 PM Dominic Tarr [email protected] wrote:

or, to create a fresh polyfil.

that would probably be good anyway, if you wanted to use libsodium instead
of openssl etc

—
Reply to this email directly or view it on GitHub
#32 (comment)
.

[dominictarr]

yeah, it would be annoying to make every hash need to be async... but I guess unless we can persuade w3c to give us a sync api then that is the choice we have. it would be better to use hardened crypto in the browsers than a js polyfil if possible.

[calvinmetcalf]

so basically what we'd want for this would be crypto-browserifiable, an api that uses the most secure/fastest implementation no matter what the platform is

[calvinmetcalf]

so I have finally started work on a browserifiable crypto library that uses the native apis in both node and the browser https://github.com/calvinmetcalf/native-crypto

[elf-pavlik]

👍 ping @KAepora

[RobertWHurst]

Is there any activity on this front?

[RobertWHurst]

Noted, thanks

[lukechilds]

Sorry to revive an old issue but I thought anyone who ends up here via Google may find this interesting.

I was interested how the perf of Web Crypto hashing would stack up against pure JS implementations.

Tested in a loop, hashing with the Web Crypto API is about 95% slower than just using a pure JS implementation.

https://jsperf.com/sha256-native-vs-js/1

That might well be largely due to the async overhead, if you're hashing a single huge file you might get better results using the async Web Crypto API.

But these results are very relevant to proof-of-work style use cases.

[lukechilds]

@calvinmetcalf yep completely understand and agree.

To clarify I wasn't advocating for the use of Web Crypto in crypto-browserify, just seemed like people in this issue assumed Web Crypto should be used because it's native and will therefore be faster (I made the same assumption). Just wanted to show that for many use cases that isn't necessarily the case.

[rawr51919]

So since the spec has been largely implemented in this module, can this issue be closed?