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

81–90 of 99 posts

Re: SJCL – Stanford JavaScript Crypto Library

#81

Post by StavrosK »

tptacek wrote: post #77
StavrosK wrote: post #57

Earlier quoted context omitted.

There's no "non-plaintext password", encryption keys are encryption keys. I don't know if SJCL includes asymmetric crypto, but there's nothing wrong with AES.

SJCL includes public-key crypto, and its defaults include an iterated KDF for password-based encryption, and CCM with random IVs. It's one of the better crypto interfaces (though, again, it's hamstrung when it's run inside a browser).

Ah, thanks. Last I used it, I only needed the symmetric part, so I couldn't remember whether it had an asymmetric part as well. It is a very good library indeed, and was (at least partly) written by Dan Boneh, whom I regard highly.

Re: SJCL – Stanford JavaScript Crypto Library

#82

Post by tptacek »

StavrosK wrote: post #81
tptacek wrote: post #77

Earlier quoted context omitted.

SJCL includes public-key crypto, and its defaults include an iterated KDF for password-based encryption, and CCM with random IVs. It's one of the better crypto interfaces (though, again, it's hamstrung when it's run inside a browser).

Ah, thanks. Last I used it, I only needed the symmetric part, so I couldn't remember whether it had an asymmetric part as well. It is a very good library indeed, and was (at least partly) written by Dan Boneh, whom I regard highly.

"bitwiseleftshift" is Mike Hamburg. :)

Re: SJCL – Stanford JavaScript Crypto Library

#83

Post by StavrosK »

tptacek wrote: post #82
StavrosK wrote: post #81

Earlier quoted context omitted.

Ah, thanks. Last I used it, I only needed the symmetric part, so I couldn't remember whether it had an asymmetric part as well. It is a very good library indeed, and was (at least partly) written by Dan Boneh, whom I regard highly.

"bitwiseleftshift" is Mike Hamburg. :)

I was just wondering that! Half the contributors on the Github repo have the default avatars and barely any info on their profiles, so I couldn't figure out who was who.

Re: SJCL – Stanford JavaScript Crypto Library

#84

Post by placebo »

aabajian wrote: post #75

One of my first jobs involved encrypting medical data in the client-side browser. The plan was to generate a new RSA private/public key pair whenever a new user joined. The keys themselves were encrypted using the user's password (w/AES) on the client side. We stored the encrypted RSA keys and the user's password hash on a server. When a user logged in we would validate the user's password hash, and return the user's…

If the goal was just end to end encryption, why was there a need for asymmetric keys? Couldn't the medical data have been directly encrypted via the password-derived AES key and stored on the server?

Re: SJCL – Stanford JavaScript Crypto Library

#85

Post by michaelchisari »

jcranmer wrote: post #23
michaelchisari wrote: post #11

Earlier quoted context omitted.

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

WebCrypto API was released as a W3C Recommendation January 26, 2017. Indeed, the working group has now shut down (they decided not to do anything about any other APIs than low-level crypto stuff...).

Well, that was fast.

Re: SJCL – Stanford JavaScript Crypto Library

#86

Post by technion »

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…

As much as the facts you've listed are generally accepted, there's grey areas between the "Browser crypto is good" and "browser crypto is bad" that are worth considering.

I'm working on a form submission that I know is going to be used by a lot of enterprise clients, in many cases with passive MiTM SSL devices.

Browser based crypto can prevent the contents of that form leaking to a passive firewall admin, and the very real issues you've raised don't apply to the threat I'm interested in resolving.

Now if I had a marketing team go off and call it "military grade end to end encryption" we'd have a problem, but I won't be letting that happen.

Re: SJCL – Stanford JavaScript Crypto Library

#87

Post by technion »

tptacek wrote: post #74
StavrosK wrote: post #60

Earlier quoted context omitted.

What's a good library to link against? NaCl?

There have to be Node.js libsodium bindings by now, right?

As is often the problem with npm, the question is "which one"?

https://www.npmjs.com/search?q=libsodium&page=1&ranking=opti...

Whilst I would lean towards the one from jedisct1 because I know they maintain the C version, I can't expect an average developer to know that.

Edit: Typing

Re: SJCL – Stanford JavaScript Crypto Library

#88

Post by notyourwork »

thinkloop wrote: post #67
jpgoldberg wrote: post #32

It is important to separate three security concerns: 1. Crypto delivered to the browser over HTTPS depends on the integrity of HTTPS. 2. A browser is a very hostile environment (injected JS, other browser extensions, etc.) 3. JavaScript may not be the best language for coding certain things (e.g., it is hard to remove strings from memory) Depending on your use, some of these might be larger concerns than others. For…

The browser is not secure, but it's secure enough for banking and passwords - why is this that different?

The place that stores and manages your passwords for things like financial institutions has the right to decide if they would prefer a higher level of security.

Banking industry doesn't have much of a choice, they have to provide an online portal to service their customers. Customer's don't want or need a banking application to check their balance or do a bill pay.

Re: SJCL – Stanford JavaScript Crypto Library

#89

Post by homakov »

tptacek wrote: post #16
baby wrote: post #12

Earlier quoted context omitted.

> 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…

That is well put, probably worth slightly revising your old article to highlight that.

Re: SJCL – Stanford JavaScript Crypto Library

#90

Post by Buge »

k__ wrote: post #37
jpgoldberg wrote: post #32

It is important to separate three security concerns: 1. Crypto delivered to the browser over HTTPS depends on the integrity of HTTPS. 2. A browser is a very hostile environment (injected JS, other browser extensions, etc.) 3. JavaScript may not be the best language for coding certain things (e.g., it is hard to remove strings from memory) Depending on your use, some of these might be larger concerns than others. For…

When will we have end-to-end encryption in the browser, is it even possible? Can this be achieved with extensions? What makes this unsafer than, lets say SSH? I mean, it is a software I download from somewhere, just like a browser, so if I trust SSH to encrypt stuff I want, why can't I trust the browser to do the same?

What do you mean by end-to-end encryption?

If one end is the browser, and the other end is the server, then we already have end-to-end encryption: https (as long as you don't use a TLS terminating CDN).

Post reply on HN