[liberationtech] Tormail in trouble. Experts at Black Hat recommend Elliptic Curves: this is what PassLok 1.3 is based on.

[Francisco Ruiz]

Hi Greg,

It seems my reply didn't stick, so I'm replying again. Sorry about
that. I'm still trying to figure out hos this mail list works.

On Tue, Aug 6, 2013 at 3:20 PM, Francisco Ruiz <ruiz at iit.edu
<https://mailman.stanford.edu/mailman/listinfo/liberationtech>> wrote:
>* Hi folks,*>**>* Thank you very much for your great feedback on the previous version. The*>* next version is now up at http://passlok.com, which redirects to*>* https://passlok.site44.com*>* This may come in handy now that there are problems with Tor, since PassLok*>* allows you to go to any computer to do encrypted mail, because there is*>* nothing to install. This is what PassLok was designed to do.*>**>* The other unforeseen endorsement came from the recent Black Hat conference.*>* Researchers Alex Stamos, Tom Ritter, Thomas Ptacek, and Javed Samuel*>* encouraged everyone to base their public key cryptosystems on elliptic*>* curves rather than RSA. Here's a link on this:*>* http://arstechnica.com/security/2013/08/crytpo-experts-issue-a-call-to-arms-to-avert-the-cryptopocalypse/*

You replied:

>Wait. You are using vague popular press FUD about RSA to promote a
>website hosted JS encryption tool? Really?>
>
>Your code generates random values like this:
>
>        sjcl.random.addEntropy([a.x || a.clientX || a.offsetX || 0, a.y ||
>a.clientY || a.offsetY || 0], 2, "mouse")
>        sjcl.random.addEntropy((new Date).valueOf(), 2, "loadtime")
>try {
>    var s = new Uint32Array(32);
>    crypto.getRandomValues(s);
>    sjcl.random.addEntropy(s, 1024, "crypto['getRandomValues']")
>} catch (t) {}
>
>Meaning that if it's used someplace where crypto.getRandomValues()
>doesn't exist, it has only pure snake-oil-extract randomness.
>
>Really????

This is what the SJCL code does. I didn't write this. I believe the
getRandomValues call is in addition to all the entropy collection the
SJCL is doing elsewhere. But you've got a worthwhile point. I'm adding
instructions to my code so entropy collection gets done a lot more
often, every time the user clicks or releases a button.

>If the randomness is poor, the nonce used in ECDSA will be predictable
>and the private key will be recoverable.

Absolutely. It is essential that the RNG be flawless.

>This isn't to say I've audited any of it, I just grepped for a couple
>likely mistakes. Part of the JS code has been whitespace compressed, I
>consider it unauditable.

Thanks for bringing this up. This was because the qr.js code I added
was minimized. I've corrected that. Hopefully you can read the code it
now.


>>* up to a whopping*>>* 200,000 iterations for lousy keys. Since keys made in version 1.2 are no*>>* longer compatible, this prompts upping the version to 1.3.*>
>So, not implemented in slow-as-dirt JS 200,000 iterations should take
>a random desktop cpu about 100ms or so. This is hardly wopping. It's
>not far from the minimum I'd start with, for all keys not just weak
>ones.  Generally user provided keys are a security disaster and should
>be avoided wherever it's possible, strengthening or no. Humans are
>horrific entropy sources and really can't self assess how bad they
>are.

The web app has to be able to run on  a smartphone. 200k iterations require
more than a minute in an iPhone 4S. Totally unacceptable, which is why I
think this might entice users to select better passwords. The elliptic
curve multiplication needed to do anything with a private key is pretty
slow by itself, and it's always there. In that same iPhone, it is roughly
equivalent to 10k iterations, which take three seconds. Unfortunately,
using different iteration numbers depending on the platform would break key
compatibility.

Regards,

-- 
Francisco Ruiz
Associate Professor
MMAE department
Illinois Institute of Technology

PL13lok=WsH3zTgZn8V3hnIqjdbfPus+5YF5n+LBRPuH9USMMp8izPv+hsLoZKv+jaCFMapJFfiA11Q9yJU1K1Wo0TbjXK/=PL13lok

get the PassLok privacy app at: http://passlok.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.stanford.edu/pipermail/liberationtech/attachments/20130811/6b16530f/attachment.html>