[liberationtech] In defense of client-side encryption

[Ben Laurie]

On 12 August 2013 06:14, Ximin Luo <infinity0 at gmx.com> wrote:
> On 11/08/13 22:28, Nadim Kobeissi wrote:
>>
>> On 2013-08-11, at 10:36 PM, danimoth <danimoth at cryptolab.net> wrote:
>>
>>> On 11/08/13 at 01:10pm, Francisco Ruiz wrote:
>>>> Twice again, privacy has taken a hit across the land. Lavabit and Silent
>>>> Mail are gone, and to quote Phil Zimmermann, “the writing is on the wall”
>>>> for any other encrypted email provider located in US territory. This is
>>>> sure to be repeated for servers located in Europe and other countries. Is
>>>> this the end of encrypted email?
>>>
>>> [cut]
>>>
>>> IMHO you are making big statements, taking a lot of risks, and a lot of
>>> people's life on your back, as we're not playing here. Are you sure to
>>> have big enough shoulder?
>>>
>>> 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).
>>>
>>> Second, someone posted about your random number generator, and you
>>> ignored it. But this is a minor problem, as all things are in
>>> Javascript.
>>>
>>> Third, you use Javascript. But, wait, I need to sleep. Please stop
>>> spamming an insecure-by-design product.
>>
>> I think it's a bit short-sighted to criticize encryption because of the programming language it's implemented in. JavaScript encryption doesn't have problems because of the programming language, but because of the APIs, environment and mechanisms surrounding the language.
>>
>> I've investigated many of the challenges surrounding proper implementation in those contexts, and have written a blog post to this effect. I would be interested in hearing some feedback! http://log.nadim.cc/?p=33
>>
>
> How is it possible to defend against timing attacks in JS? Any language theoretically can be complied into anything, but the JS runtime does not give you much control in what the CPU actually executes. The webcrypto WG you linked to looks interesting, if browsers will provide a native crypto API to JS, preinstalled (at least the mathy bits that you need direct execution control over) as opposed to loaded on-demand by a remote server. Did you ever think about having the cryptocat browser extension using a lower-level language? Firefox at least can run binary extensions; I don't know about Chrome.

It is possible to defend against timing attacks by writing inherently
constant time code. For example:

https://github.com/openssl/openssl/commit/a693ead6dc75455f7f5bbbd631b3a0e7ee457965

is full of such code.


>
> Also I'll note that "investigate many" is not sufficient to have security confidence; you have to "investigate all" - i.e. enumerate all parts that can be compromised, and argue convincingly that you haven't missed anything. This involves knowing the JS spec and browser implementations very very well.
>
>> NK
>>
>>>
>>> Last thing: People, please, use PGP instead of these circus things.
>>>
>>>
>>> [1] http://www.matasano.com/articles/javascript-cryptography/
>>> [2] https://www.google.it/search?q=why%20is%20bad%20crypto%20javascript
>>>
>
>
> --
> GPG: 4096R/1318EFAC5FBBDBCE
> git://github.com/infinity0/pubkeys.git
> --
> 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.