We've been using SJCL for 4 years in our browser extension to encrypt incognito mode bookmarks [1] and one of the things we've really appreciated is its backward compatibility -- version updates have been complete drop-in replacements which has made developing on this very pain-free.
SJCL – Stanford JavaScript Crypto Library
51–60 of 99 posts
Re: SJCL – Stanford JavaScript Crypto Library
#52I am 99% sure this post was submitted to HN after user read following comment yesterday:
Re: SJCL – Stanford JavaScript Crypto Library
#53Shameless 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…
How does User B obtain the password to decrypt the file? How does the key distribution part work?
It's a plaintext password - not nearly as secure as PGP or the like.
Re: SJCL – Stanford JavaScript Crypto Library
#54For someone not really familiar with javascript could someone explain how sensitive information is removed from memory when no longer needed? Does the runtime expose semantics to ensure memory is zeroed? Also given javascript is garbage collected are there concerns about timing attacks? Or can you prevent the GC from running in critical sections like Go (I assume Java offers this too)?
I can't answer your questions with certainty, but for those who can, could ES6 WeakMap address these two things?
WeakMap just allows you to tell the GC "don't hold on to this memory just because I'm using it as a key in this Map" -- it doesn't let you tell the GC what to actually do with the memory.
Re: SJCL – Stanford JavaScript Crypto Library
#55Earlier quoted context omitted.
SJCL provides a secure random interface (it implements Fortuna). It's not great, and SJCL is not especially performant. But its interface, cryptographically, is (as I said) superior to that of WebCrypto. I'm not sure it matters that WebCrypto is native and "can't be overwritten", given that all the glue connecting the crypto is pure Javascript and can easily be rewritten.
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).
Re: SJCL – Stanford JavaScript Crypto Library
#56For someone not really familiar with javascript could someone explain how sensitive information is removed from memory when no longer needed? Does the runtime expose semantics to ensure memory is zeroed? Also given javascript is garbage collected are there concerns about timing attacks? Or can you prevent the GC from running in critical sections like Go (I assume Java offers this too)?
Couldn't buffers be used for explicit memory control? I think that was how emscripten implemented memory management
Re: SJCL – Stanford JavaScript Crypto Library
#57Earlier quoted context omitted.
How does User B obtain the password to decrypt the file? How does the key distribution part work?
It's a plaintext password - not nearly as secure as PGP or the like.
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.
Re: SJCL – Stanford JavaScript Crypto Library
#58Shameless 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) executables - Eve can choose what to do - try for a compromise when B runs C', show the original message but run additional code for C'' ... ?
Re: SJCL – Stanford JavaScript Crypto Library
#59Earlier quoted context omitted.
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.
I know that website JS isn't a solution. But can't the browsers provide APIs for this? I mean they force me to directly use user-events to switch to full-screen, why can't the do such things for crypto APIs, so that no one could mess with this?
Because you're downloading the program at every launch. A malicious program doesn't have to attack the APIs, it can just send the data to the bad guy's server after it's been legitimately decrypted.
Re: SJCL – Stanford JavaScript Crypto Library
#60In 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…
Node, V8, and Javascript in general isn't the most hospitable platform on which to do crypto work (Rust, Go, and Java are better for it), but if it's worse than Ruby or Python, it's only marginally worse. One challenge is that SJCL is a very well-designed library that assumes it has no low-level primitives to work with, but in a Node environment you have native code to lean on, and you're better off doing than than u…
What's a good library to link against? NaCl?