
Web Cryptography API Examples - diafygi
https://github.com/diafygi/webcrypto-examples
======
tptacek
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.

~~~
pbsd
> 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?

~~~
tptacek
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!

------
wtbob
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.

~~~
jessaustin
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?

~~~
wtbob
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.

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

------
yeukhon
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.

~~~
andrewstuart2
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.

~~~
olefoo
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.

