Web Cryptography API Examples | Hacker News Reader

Web Cryptography API Examples

github.com

33 pointsdiafygi17 comments

This demonstrates a big complaint with the WebCrypto API: it exposes a bunch of stuff you never want to be dealing with --- either directly or, in some cases, at all:

* Never use RSA PKCS1v15

* Avoid padding arbitrary data to RSA-OAEP encryption (you only ever want to encrypt keys)

* The "nonce" bits of the AES-CTR must be random, but the API doesn't even make it obvious which bits those are. Screw that up and you get no security.

* Avoid AES-CBC.

* You can't securely use AES-CBC or AES-CTR without a MAC.

* Never, ever use AES-CFB.

* Avoid multiplicative group DH (what WebCrypto calls "DH").

Out of all those examples, the only interfaces that approach "safe" are AES-GCM and AES-CMAC, and even the AES-GCM case makes it awfully easy to repeat the nonce, which is a devastating vulnerability.

As I understand it, whatever HN might want to believe this API is for, its real purpose is to make it possible to implement DRM without plugins. It's a compat interface, and it shows.

> The "nonce" bits of the AES-CTR must be random

Huh? This is not an IV, the only hard requirement is that it be unique. What am I missing?

You're not missing anything; I wrote that comment in haste, as you can tell from the grammar errors. The CTR nonce doesn't need to be random.

The interface is still treacherous!

I noticed the inclusion of NIST curves and no modern ECC and decided I'd withhold judgment until someone else had a chance to look at it.

This is pretty terrible.

If anyone was looking forward to using this for creating browser extensions (do NOT deliver code from a webserver and assume it's safe!), you're better off using https://github.com/jedisct1/libsodium.js instead.

>* Avoid AES-CBC.

Why? Most of the flaws comes from MtE as I understand.

This is great stuff for plugins, but really bad stuff for scripts. Remember, if you can't trust the server with your secrets, you can't trust the server to send you a script which can decypher your secrets.

Is this comment meant for browser-based crypto in general, or just this API?

Browser-based crypto in general. It makes a great deal of sense to provide encryption APIs for plugins, and there's a case to be made for providing some APIs to site scripts, but in general browser crypto is just scarily insecure.

I might be wrong here, but the two major problems with browser crypto were the fact that you had to send the crypto libraries to the browser in the first place, and that then you didn't really have access to a proper random number generator.

Those two issues pretty much disappear with the use of a built in api from the browser. I guess now you've just got to trust the browser, but the browser is never going to be as secure as doing things on your own server.

Can one stipulate that one does trust a particular server (maybe it has a valid TLS cert?) and still derive some value from this API? E.g., it seems perfectly valid to me to do some work on the client in order to reduce data volumes or server loads?

Well, I'd never trust the server (and TLS certs are only a step or two above pure snake oil security), but if the server is willing to trust me, then I don't in principle mind decrypting data on its behalf.

Never trusting the server seems equivalent to never using an online service. This isn't helpful.

Crypto Apis can be useful for things other than encrypting data - for example creating uniqueness or testing for uniqueness - I'm sure a range of other clever possibilities exist.

Excellent point. A well-chosen set of some primitives makes sense for site scripts, but the general case of encryption/decryption almost certainly doesn't in most cases.

I am surprised to see Chrome failed most of the tests, whereas latest FireFox nightly passed most, since in terms of features, Chrome is usually ahead of FireFox.

Not so much anymore, from what I've seen, especially when it comes to standards. Chrome (and chromium) seem much more focused on experimental future features than current or near-future standards.

There is also the question of whether Chrome pays a "strategy tax" to Google. Where the interests of the parent company cause some features to be prioritized and others deemphasized.

Reply on news.ycombinator.com