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

61–70 of 99 posts

Re: SJCL – Stanford JavaScript Crypto Library

#61

Post by blablabla123 »

bmh_ca wrote: post #3
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.

I've written about this, here: http://stackoverflow.com/a/24677597/19212 , in response to the question "Can local storage ever be considered secure?", and in particular using encryption from the SJCL. Here is the gist, copied for convenience: > There are libraries that do implement the desired functionality, e.g. Stanford Javascript Crypto Library. There are inherent weaknesses, though (as referred to in the link fro…

Thanks a lot for your answer, I also read the one on SO. I'm actually thinking to use WebCrypto API for a current (kind of side-)project. I guess if you wrote a blog post about that, that could be really interesting. Until now I only heard "strong no" towards crypto in JS. Even if it's not perfect, if it can be designed towards "better than nothing". Also given that the Web is likely becoming the major platform for everything at some point in time...

Re: SJCL – Stanford JavaScript Crypto Library

#62

Post by ruleabidinguser »

e12e wrote: post #58
colept wrote: post #15

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…

So, decryption prior to authentication of the executable/ciphertext? So it's more likely to be user A encrypts M with K producing C, uploads to server, where E(ve) swaps out C for C' that records the password B types in and sends it to E - C' then claims "an error occurred, please reload the page/app" and then submits C'', a message M' chosen by Eve encrypted with K? And since C' and C'' are delivered as (js) executa…

When you put it that way im not sure I understand it anymore lol

Re: SJCL – Stanford JavaScript Crypto Library

#63

Post by blablabla123 »

arkadiyt wrote: post #4
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.

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.

Imagine a diary Web app, for me that would be a perfect use case. It's platform independent and you have automated backups in the Cloud - encrypted though.

Re: SJCL – Stanford JavaScript Crypto Library

#64

Post by blablabla123 »

ruleabidinguser wrote: post #62
e12e wrote: post #58

Earlier quoted context omitted.

So, decryption prior to authentication of the executable/ciphertext? So it's more likely to be user A encrypts M with K producing C, uploads to server, where E(ve) swaps out C for C' that records the password B types in and sends it to E - C' then claims "an error occurred, please reload the page/app" and then submits C'', a message M' chosen by Eve encrypted with K? And since C' and C'' are delivered as (js) executa…

When you put it that way im not sure I understand it anymore lol

I think C is the code and C'(') is some evil attack code. Several blog posts about JS crypto mention that given all the past attacks on TLS, it's not unlikely that someone can perform a Man-in-the-middle attack to swap out code.

Re: SJCL – Stanford JavaScript Crypto Library

#65

Post by colept »

e12e wrote: post #58
colept wrote: post #15

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…

So, decryption prior to authentication of the executable/ciphertext? So it's more likely to be user A encrypts M with K producing C, uploads to server, where E(ve) swaps out C for C' that records the password B types in and sends it to E - C' then claims "an error occurred, please reload the page/app" and then submits C'', a message M' chosen by Eve encrypted with K? And since C' and C'' are delivered as (js) executa…

As with anything - the result is only as secure as transmission and execution - so isolation is the only guarantee. If you're truly paranoid - run without network connectivity and transmit through physical media.

That being said, this was a fun project that demonstrates encryption at the lowest common denominator - versus the complexities of setting up PGP for email. This is something my grandmother still using AOL could use.

Re: SJCL – Stanford JavaScript Crypto Library

#66

Post by giaour »

tptacek wrote: post #55
giaour wrote: post #45

Earlier quoted context omitted.

I meant that the WebCrypto API does not rely on network transmission and that window.crypto and window.crypto.subtle are read-only properties in compliant implementations. Those two characteristics alone would seem to solve many of the problems enumerated on https://www.nccgroup.trust/us/about-us/newsroom-and-events/b... , namely the chicken-egg problem of secure javascript transmission and the malleability of the JS…

It doesn't matter that you've securely transmitted the AES implementation if the code that drives AES, sets up its constructions, ensures that its parameters are set properly, manages its keys, and handles the plaintext is itself delivered insecurely. (I wrote the document you're citing, for what it's worth).

I know you wrote the document; that's why I was surprised to see you agree with a claim that using WebCrypto is "more questionable" than serving and using SJCL based on the differences in the libraries interfaces. I personally find SJCL's interface difficult to work with, since all bytes must be converted to an idiosyncratic format (sjcl.bitArray), whereas WebCrypto uses the unsigned int array primitives introduced to the language after SJCL was released. I'm pretty sure that's not what you mean when you say the WebCrypto interface is inferior, and I'll probably need to do some basic reading to figure out what exactly that means in the context of cryptography.

FWIW, WebCrypto should only be available in a secure context (https://lists.w3.org/Archives/Public/public-webcrypto/2016Se...), though I believe only Chrome enforces that requirement at the moment.

Re: SJCL – Stanford JavaScript Crypto Library

#67

Post by thinkloop »

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?

Re: SJCL – Stanford JavaScript Crypto Library

#69

Post by e12e »

blablabla123 wrote: post #64
ruleabidinguser wrote: post #62

Earlier quoted context omitted.

When you put it that way im not sure I understand it anymore lol

I think C is the code and C'(') is some evil attack code. Several blog posts about JS crypto mention that given all the past attacks on TLS, it's not unlikely that someone can perform a Man-in-the-middle attack to swap out code.

C "executable" cipher text that is (presumably) made by prepending a js decryptor (executable code) to encrypt(M,K) - ie: C=make_executable_js(encrypt(M,K)).

C' could be anything (B only sees a minfied blob of js) - but at the very least is likely to be runnable js code. In the simplest case, it's simply a modified message M', encrypted with K and prepended with the (presumably) benign decryption code -- the change now being that when A wrote ("HI MOM, PLZ SEND MONEY TO ACCOUNT #121"), M' reads similar except for the account number (etc, etc).

The main difference (apart from implementation details of encryption and so forth under a js runtime) from Gnu Privacy Guard - is that one can/should/would get a trusted gpg binary that should be safe(ish) to run on potentially untrusted ciphertext.

Note that in the example above, Eve doesn't start out knowing the Key, K -- but as B runs any random js-code found at the "drop" point, Eve might be able to use said code to obtiain K (B types it in and allows untrusted code to handle the secret).

Contrast with getting a cd-rom from a trusted source with an OS and gpg on it - feeding gpg some reandom cipher text C' that Eve created, barring gpg bugs, a) doesn't give Eve access to K, and b) doesn't trick B into reading some bogus message M', different from the message A wanted to send in the first place.

In short - it would make more sense to distribute the decryptor js-script in a public but trusted manner - and then run the decryptor on the cipher text that could then be obtained in a different manner.

What an executable self-decrypting file (weather .exe or .js file) might be good for, is if A hands it to B on a USB key or transfer the encrypted archive in some trusted manner - the data would then be "safe" until B sits down and types in K. How useful this actually is, is up for debate.

All that said - I think it's great fun to make little tools like this, but we should be a careful about teaching people (even for fun) to run random code - be that js or other code.

Re: SJCL – Stanford JavaScript Crypto Library

#70

Post by e12e »

colept wrote: post #65
e12e wrote: post #58

Earlier quoted context omitted.

So, decryption prior to authentication of the executable/ciphertext? So it's more likely to be user A encrypts M with K producing C, uploads to server, where E(ve) swaps out C for C' that records the password B types in and sends it to E - C' then claims "an error occurred, please reload the page/app" and then submits C'', a message M' chosen by Eve encrypted with K? And since C' and C'' are delivered as (js) executa…

As with anything - the result is only as secure as transmission and execution - so isolation is the only guarantee. If you're truly paranoid - run without network connectivity and transmit through physical media. That being said, this was a fun project that demonstrates encryption at the lowest common denominator - versus the complexities of setting up PGP for email. This is something my grandmother still using AOL c…

Right, please don't take the above as critique of writing up a project like this - it's a fun thing to do.

But even if your grandmother could use this, she wouldn't be able to use in any meaningful way in order to increase security around secret messages.

The only case in which such a project (or an equivalent one that generated a self-decrypting executable that asked for a password, or something like[1]) - is that if the file received isn't a trojan, the data in the file remains secure until decrypted for the first time. But as there's no way to know the file isn't a trojan, unless it's been transmitted via secure channel, it doesn't really add any security.

[1] I could see this working for a shell-script and a here-document using gpg:

  #!/usr/bin/env bash
  # this is makemsg.sh

  cat > msg.sh > msg.sh
  echo eof >> msg.sh

  echo "Encrypted message msg.sh created"
  echo " - run msg.sh to read message"
Note that msg.sh is rather easy to audit:

  #!/usr/bin/evn bash
  # this is msg.sh

  gpg --decrypt
jA0EAwMCtkFEXeN2ydJgyT94WmGBkuSM9wFomkopr6BAfnucTv3kyU/w+Ni54PZi

rOdvVl7WUdvt7wZ/Pq64ycM6uqWFp5kXRvw4zCRSKeU= =Jq6V

  -----END PGP MESSAGE-----
  eof
(Note that I've avoided indenting lines of cipher text to avoid breaking the layout).
Post reply on HN