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'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.
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
XSS Problem: Any XSS flaw can poison the runtime
MITM Problem: Without SSL the code can be easily modified
SSL Problem: SSL Authentication (CAs) blows
Modified Problem: Have to validate the runtime each new pageload
RNG Problem: Javascript doesn't have a secure RNG
Implementation Problem: Shouldn't write your own crypto
Keystore Problem: Where do you keep your keys?
Side Channel Problem: Timing and other attacks
Coercible Problem: Has the entity you used to trust still trustworthy?
Cache Problem: Has your cache been tampered with or poisoned?
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.
Not everything will be solvable by OpenPGP JS. Some things can be
mitigated, others cannot.
The runtime integrity issue cannot be solved without browser changes.
It can be mitigated, with Content Security Policy. It can be avoided,
with browser plugins. But if the plaintext is present in the DOM, or
the OpenPGP S2K work factor is set in javascript, or another number
things - the integrity is compromised.
The PRNG can be 'solved' with a browser implementation of a PRNG. But
have you audited that in all browsers? Is Opera's secure? Have you
considered an approach like OpenSSL, which tries to induce more
randomness just in the case underlying RNG is insufficient?
The Third Party and Implementation problems can be approached by
posting a 'finished 1.0.0' version you encourage everyone to audit.
Then that 1.0.0 is signed and users copy it to their own server and
rely on no 3rd party.
Have you speficied guidelines regarding deployment: Public Key
Pinning, Strict Transport Security, Content Security Policy,
preventing MIME Sniffing, X-FRAME-OPTIONS.
There's a lot to think about. A sanity check is a very good idea.
-tom
_______________________________________________
http://openpgpjs.org
