On 11/08/13 22:28, Nadim Kobeissi wrote:
> 
> On 2013-08-11, at 10:36 PM, danimoth <danim...@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.

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 
compa...@stanford.edu.

Reply via email to