[liberationtech] In defense of client-side encryption

[Francisco Ruiz]

Thanks for a thoughtful and extensive reply. Let me see if I'm
understanding your position correctly. Running crypto code in a browser is
inherently insecure because we don't really know what the browser is doing
with it, regardless of whether it is communicating with a server. Of
course, we can't be sure of what a high-level OS is doing, either, but at
least it is one step closer to the hardware.

Faced with this uncertainty, it seems to me that making compiled code based
on NaCL still does not solve the basic problem that the user does not
control (and can't even view) the OS. Even if it is shown to be safe today,
there's no telling what an update might do to it in the future. Windows
seems to get "security" updates every other day; it would be trivial to
slip in one that undoes the security of a browser, as well as any
NaCL-based code. I'm saying this without knowing much about NaCL, but I
doubt it can withstand a malicious change in the OS.

So, trusting the OS but not trusting the browser seems to me a curious case
of double standard. They are made by the same companies, after all.

The only really secure cryptography, then, would be that which does not use
computers at all. Following this logic, I once made a stream cipher based
on a calculator. You can see the description here:
http://prgomez.com/nonfiction/crypto/17-crypto

I tried to extend this work to some sort of public-key functions, but
unfortunately calculators don't have the power needed to do the simplest
powermod operation on which to base a Diffie-Hellman scheme. And this
eventually led to PassLok, which uses the browser strictly as a powerful
calculator. Unfortunately, it is written in Javascript.

On Mon, Aug 12, 2013 at 5:12 AM, danimoth <danimoth at cryptolab.net> wrote:

> On 11/08/13 at 09:37pm, Francisco Ruiz wrote:
> > 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
> [cut]
>
> I catched the point about secure delivery of the code, this is an open
> problem and you suggested a youtube video with a spoken hash, assuming
> no one could modify it. In this topic branch, let's assume that problem
> resolved (but in others, specifically in the branch started by Guido
> Witmond, it isn't).
>
> Talking about syntax (and so, the programming language) you and Nadim
> are correct when sentencing "it's not a problem". I know, from my
> background, that every programming language will finish into assembly
> code, because it is the only one recognized by my CPU, so it isn't the
> node of the question. The really interesting thing is the environment
> where the code is executed, compiled, interpreted: in my point of view
> (but in many others) browsers aren't the best places to do critical
> things, because there a lot of points which aren't under our control. Is
> it Windows XP with a lot of mess installed? Is it a Linux Live CD? I
> don't know. Maybe the only way is throw away the entire technology stack
> and go back. But, if I need to choose between browsers and OSes, I
> choose OSes because they are closer to the CPU.
> You could have different vision, but please take it in consideration
> when presenting your product as the non-plus-ultra program of the year.
>
> Moving on the semantic aspect of the problem, I want to start saying my
> model in every crypto thing is NaCL library. Few of us (and few in the
> world) can safely play with little crypto bricks, joining them in new
> and fashion protocols. This is clearly not the way of reasoning of the
> majority of people: let's see for example the draft of Web Cryptography
> API..
> So, you had an idea: making the 20-year old PGP in a new and simple way,
> to permit inexperienced users to have the same functionality. You
> used little bricks (AES, elliptic curves..), and provided high level
> functionalities (Lock, Unlock, Stamp, Verify).
> What about reverting this paradigm, using NaCL experience as background,
> and so using something which already provides high level
> functionalities, focusing on user experience following your ideas (one
> simple place where doing all things, less buttons, less
> configurations..) ? And yes, this is only an interface problem, because
> you already have the background: GPG, NaCL, ...
>
> And don't think interface problems are trivial or stupid. They can make
> differences.. big differences.
>
> --
> Liberationtech is a public list whose archives are searchable on Google.
> Violations of list guidelines will get you moderated:
> https://mailman.stanford.edu/mailman/listinfo/liberationtech.
> Unsubscribe, change to digest, or change password by emailing moderator at
> companys at stanford.edu.
>



-- 
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/20130812/440ae1fa/attachment.html>