Le 19/07/2014 11:13, carlo von lynX a écrit :
On Fri, Jul 18, 2014 at 7:59 AM, Lorenzo Franceschi-Bicchierai
<lorenzo...@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
--
Liberationtech is public & 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.
