http://rdist.root.org/2010/11/29/final-post-on-javascript-crypto/

cheers.

I agree the current app deployment model, even for heavyweight client apps, is flawed. The “best” commonly-used approach we have today is verifying a PGP signature with a public key that was fetched directly from the same server as the signed code.

I also agree that a server-side app offers no auditability to the client, while JS crypto at least gives some possibility of that. Server-side apps do not offer a fundamentally better or different trust model than JS crypto — both have significant drawbacks in common. But I think there are some additional drawbacks to JS crypto that make it a worse option, even though the trust model is largely the same.

Check out the post next week and see if it helps explain why. Thanks.

i *really* appreciate your thoughtful analysis, but know that i am a developer that has developed many durable and long running systems on the basis of someone saying “that won’t work”

hopefully you’ll appreciate that i’m sincerely trying to get a deep understanding of the limitations of client vs server systems and not simply trolling… to that end i offer my gratitude in engaging in such a discussion

i hope your readers will find value in discussion, even if the end result is that i end up looking like and idiot ;-)

my commentary on your recent points follows:

> – Many different JS crypto libraries

i am personally aware of only a few credible js crypto libs, such as http://www-cs-students.stanford.edu/~tjw/jsbn/, and yet am also aware of dozens of c/fortran/misc crypto libs. of course the quality/culture of js code is a real issue… but some basic googling doesn’t seem to point to a huge proliferation of js libs. if i’ve missed some plethora of usable js crypto code please advise with urls.

> – Around <4 years (some much less), written by web developers

maturity != quality or security. $ms – No access to system security features such as PRNG

https://random.org

personally i’d trust this more than some random mobile phones prng… in fact, i think many of your arguments are quite ‘personal computer’ centric… it’s quite worthwhile considering that access to secure data is going to become increasingly mobile based, and that the limitations of those platforms will undoubtedly become a game changer wrt determining best practices in data security.

> same origin policy only security model

i think this is a red herring. the browser is probably the *only* example of ubiquitous code/security sandbox in existence – despite the efforts of sun microsystems… same orgin is better that *no* security model. consider that most users have any number of application setup for ‘auto update’ on their systems – with root access no less – and that the kernel (ignoring se-linux, etc) offers absolutely zero protected from executing abritrary *.so’s. it’s actually very odd to me that people consider with great deliberation the merits of executing arbitrary javascript when almost no one understands nor cares how osx or ubuntu dlls are verified, signed, and trusted…

it brings to mind a scenario i was once in: a ‘security’ guy refused to install a verison of my software on our .gov systems… i pointed out that the mac he was running came out of the box with an older, flawed, version of the software and that i, the author, was suggesting he updated to a newer, more secure version of the software. he ignored me, despite the fact that apple had never contacted me and had no idea if i’d released improvements to the oss package they’d included from my repos… this is a conrete example of how the magical process if pulling down loads of software from the intertubes and running it generally goes through a very lax security audit.

summary: unless you can provide some *general* mechanism for how users should download, apply trust, and execute software from the internet, including system and arbitrary third party dlls – i dont’s see why js code should be subject to some special treatment/consideration – it’s the only programming language in the world with a standards based security sandbox!

> – User audits crypto code every time they connect to the site (note: no users actually do this), no way to detect trojans

i’m unclear how https and certs (trust chains) don’t solve this. if they do not it would seem that the ‘server side encryption is better’ argument would immediately fall down. right? consider: what version of openssl is the server running? where did they get it from? how do i know this?

- Small set of libraries (OpenSSL, pycrypto, ?)
- Has been in existence for 10+ years, usually at least one actual cryptographer as maintainer
- Access to proven platform security features (/dev/urandom, ACLs, UIDs)
- Audit library once and then use traditional modification detection (tripwire etc.)

To this:

- Many different JS crypto libraries
- Around <4 years (some much less), written by web developers
- No access to system security features such as PRNG, same origin policy only security model
- User audits crypto code every time they connect to the site (note: no users actually do this), no way to detect trojans

i personally refuse to consider that it is either value-less or impossible. mark my words: we’ll see more of it as the clould, data everywhere, and js continue to be part of the technological landscape.

at a meta-level *all* crypto code is run from some random server. in the case of a browser/js the server is know and the container designed to be a security sandbox. the sandbox is watched by many eyes. contrast this to

sudo rpo install openssl

or

sudo python setup.py install package.py

or, worse

(double click something.exe)

or, very worse

(automatically upgrade my system while i’m at the coffee shop)

and i think one can begin to imagine how, one day, it might be considered crazy to install and execute crypto code from some random operating system repository.

food for thought.