[liberationtech] Snakeoil and suspicious encryption services

[Aymeric Vitte]

Le 19/07/2014 11:13, carlo von lynX a écrit :
> On Fri, Jul 18, 2014 at 7:59 AM, Lorenzo Franceschi-Bicchierai <lorenzofb8 at gmail.com> wrote:
>>> I was wondering if it's time to make a list of not-so-good snakeoil
>>> encryption services that have popped up after the Snowden revelations.
>
>
> Let's look at the long-term solutions. We keep a map of them on
> http://youbroketheinternet.org - anything that uses public-key routing
> instead of trying to put a band-aid over the existing Internet is in it.
> Everything that has a chance of protecting metadata is there.

You should add the Peersm project [1]


> Browser crypto is an oxymoron. As long as the browser has no way to 
> verify that credibility of the code, the entire architecture is snake 
> oil. Some folks are producing add-ons that verify JS crypto code by 
> PGP signatures, but those are special solutions that expect you to 
> trust certain PGP keys. A redo of the certification system. Band-aids. 
> You may do the crypto directly in your add-on, but that won't protect 
> your social graph. If you want a safe web, you should go the way of 
> cjdns, Tor, GNUnet, I2P: The content was delivered with end-to-end 
> encryption underneath, so you don't need to worry about encryption on 
> the upper layers such as the web browser. Any .onion site is more 
> secure than browser crypto (if your aim is to talk to the owner of 
> that .onion). Using browser crypto with end-to-end hidden services is 
> redundant. The slides are entirely missing out on distinguishing 
> public-key routing infrastructures such as Tor, I2P, GNUnet, cjdns etc 
> from the traditional encryption-on-top-of-broken-routing technologies. 
> The latter are by design all band-aids or snake-oil. Thus, your slides 
> are missing out on most of the interesting projects happening. Crypto 
> is not just about the algorithms. It's also about where you apply 
> them. Best regards. 

Sorry, while some statements here are correct you give a totally wrong 
conclusion about crypto inside browsers.

Let's take the Peersm project, it's all about crypto inside browsers, 
javascript modules for now and maybe WebCrypto later.

Unlike obscure elefantesque open source code that you don't even know 
what it becomes when it gets compiled, it's trivial to see what it is doing.

So Peersm is a monolithic js code app, monolithic so you don't load tons 
of potentially insecure modules, it does not use neither rely on any 
plugin/add-on, for always the same reason: you must be able to check 
precisely what the app is doing.

But of course you must load the code at a certain point of time, I am 
not going to reexplain why the main page of Peersm is not using https, 
this will anyway not secure the code loading, this part can be insecure 
and whatever the specifications groups are inventing to solve this, you 
can minimize the risk but not eliminate it unless you have a way to 
check the code with different third parties and different communication 
channels.

The easy fix for this is to package Peersm as a standalone app and run 
it locally [2]: you load the page locally (images, css, etc) and you 
inject the js code (after you have verified using different sources that 
the code that you have is the right one), you do not load anything from 
the outside (except peers and Tor/Peersm bridges details, but this too 
you can handle it locally if you like). This package is not available 
right now because of some lack of time and because it does not present 
any issue from a technical standpoint (so we focus on other issues like 
the final phase, do not even check the hash in [2] it's not up to date), 
it will for sure not be a plugin/add-on, just a package with a short 
explaination how to use it.

Then please tell me what threat the app sould be afraid of, there are 
none, if we go further in the paranoia the only threat is a physical 
attack on your device, so if you do stupid things you can hack yourself, 
if someone else gets access to your device it can hack inside the app 
without you knowing about it, but even this is difficult the way the 
code is sandboxed, another layer could be added like complete DOM 
sandboxing using Caja principles but this seems really too heavy given 
that a physical attack is your problem, not the one of the app.

 From my standpoint it's more secure than anything else, because you do 
not install anything that can get access to your device, what you 
"install" is inside browsers, you can check in a determist way what it 
is and what it is doing, it can not access anything on your device not 
authorized by the web and yourself, it does not load anything from the 
outside that is not secure by the app.

Peersm concepts can be challenged, I am still surprised that on this 
list and others the wrong ideas of insecure browser, js, nodejs keep 
propagating and that the uses are systematically disregarded.

Regards

[1] http://www.peersm.com (current phase) and (final phase) 
https://github.com/Ayms/node-Tor#anonymous-serverless-p2p-inside-browsers---peersm-specs
[2] https://github.com/Ayms/node-Tor/tree/master/min

-- 
Peersm : http://www.peersm.com
node-Tor : https://www.github.com/Ayms/node-Tor
GitHub : https://www.github.com/Ayms