[messaging] EFF Insecure Messaging Scorecard

[carlo von lynX]

str4d, great news! You must have a great community following
since the crypto mainstream keeps disregarding I2P quite a bit,
me included. I still haven't made my mind up if garlic routing 
is a valid strategy, but all strategies are being heavily
questioned these days, and there's also always people who
criticize code quality.. but people used to criticize my code
for having too many #ifdef's, so I can imagine how superficial
such criticism can be. In any case I2P Bote does end-to-end
crypto plus hiding the traces of conversation also avoiding
central honey pots of store and forward, so in theory that 
qualifies it as a better solution than any other in the race.

On Mon, Nov 17, 2014 at 10:37:40AM -0500, Nathan of Guardian wrote:
> While I understand where you are coming from, and acknowledge the
> limitations in protocols like XMPP. I am also very excited about the
> extremely important work on next-generation systems and protocols like
> Pond, Secushare, and the like. I was very happy to see TheGrugq's port

Actually I come from Bitnet Relay and IRC.. then I had this idea of
making a federated chat system since I couldn't stand the oligarchy
implied in the architecture of IRC. PSYC was doing a great job at
that, ever since 1997, but unfortunately I was too perfectionistic
to open source it, so Jabber suddenly slashdotted out of nowhere.
PSYC turned out to be a great business however - whenever clients
needed a chat system that actually scales.

Around 2008 my co-devs started ranting at the hopelessness in
trying to architect a properly safe use of X.509 with federation.
We thought of certificate pinning, which led to the side project
that implements certificate pinning for Firefox, but ultimately
overthrew the entire federation architecture after understanding
that things like GNUnet, I2P, Retroshare and Tor actually work
and remove the necessity for insecure and administration-intensive
servers. The advent of virtualization ultimately killed off any
hope concerning the safety of servers: VPS are cheap and insecure
as hell, and you never know if your high security conversation partner
is corrupted because she has her account on one of those cheap VPS.

So, that is where I'm coming from. I've been THROUGH all that.
I have thrown away a piece of software I invested ten years in,
because the architecture is wrong: it is designed to run on servers.

I have the impression some people would rather not swallow the bitter 
pill that what they have been doing the past ten years has been 
obsoleted by technology - and that sort of thinking is keeping many
of us from moving forward. From my analysis of current technology I
must conclude that working for federation today equals working against 
the benefit for humanity, because it isn't even a reasonable in-between
step. It's just plain wrong.

> of Pond to Android, and with the years work on systems like Briar coming
> to fruition, I do think we are about to take a big step forward on
> protecting mobile metadata.

grugq's mobile Pond is also great news, although as usual
people will be too lazy to set up their own servers, thus they
will end up on honey pot servers which make de-anonymization
by traffic shaping a lot easier. So from my current analysis
Pond scores second to I2P Bote, but my evaluation may be too
simple considering all the other things Pond does (I recommend
ioerror's video presentation on http://youbroketheinternet.org
to learn about Pond properly).

Yes, Briar is a neat design that we should support. It has an
opportunistic distribution strategy like Retroshare, but for
smallish working groups that is perfectly sufficient. The
way it does not strictly depend on the Internet is epic.

With Briar a group of kids in a classroom has a better chance
of forming a constitutionally protected political opposition
group than, for example, the members of this mailing list.
I bow to Briar for contributing to democracy, although I
frequently disagree with Mike's views on current priorities.  ;)

> The EFF was focused on helping mass market users they can reach with
> taking the first step up from insecure SMS and messaging that offers
> basically no defense at all from a variety of bad actors. They need to
> offer apps available today that a had a history of being maintained and
> updated (Moxie, Nadim and I have been at this awhile now), and could
> offer good user experiences to even novice users. I also know this is
> only the first step in a process for EFF, and that I hope they will be
> open to feedback such as you have provided.

I can only hope that these "mass market users" will be willing to move
on to safer technologies as they become available, not get stuck for
all times on something that was given to them as Snowden compliant.
By referring to Ed, the website kind of makes that claim, while it 
completely ignores THE Snowden HOPE-X criterion: metadata protection.
Somebody please fix that. Somebody please admit how metadata is a huge
problem that those tools aren't fixing. ChatSecure at least tries it
in several ways (see below), although the 0.0.11 version I have doesn't
show any of those.

In theory encryption is better than nothing, but if metadata is the
actual meat of the conversation rather then the love and kisses inside,
and if encryption keeps people from solving the metadata problem, then
encryption is doing harm in detracting atention from the main issue.

I have mixed feelings about IAB focusing on encryption but ignoring
metadata, which is completely in accordance with what government agencies
want us to do. They want us to only do encryption. But leaving metadata
unattended is a threat to the stability of democracy.

It may sound radical, but maybe EFF would do humanity a better job if
that web page was empty and there was only a download button for I2P Bote.
Then instead of asking all companies to audit their irrelevant proprietary
play things, get them to audit the only properly distributed messaging
system we seem to be having for mobile platforms.

> I would like to point out some particular features of ChatSecure that do
> combat and minimize metadata-based surveillance. I think Cryptocat, by
> its transient nature, also has some of these characteristics. You might
> dismiss them as band-aids, but we see them as practical defense-based on
> what is available today. 

Oh yes, I am notable for dismissing band-aids, but I understand the
motivation.

> 1) One-tap use of Tor, which both means the ability to circumvent
> network surveillance by our WISP/Telco, and the ability to connect to
> Tor Hidden Service hosted XMPP servers. This is why EFF mentioned
> "ChatSecure + Orbot"

Yes, that is great stuff... I understand we all didn't fully realize
that just because a popular server has a hidden service address it
is still very de-anonymizable and that by traffic shaping the return
traffic (once you get reasonably close to where the server is hosted)
I presume you can also de-anonymize the users of such popular servers.

If you do traffic shaping long enough, you should be able to
figure out who is talking to whom, so metadata is slowly dismantled.
Still, it is a lot more effort than doing encryption only, so this is a
great step forward from regular TLS/PGP. But I2P Bote has a distributed
architecture for the store & forward, so it is IMHO less susceptible
to de-anonymization and metadata reconstruction.

Last year, when getting funding from the Wau Holland foundation, we
joked that one of the aims would be to get secushare to the point that
we can stop having to finance and operate jabber.ccc.de because we would
tell the users to migrate to a more secure platform. Unfortunately we
need more attention to get there.

> 2) Support for multiple accounts and in-app creation of accounts on any
> server you choose, over Tor if you choose, and offer a built-in list of
> geographically diverse, vetted XMPP hosts. Maintaining multiple

Multiple identities still do not cut it if the client logs them all
in in the same instant. It's easy for an observer to deduce that
they all belong to the same person if the same pattern is observed
each day, day-in day-out. Clients would at least need to employ random 
delays. Also you should probably influence Orbot to use seperate circuits 
even when all accounts are on the same server.

> identities is meant to be easy to. This also means anyone can run a
> server based on open-source/free software, and using our Lil' Debi (our
> Debian-on-Android system), a more experienced user can run an XMPP
> server on a phone or tablet inside a Hidden Service. 

Good, that is an architecture that avoids large popular servers.
This is almost like TorChat or Retroshare+Tor, but having an entire
server platform is actually much more complicated. Dedicated software
designed to deal with P2P interaction is simpler to deploy than
re-architecting federation for P2P use. It's also slicker and cleaner
as it gets rid of all the legacy DNS and X.509 code.

The only problem remaining with this sort of architecture is that 
hidden services are currently enumerable, so the agencies may routinely 
start opening circuits to it, just to find out who is running that service.

> 3) Support for a secret identity/burner account that generates a
> randomly named account on a Tor HS based server (Calyx) that only
> supports OTR-encrypted messaging and does not log. This can be used for
> communicating with only one contact, ideally using the same app and
> method to connect, such that the buddy list only shows one contact.

That's pretty neat. Now we need many many such servers and a fix for
Tor to not have the agencies figure them out and run traffic shaping
attacks on them. If everyone just uses one Calyx, they can routinely
use the same analysis software they already developed for jabber.ccc.de.

As a side note, if you use a different jabber server, then talk to
people on other servers, you are using XMPP federation which is even
more likely to expose your metadata than having all your contacts on
a central server. But that is why people are making these single
contact servers.. a smart idea! The less XMPP you use, the better.

> 4) Full encryption of all account data, messages, contacts and shared
> media data on the device and no integration with built-in contact lists
> on the phone, to stop any leak of data from the ChatSecure environment
> into your phones unencrypted/insecure storage. When thinking about
> mobile, you must also consider metadata physical extraction, as well as
> inherent insecure of the OS services themselves.

Ok, that sounds reasonable considering that we are putting sensitive
applications in a completely hostile environment. To me the way
smartphones function is anti-constitutional anyway, that's why we
wrote a proposal to regulate them. In the architecture proposed by
the law proposal you would not need to take these extra steps since
the device would not legally be a hostile environment.

> 5) No requirement for using your actual phone number or device
> identifiers, and no integration/dependency upon Google Cloud Services
> (push, etc).

Yes, that too is inhibited in our law proposal. But for current
real life conditions, it is good you wrote ChatSecure this way.
Thank you a lot in any case. I appreciate, even if I'm a perfectionist.

> > I know very well that they are all experimental,
> > but it is irresponsible not to openly say: Sorry people,
> 
> What do you mean by experimental?

Whenever I mention Pond, GNUnet, Retroshare or I2P, PGP advocates
say that is experimental stuff. I chose not to deny that bit.
Still I'd rather use something experimental that may de-anonymize
me if it fails, rather than something which isn't anonymous already.
It's like saying I'm not using the bike because the chain may break.

> > there IS no well established and stable messaging system
> > that will actually protect you as it should. All we can
> > offer are tools that will protect what you talk about,
> > not you as a person.
> 
> Yes, I agree that is generally true, but I do hope that you appreciate
> the work we've done in minimizing metadata leakage.

Yes, thank you for the effort spent. I know it must be a very
Sisyphussian sensation when you work on something as advanced
as Calyx and then find out that it is still de-anonymizable
because it is still too much thinking in client/server terms.

I must say that I feel better not trying to work on low-hanging
fruit. Each time you try, you find out that the fruit isn't so
low after all, and once you're done you find out the threat
scenario has already become worse.

Chasing low-hanging fruit is a race we can't win. We must all
focus on doing the best imaginable architecture - no shortcuts,
no cheap tricks, no band-aids. Only then we have a chance of
winning the race. MHO.

And, ironically, we have never been so close at actually being
able to deploy a "GNU Internet" as some of us call it. I believe
doing the right thing is the lower hanging fruit than band-aiding
the broken Internet.


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