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

71–80 of 99 posts

Re: SJCL – Stanford JavaScript Crypto Library

#71

Post by e12e »

e12e wrote: post #70
colept wrote: post #65

Earlier quoted context omitted.

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

Obviously, "msg.sh" is only "easy" to use on something like a Ubuntu/Linux desktop that comes with (ba)sh and gpg -- and it's only "easy to audit" for technical users.

It's still easy enough to swap out the contents of "msg.sh" with something nefarious that sends the contents of ~/Maildir to a remote server or whatever.

The point being, if the user can't trust the framework (in this case, operating system, shell and gpg executable) there can be no trust in the handling of data either.

But blindly running code (be that a shell-script or javascript code) is generally a bad idea...

Re: SJCL – Stanford JavaScript Crypto Library

#72

Post by Klathmon »

sly010 wrote: post #39
k__ wrote: post #37

Earlier quoted context omitted.

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.

With service worker, you can have a similar setup to a traditional application (install once, and have the first installed version verify all other versions are signed by a correct key).

It's abstracted away from you, but with some work I feel a browser UI could be made to help with this process if people wanted it.

Re: SJCL – Stanford JavaScript Crypto Library

#73

Post by CiPHPerCoder »

giaour wrote: post #66
tptacek wrote: post #55

Earlier quoted context omitted.

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

WebCrypto is also a potluck of primitives, designed my committee, with "secure end-to-end encryption" as a non-goal.

I'd personally rather see browsers ship libsodium.js (or equivalent) than WC or SJCL.

Re: SJCL – Stanford JavaScript Crypto Library

#74

Post by tptacek »

StavrosK wrote: post #60
tptacek wrote: post #28

Earlier quoted context omitted.

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?

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

Re: SJCL – Stanford JavaScript Crypto Library

#75

Post by aabajian »

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 encrypted keys. The user would have to know their password to decrypt the RSA key. The theory was that no medical data was visible on our server, even to us. We also used standard SSL for all connections.

The challenge was implementation. At the time there were no AES block-cipher JavaScript modules. My solution was to use GWT to compile BouncyCastle's Java library into JavaScript. I had to strip the library of all low-level I/O calls and replace the BigInteger class with a GWT-JSNI-wrapped version of the BigInteger class I found online. That BigInteger class was a side-project of a Stanford graduate student: http://www-cs-students.stanford.edu/~tjw/jsbn/

He also included a JavaScript implementation of RSA. Long story short, within a year there were several cryptography libraries, but I like to think we were ahead of our time.

Re: SJCL – Stanford JavaScript Crypto Library

#76

Post by tptacek »

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…

How likely do you think it is that your implementation was safe? It's hard enough to use RSA safely in the best possibly circumstances --- and BouncyCastle isn't that! (I hope you're saying you compiled down BouncyCastle's RSA along with their OAEP support, and not that you did what a lot of front-end crypto people do, which is to implement RSA in pure Javascript).

Re: SJCL – Stanford JavaScript Crypto Library

#77

Post by tptacek »

StavrosK wrote: post #57
colept wrote: post #53

Earlier quoted context omitted.

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.

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).

Re: SJCL – Stanford JavaScript Crypto Library

#79

Post by tptacek »

0XAFFE wrote: post #68

How does this compare to libsodium(.js)[1][2]? [1] https://github.com/jedisct1/libsodium [2] https://github.com/jedisct1/libsodium.js

Somewhat similarly. It's default mode is authenticated. It handles nonces and IVs for users, unlike NaCl, which demands random nonces from the user. It has and exposes a lot more primitives than libsodium, which is probably a bad thing for security. Its authors (and not just Dan Boneh) have impeccable credentials.

On the other hand, libsodium will outperform SJCL on Node.js, which is really the only safe place to use a library like this.

Re: SJCL – Stanford JavaScript Crypto Library

#80

Post by StavrosK »

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?

You'd think... There's node-sodium, it looks like it's a binding but it claims to be a port. Who knows.
Post reply on HN