[liberationtech] In defense of client-side encryption

[Francisco Ruiz]

Hi Steve. I want to thank you for taking your time to help me. Your
comments are awesome. May I follow up with some short questions, right
after some of your comments?

Many thanks in advance.

On Mon, Aug 12, 2013 at 7:18 PM, Steve Weis <steveweis at gmail.com> wrote:

> Francisco, you assume that all browsers will save a static version of the
> page identically. This is not the case.
>
> I ran a test using 'wget https://passlok.site44.com' and Chrome's "Save
> As". The former will actually match the hash value you've posted, but the
> latter does not.
>
> I spotted at least 5 differences in Chrome's saved output:
> 1. Unicode: wget returned escaped Unicode characters. Chrome saved output
> containing actual Unicode characters. Your suggested method of cutting from
> view-source and pasting into a text editor may be unpredictable, and
> dependent on a user's OS and locale.
>

I think the Unicode characters got in when I added the qr.js code, which
had comments  in Korean ;-) Do you think it's maybe best to get rid of
anything that is not strict ASCII? The code doesn't need any special
characters.


> 2. Relative link re-writing: wget returned relative links. Chrome replaced
> them with absolute links, so that links work locally.
>

I've toyed with the idea of making absolute the couple relative links in
there: the png for making a mobil icon, and the help page. Maybe it's
better if they are absolute so the browser doesn't change them, uh?


> 3. Whitespace: Chrome stripped out some whitespace.
>

I've tried to make super-sure that the code has no leading and no trailing
spaces or linefeeds, so maybe wget is adding spaces?

4. Style rewriting: Chrome replaced some style elements like
> "background-color: #FFA0A0" with "rgb(230, 255, 230);".
> 5. Chrome extensions: I have locally installed extensions that modify page
> contents, e.g. AdBlock and DoNotTrackMe. My locally saved copy of Passlok
> had elements that were injected into it by some extensions.
>
> Any of these will break your manual hash validation. These are specific to
> my version of Chrome, but other browsers may alter saved content similarly.
>

I've spent a lot of time making the code run nice and polishing the user
interface. I didn't suspect code validation was going to be this difficult.
Truth is, most users are never going to bother with validating the code,
but a few will care intensely about this.


>
> To work, you must assume that your user has a local client (say wget or
> curl) that can save a canonical copy of your page without modification.
> Browsers do not guarantee this. Then you must assume the user has a locally
> installed tool to compute the hash, like sha256sum or openssl. Then they
> would need to point their browser at the locally downloaded file to
> actually use it.
>
> If you depend on locally installed software outside the browser and use
> local storage, the user is better off just using locally installed software
> to do the crypto.
>
> PS - I noticed some oddness glancing through the source. For example, the
> makepub() function strips 6 bits of a Base64-encoded leading 0 for no
> apparent reason. The rest of the code has to remember to keep adding back
> in the missing Base64 character or else it will break. The only reason I
> can think of someone doing this is because they didn't understand why the
> randomly generated Base64 value always started with 'A'.
>

Ah, you saw that. It's the elliptic curve output. SJCL handles points and
exponents as complex recursive objects. In order to display them for the
user, I extract the data and convert it into base64. For reasons that I
don't fully understand (probably having to do with 521, the true bit length
of the elliptic curve numbers, not being divisible by 6), those strings
always start with "A". Since I intensely dislike displaying supposedly
random-looking strings that always begin with the same character, I strip
it, but instruct the functions that read those strings from the interface
to add it again before they do any calculations.

Thanks again, Steve!


>
> On Sun, Aug 11, 2013 at 7:37 PM, Francisco Ruiz <ruiz at iit.edu> 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, 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.
>>
>>
> --
> 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/20130813/f54136e4/attachment.html>