Is there a market for end-to-end encrypted app in the browser?
Yes there certainly is a market for that. I work at Virtru, which is essentially doing encryption in the browser for your content and then decrypting in the browser.
SJCL – Stanford JavaScript Crypto Library
31–40 of 99 posts
Re: SJCL – Stanford JavaScript Crypto Library
#32It 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 us, 1Password.com, (1) is the biggest concern for those using the web-app. Our approach is to be very strict about TLS (TLS 1.2 only, HSTS, etc) and to encourage use of the native clients over the web-app.
Re: SJCL – Stanford JavaScript Crypto Library
#33In 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. NodeJ…
> 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).
What I can say is that NodeJS has the biggest and more mature amount of cryptocurrency libraries. This doesn't obviously imply that the crypto libs used are the best ones or they are secure. For example, OpenPGP.js [1] was audited by Cure53 and the changes to support elliptic curve cryptography (RFC 6637) [2] were done and audited by my company (two different teams).
[1] https://github.com/openpgpjs/openpgpjs/blob/master/README.md...
Re: SJCL – Stanford JavaScript Crypto Library
#34Earlier quoted context omitted.
I feel WebCrypto (strange architectural choices made by people whose priorities are availability of crypto, not consistency of security) is even more questionable than running SJCL (a good crypto done by good people in questionable environment) in browser.
I agree. Not making this up: the primary goal of WebCrypto was the elimination of Flash and plugins to enable streaming media players. It's not designed for security. It eliminates some of the least worrisome flaws in browser crypto (side-channel attacks against the lowest-level primitives) but leaves all the rest of the problems intact.
Can you recommend any reading on the subject? I've found WebCrypto to be a vast improvement over the alternatives.
Re: SJCL – Stanford JavaScript Crypto Library
#35Earlier quoted context omitted.
I agree. Not making this up: the primary goal of WebCrypto was the elimination of Flash and plugins to enable streaming media players. It's not designed for security. It eliminates some of the least worrisome flaws in browser crypto (side-channel attacks against the lowest-level primitives) but leaves all the rest of the problems intact.
Can you recommend any reading on the subject? I've found WebCrypto to be a vast improvement over the alternatives.
In what sense? The WebCrypto interface is inferior to SJCL's, which existed for years prior.
Re: SJCL – Stanford JavaScript Crypto Library
#36There'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.
Looks like SJCL can do exactly that:
https://github.com/bitwiseshiftleft/sjcl/blob/master/core/ra...
Re: SJCL – Stanford JavaScript Crypto Library
#37It 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?
Re: SJCL – Stanford JavaScript Crypto Library
#38Is there a market for end-to-end encrypted app in the browser?
Yes, kind of. I use SJCL in Turtl (https://turtlapp.com) which is packaged as standalone browser app (nwjs on desktop, xwalk on android). I'd never publish the app as a web app (at least not without significant warnings to the user/an opt-in) but technically yes, we use client-side crypto in a browser.
SJCL is kind of a pain in the ass though, to be honest. It was built before Uint8Array was prevalent, meaning all your crypto data has to be encoded as a string, and you have to be extra cautious of UTF8 data (you have to decode/encode your data as ASCII strings). Someone please correct me if this is no longer the case.
Recently I've been playing with the emscripten port of libsodium (https://github.com/jedisct1/libsodium.js), which seems to be working quite well. I have yet to benchmark, but the nice thing is that eventually I can replace parts of the app with Rust (WIP) and use the exact same library for crypto as used in the js app.
So, I'd agree in general that javascript is a shitty language for crypto, or at least it was before Uint8Array et al. I'm looking forward to seeing what happens with Wasm...being able to replace a JS app with low-level code compiled from Rust or something is definitely a nice idea. My ultimate goal was to provide a comm layer between JS Rust and embed the Rust portion of the app as a library (.dll/.so/etc) but perhaps it just makes sense to compile everything to Wasm and embed it that way.
Re: SJCL – Stanford JavaScript Crypto Library
#39It 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?
You typically download SSH once, while you download js potentially on every page load.
It is also much harder to monkey-patch a native binary than to inject js into a browser tab.
Browsers by default trust any of hundreds of CA's, while SSH trusts none by default.
Re: SJCL – Stanford JavaScript Crypto Library
#40Earlier quoted context omitted.
Can you recommend any reading on the subject? I've found WebCrypto to be a vast improvement over the alternatives.
In what sense? The WebCrypto interface is inferior to SJCL's, which existed for years prior.
It has a built-in cryptographically sound random source, uses modern JS primitives (Uint8Array and Promise), and easily outperforms SJCL at hashing and HMACing.
Additionally, the WebCrypto operations are built into the browser platform and cannot be overwritten by userland javascript, though the interface can be spoofed in browsers that do not support it natively.