[liberationtech] Snakeoil and suspicious encryption services

[carlo von lynX]

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.

Too much effort really. It's easier to document the technical criteria
for judgment. There are three general categories: projects that look for
real long-term solutions, band-aids for the time being (although they
frequently think of themselves as solutions) and ultimately snake-oil humbug,
although there is no clear separation line between band-aids and snake-oil.

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.

Everything that tries to insist on using insecure technologies such as
X.509, DNS, DANE can at best be a band-aid. Everything that tries to
put encryption on top of SMTP, XMPP, HTTP instead of underneath, is
vulnerable. If it's not vulnerable technically, it is by usability.

If you really really make no mistakes, then PGP and similar tools will
allow you to have a secret conversation, but none of this stuff properly
protects who is talking to whom. And there is a further trade-off, if the
end-to-end encryption is only granted to you by a server that sends you
the suitable javascript code and you are somehow supposed to trust it.

So from a suitably radical perspective (can we afford anything less?)
many even respected projects are more close to snake-oil than actually
useful at protecting us from the pervasive active adversary we are
confronted with. Why insist? There are many projects designed in a
more secure way.


On Fri, Jul 18, 2014 at 08:32:36AM -0700, Steve Weis wrote:
> Somewhat relevant, I recently gave a talk about "Crypto Projects that
> Might Not Suck":
> http://saweis.net/pdfs/CryptoMightNotSuck-2014.pdf

I don't really understand these slides. There is a confused mix of
libraries that could of course be used properly or not, then many
band-aids and a few recommendable things and there is no differentiation
between tools that protect metadata such as Tor and Pond and all the
rest that merely tries its best to achieve end-to-end encryption.

Combining PGP/SMTP with Tor only works if all participants use
pseudonymous mail accounts, hardly anyone does - even then, one 
small mistake can deanonymize you and having a social graph too
similar to your regular mail account might, too. Pond and I2PBote 
are way ahead concerning this, providing mail systems that protect
the social connections, and since all participants have to upgrade to
be safe, why are we still talking of solutions that use the old
broken Internet?

OTR works well for encrypted communications if we didn't fail to
activate it and respected the bureaucracy of ensuring its accuracy.
But even if we didn't fail in that, we still entrust servers with
the knowledge of our social graph. To avoid that, chat systems that 
use hidden services are better - but then there is no reason to insist
on XMPP and OTR as invisible.im does: Tor already provides end-to-end
and forward secrecy, circuits are reestablished all the time. OTR is
redundant in this case.

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.

-- 
	    http://youbroketheinternet.org
 ircs://psyced.org/youbroketheinternet