On 12 August 2013 06:14, Ximin Luo <infini...@gmx.com> wrote: > 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.
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 > compa...@stanford.edu. -- 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.
