[liberationtech] In defense of client-side encryption

[Francisco Ruiz]

@danimoth, sorry if this is duplicate. I'm re-sending this a different way
so it can be seen by all.

Thanks for the quick feedback. In there, you say,

>First, it is in Javascript. Who needs cryptography, SHOULD NOT use
>javascript. Google can help you ([1] for example, [2] if
>you are coming from a 48h non-stop no-sleep marathon).

I still have to read through the references you supply, but I can already
see a misconception. They refer to the dangers of carrying out cryptography
with javascript-containing dynamic pages. My previous posting referred to
_perfectly static_ pages, which are supposed to be always the same coming
from the server, not modified by the browser in any way, and which, in
fact, you can save and store somewhere safe and never again have to get
from the server. I believe the intrinsic security of this kind of
javascript code is no different from that of compiled code, which also
should be checked for tampering, so long as it uses standard functions that
are not likely to be modified in browser updates. Sorry about the confusion.

>Second, someone posted about your random number generator, and you
>ignored it. But this is a minor problem, as all things are in
>Javascript.

I did reply, and the updated PassLok includes improvements based on that
great piece of feedback. But perhaps it hasn't shown in the mail list
because I replied directly to the poster. I'm still trying to figure out
how to reply to a post on the daily digest.

The criticism is actually about how SJCL handles entropy collection. I hope
the SJCL developers will read it and respond to it.

-- 
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/9db32cce/attachment.html>