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

Eugen Leitl eugen@leitl.org
Wed Aug 7 01:52:01 PDT 2013


----- Forwarded message from Gregory Maxwell <gmaxwell@gmail.com> -----

Date: Tue, 6 Aug 2013 15:39:29 -0700
From: Gregory Maxwell <gmaxwell@gmail.com>
To: liberationtech <liberationtech@lists.stanford.edu>
Subject: Re: [liberationtech] Tormail in trouble. Experts at Black Hat recommend Elliptic Curves: this is what PassLok 1.3 is based on.
Reply-To: liberationtech <liberationtech@lists.stanford.edu>

On Tue, Aug 6, 2013 at 3:20 PM, Francisco Ruiz <ruiz@iit.edu> 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/

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????

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

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.

> 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.
--
Liberationtech list is public and archives are searchable on Google. Too many emails? Unsubscribe, change to digest, or change password by emailing moderator at companys@stanford.edu or changing your settings at https://mailman.stanford.edu/mailman/listinfo/liberationtech

----- End forwarded message -----
-- 
Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org
______________________________________________________________
ICBM: 48.07100, 11.36820 http://ativel.com http://postbiota.org
AC894EC5: 38A5 5F46 A4FF 59B8 336B  47EE F46E 3489 AC89 4EC5



More information about the cypherpunks mailing list