-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 25.02.2012 01:39, schrieb Tom Ritter: > I'm going to have to jump in and say that the Matasano article is > not old, and the fundamental issues in it are not resolved. > hellais highlights a single browser improvement and a few possible > workarounds for other issues - it doesn't invalidate the article. > I'm not terribly familiar with the specifics of OpenPGP JS and if > it's incorporating these workarounds, but from what I've seen, it > is ultimately doing OpenPGP in javascript. > > I'm critical of javascript cryptography because it's _dangerous_. > I'm not unconvinced it's possible to do 'securely' (for most values > of securely) - I am however made way more nervous by claims like > "Keep it strong and resist objectically again claim and critics, as > for many years JS has been considered crap-stuff, but in the HTML5 > world things are changing and crypto-veterans must update their > vision!". Crypto-veterans usually have a reason for their > skepticism.
I do not see the general problem with JS because it is turing complete just like any other language. We should definitly differ between two types of "applications" here: - - One is a web page which means it is loaded from the server every time you access it. - - The other one is a normal executable which uses a Javascript engine instead of another programming language. > I've lost count of the number of shoot-from-the-hip crypto projects > in the last couple years. Cryptweet was the most recent, and they > all follow the same pattern: Announce crypto thing that secures > 'something', have no published threat model, no request for > review, but an initial 'launch'. It gets good coverage, everyone > pokes at it a little bit, it falls over and is insecure, everyone > talks about there's now yet another insecure crypto example out > there, and it's forgotten. > > Wanting to do a sanity check is a great idea, and gives me > encouragement for the project. A sanity check is always good. We should definitly not rely on the project without auditing it. > I tried to create a taxonomy of problems that javascript > cryptography must overcome: > > Third-Party Problem: Any third party supplying code can poison the > runtime True, but this can also happen with a normal program if you use third-party things. If I compile a library into my program the library can virtually do anything, so read my keys even with a normal executable. > XSS Problem: Any XSS flaw can poison the runtime We should definitly look into this, because it really is a big problem. I would compare it to a Heap Overflow in a normal Executable because the consequences are merely the same (control over the application) > MITM Problem: Without SSL the code can be easily modified Mainly only true for Web pages and not "apps you install one time". You should still download those via SSL, but it is the same problem as with normal executables (which you should also only download via ssl otherwise one can change the source code too). > SSL Problem: SSL Authentication (CAs) blows Not our problem but a general Internet Problem (from my point of view) > Modified Problem: Have to validate the runtime each new pageload Problem for a web page, but not an app. > RNG Problem: Javascript doesn't have a secure RNG > Implementation Problem: Shouldn't write your own crypto Why not? > Keystore Problem: Where do you keep your keys? With an app you can keep the keys on the disk just like any other "program". For the Web page only localstorage is a possibility. > Side Channel Problem: Timing and other attacks Not my area of expertise. This is also a problem for executables as far as I know and as far as I heard, it is also a huge problem there. I do not see the general problem with stepping on new land and "trying to find out" but we should keep this in mind when discussing what we encrypt (I would not use the JS crypto for my very high secure mails or files, but maybe for a "standard chat") > Coercible Problem: Has the entity you used to trust still > trustworthy? I do not really see where this fits in. > Cache Problem: Has your cache been tampered with or poisoned? Web Page problem. Not really solvable. A dedicated app is not a problem. > I suggest using this as a baseline for the sanity check. (It may > not cover everything though!) For each item: how can OpenPGP.js > mitigate the risk in code and in deployment guidelines. What is > the threat model for each: do you attempt to defend against it, or > not. - From my point of view the idea is to bring crypto to more people. For example if you build a "PGPBOX" you could do it like this: Have a Web Page and a Plugin for major browsers. For those who want to have the "full" security, get the plugin, for everyone else, Web Page might be a good solution and is better than no encryption at all (like Dropbox which "has encryption but not anything secure at all" as far as I know) > There's a lot to think about. A sanity check is a very good idea. :) True! Greets, Nils -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJPSNR0AAoJECvXQ9f0b0Ho8akIAKm3jnNeyrncqXwD2AcpvUZA SOmbM+IeMxQ+BNxhsWvnrFmwvRHvxxBzPKIZ8K2tXrUr0dni8CcS/67bssSW+6zm OUz07QxOjhh+ZyUkZezozboI6+V/4kT5Ahsm15UEigrmXurzchAZRA842m84C13j 4b91ktstm7iSPKzE9Qm7OvHbZkyMDiqx1pGx+lvwYI4tKpmNhweiI91b+pMrDFvp 0ZPealFxSWvAMBuM98HSlWeiS4E8Pj0aJOvK/SgW4KZBa74Ev/OyH2K2qqwG5Ssg iTgpHzi3HIELShQv2sPfJ6U00qc+SM28p4a5vRzH5q0lAmoY+Rl+YjQRCKqrFWQ= =jaV+ -----END PGP SIGNATURE----- _______________________________________________ http://openpgpjs.org
