33 ms·

Web Cryptography API Examples

33 points by diafygi 12y ago

yeukhon 12y ago
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 12y ago
  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 12y ago
    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.
wtbob 12y ago
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.
- thomasfoster96 12y ago
  Is this comment meant for browser-based crypto in general, or just this API?
  - wtbob 12y ago
    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.
    - thomasfoster96 12y ago
      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.
- jessaustin 12y ago
  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 12y ago
    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 12y ago
      Never trusting the server seems equivalent to never using an online service. This isn't helpful.
- taf2 12y ago
  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.
  - wtbob 12y ago
    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.
tptacek 12y ago
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 12y ago
  > 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 12y ago
    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!
- sarciszewski 12y ago
  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 https://github.com/jedisct1/libsodium.js instead.
- yuhong 12y ago
  >* Avoid AES-CBC. Why? Most of the flaws comes from MtE as I understand.

33 points by diafygi 12y ago

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 12y ago
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 12y ago
  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.

wtbob 12y ago

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.

thomasfoster96 12y ago
Is this comment meant for browser-based crypto in general, or just this API?
- wtbob 12y ago
  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.
  - thomasfoster96 12y ago
    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.
jessaustin 12y ago
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 12y ago
  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 12y ago
    Never trusting the server seems equivalent to never using an online service. This isn't helpful.
taf2 12y ago
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.
- wtbob 12y ago
  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.

tptacek 12y ago

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 12y ago
> 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 12y ago
  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!
sarciszewski 12y ago
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 https://github.com/jedisct1/libsodium.js instead.
yuhong 12y ago
>* Avoid AES-CBC. Why? Most of the flaws comes from MtE as I understand.