[liberationtech] Security / reliability of cryptoheaven ?

[Maxim Kammerer]

On Tue, Oct 9, 2012 at 2:24 PM, Jacob Appelbaum <jacob at appelbaum.net> wrote:
> This is an interesting observation - it is a self-selecting user base -
> it is easy to use as long as you know 0) how to make a bootable disk, 1)
> you know how to decide if your computer supports it, 2) it does support
> and it all loads properly and 3) everyone you care to communicate with
> also fits that model.
>
> We have seen with Tails that the 0-2 is rare except in groups where 3)
> is really very solidly true.

I tend to think that locating appropriate technical solutions and
absorbing the required educational materials is a responsibility of
the userbase. Once someone is willing to actually extend the effort
(which is a non-trivial assumption, as there is no shortage of people
who expect to be babysitted after professing lack of relevant
knowledge), and as long as the tasks to be performed are relatively
simple, there is no shortage of detailed guides, especially in
communities that recognize the need for anonymity, for instance.

Moreover, simple tasks tend to become simpler with time. E.g., taking
the bootable disk example, the task is often problematic for
non-experienced users, as many things can go wrong during the process
of making the media actually bootable. With UEFI, however (despite the
frequent FUD), everything becomes simpler — the user only needs to
extract a .zip archive into the USB key root.

> I personally think the cables design in Liberté is really quite
> interesting. If it was possible for Tails to support it and for other
> chat programs to support it as well, I think we could shift the burden
> presented above and it would help to attract a different user base.

I would certainly like to see cables used in many different contexts.
I intend to eventually transform the MUA side interface to SMTP, and
rewrite remaining shell scripts in C, in order to make integration in
other projects easier, including non-Linux environments (the interface
right now is a script, sudo-invoked if one desires a separate cables
account, that accepts the message on stdin).

> Then there is stuff like NameCoin and other designs. Ultimately, I think
> we agree that no solution is worth the security trade offs as of yet. I
> think it isn't a totally lost cause for private groups that run their
> own servers or some kind of TOFU bootstrapping model.

I agree that there is currently no good option for recognizable names.
I dislike BitCoin-like designs, because they are heavy (in the sense
of requiring continuous waste of resources just to maintain the
system), and are cumbersome to use. I.e., imagine a new user who has
just installed an anonymous communication package, and who then
discovers that in order to get a short alias they need to either buy
some expensive mining hardware, or to spend some potentially traceable
virtual currency. Even Google's method of relying on a scarce resource
during registration (access to a phone number) starts to look better,
especially if you are in a country where cellular phone companies
didn't yet manage to form a cartel, and where buying a SIM card
without tying it to a government ID is not hard (e.g., I think that in
Russia one can buy a SIM card with quite a few minutes on it from
dealers on the street for ~5 USD in cash).

> Imagine an OTR extension that allows you to pass your .onion address
> over an authenticated jabber/aim/whatever session - now you can meet
> again on a decentralized system. You'll also already have the
> username/alias/realname in the chat client, I think.

That would be great, although I think that the extension should
explicitly require authentication of the contact, which is currently
optional, as far as I remember.

> Another useful thing is a dynamic, cryptographically secured but time
> limited, federated meeting protocol. I've been working on such a
> protocol and I hope to finish it before the end of the year. If you'd
> like to talk about it, I bet we could put it and cables together for
> something quite usable.

Sure, I would be glad to collaborate — feel free to ping me once you
want to discuss further, or get feedback on the design.

> Solving the problems presented are pretty easy - if users explicitly
> want security *and* another goal - such as an easy to remember name -
> they must understand that currently, we have no way to satisfy both
> safely. Users can't always get what they want but perhaps there are
> better ways to communicate that issue?

I think that one of the underlying complexities here is that while
users are in general aware of the concept of security-usability
tradeoff, they generally incorrectly estimate where they should place
themselves on the tradeoff axis. E.g., a political activist in the US
is often fully aware of state surveillance capabilities, expects all
his communications to be inspected, is (relatively) technically
educated, and will attempt to use top-of-the-line technology and
software to protect himself from black helicopters. However, the most
he can expect (unless doing something explicitly illegal) is some
harassment at the border. A political activist in UAE (taking a recent
example posted on this mailing list) knows that his country is
incapable of sophisticated US-style mass surveillance, and does not
pay too much attention to computer security, besides some simple
guidelines. Then, his country deploys the most sophisticated
individual surveillance technology money can buy against him, and he
is beaten and/or killed after being confirmed as a danger to the
regime. Maybe if he knew this could happen, he wouldn't use regular
non-authenticated and non-encrypted email at all?

-- 
Maxim Kammerer
Liberté Linux: http://dee.su/liberte