Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

SJCL – Stanford JavaScript Crypto Library

github.com

Post reply on HN
Print view View original

11–20 of 99 posts

Re: SJCL – Stanford JavaScript Crypto Library

#11

Post by michaelchisari »

amenghra wrote: post #6
provost wrote: post #5

Earlier quoted context omitted.

This "discussion" has been going on for a long time. Here is an article posted to HN back in 2011 that you might be interested in: https://www.nccgroup.trust/us/about-us/newsroom-and-events/b...

Keep in mind that today's browsers have native crypto APIs that weren't available when this was written. ( https://developer.mozilla.org/en-US/docs/Web/API/Web_Crypto_... )

I wasn't aware of this, and checked caniuse, nad there's already some solid support, although the standard isn't complete.

Re: SJCL – Stanford JavaScript Crypto Library

#12

Post by baby »

Quiark wrote: post #8

Browser crypto is really problematic. For one, the client is downloading the crypto JS implementation (almost) every time they are using the app. Server compromised? crypto.js is rendered useless. HTTPS certificate compromised? crypto.js is useless. And also: XSS vuln on your website? crypto.js is useless since attacker will just exfiltrate your private key / password through XSS. The browser is wonderful for UI but…

> For one, the client is downloading the crypto JS implementation (almost) every time they are using the app

Not in the case of browsers' extensions or Electron/NW.js apps.

> XSS vuln on your website? crypto.js is useless since attacker will just exfiltrate your private key / password through XSS.

It's not like buffer overread and other vulns don't exist in the non-browser world. Also, a huge amount of XSS vulns can be avoided by having a good CSP config.

Now I'm not supporting javascript crypto. Just responding to some of your points. Inb4 some crypto SJW quotes me on that.

Re: SJCL – Stanford JavaScript Crypto Library

#15

Post by colept »

Shameless plug: SJCL is a great library and easy to work with.

I've used it to build a non-profit decentralized encryption tool that can be used to send and receive files that will self-decrypt using SJCL, JavaScript FileReader, and HTML5 download attributes.

User A creates a password to encrypt a file using this client-side mechanism - which produces a self-decrypting HTML file. User B opens this HTML file in their browser which will ask them for the password to decrypt the file allowing them to download the original file all without a server. The homepage can be downloaded and self-hosted at will.

https://zipit.io/

edit: I have uploaded it to Github today for easy self-hosting: https://github.com/colepatrickturner/zipit

Re: SJCL – Stanford JavaScript Crypto Library

#16

Post by tptacek »

baby wrote: post #12
Quiark wrote: post #8

Browser crypto is really problematic. For one, the client is downloading the crypto JS implementation (almost) every time they are using the app. Server compromised? crypto.js is rendered useless. HTTPS certificate compromised? crypto.js is useless. And also: XSS vuln on your website? crypto.js is useless since attacker will just exfiltrate your private key / password through XSS. The browser is wonderful for UI but…

> For one, the client is downloading the crypto JS implementation (almost) every time they are using the app Not in the case of browsers' extensions or Electron/NW.js apps. > XSS vuln on your website? crypto.js is useless since attacker will just exfiltrate your private key / password through XSS. It's not like buffer overread and other vulns don't exist in the non-browser world. Also, a huge amount of XSS vulns can…

I think it's important to decouple Javascript the language, Javascript the runtime, and the browser security model from each other. Javascript --- the language and the runtime --- aren't ideal environments in which to do crypto, but they're not untenable. It's the browser --- not the browser shell, running as a standalone application as in Electron, but the actual Chrome browser that fetches things from URLs --- that makes crypto untenable.

Re: SJCL – Stanford JavaScript Crypto Library

#17

Post by gregmac »

Quiark wrote: post #8

Browser crypto is really problematic. For one, the client is downloading the crypto JS implementation (almost) every time they are using the app. Server compromised? crypto.js is rendered useless. HTTPS certificate compromised? crypto.js is useless. And also: XSS vuln on your website? crypto.js is useless since attacker will just exfiltrate your private key / password through XSS. The browser is wonderful for UI but…

Do you even trust the site to actually do what it says? After all, a web application is just [someone else's] code running on your system.

Even if it's secure against XSS, HTTPS is intact, etc, you are ultimately putting presumably sensitive data into code someone else wrote and then allowing it to run on your machine with explicit network access.

The crypto implementation may be flawed, or the developer may even send your private key up or other data that you don't expect it to be sending (whether it is out of lack of understanding, accident or malice). It would be nearly impossible for you to spot if it's just sent as part of the big blob of encrypted data you expect it to be sending. The blob being bigger than you expect might be a clue, but the only way to know for sure is to audit the code, and if the code if obfuscated/minimized that could be quite the task in itself.

This is really not a problem of browser crypto at all; this is a problem of trust of the code you're executing and using.

Re: SJCL – Stanford JavaScript Crypto Library

#18

Post by gregmac »

michaelchisari wrote: post #10
arkadiyt wrote: post #4

Earlier quoted context omitted.

The only time you should ever use crypto in the browser is if you're building an end-to-end encrypted app in the browser.

Then encryption should be a standard API provided by the browser. We already have a level of trust in the browser for crypto implementation, we should not be relying on independent javascript code.

> we should not be relying on independent javascript code.

You mean like the code for the web app itself?

Re: SJCL – Stanford JavaScript Crypto Library

#19

Post by lucideer »

In every one of these threads, there are inevitable comments along the lines of "in-browser crypto is inherently unsecure", which often follows to a more general "javascript crypto is inherently unsecure".

This question might be slightly off-topic here, given this seems to be an in-browser library, but can anyone who knows a bit more about this topic than I comment on the state of out-of-browser JS crypto (e.g. NodeJS). The browser as environment does seem to introduce a stigma around security to the entire JS ecosystem, and I wonder if its warranted.

Re: SJCL – Stanford JavaScript Crypto Library

#20

Post by epmatsw »

z3t4 wrote: post #7
blablabla123 wrote: post #2

There's a discussion going on of people who claim doing Crypto in the browser is super insecure. (Crockford is one of them) I wonder to what degree this is true or what needs to be done to do at least some basic crypto in the browser like AES for personal user data.

JavaScript's random generator is not cryptographically "secure" because it's not random enough. You can however make your own random generator by using keyboard/mouse input, microphone noise, etc for entropy.

To be fair, window.crypto.getRandomValues is available back to IE11 and is cryptographically secure.
Post reply on HN