Re: [Cryptography] Summary of the discussion so far

2013-09-14 Thread Max Kington

On 13 Sep 2013, at 21:46, Nico Williams wrote:

 On Fri, Sep 13, 2013 at 03:17:35PM -0400, Perry E. Metzger wrote:
 On Thu, 12 Sep 2013 14:53:28 -0500 Nico Williams
 n...@cryptonector.com wrote:
 Traffic analysis can't really be defeated, not in detail.
 
 What's wrong with mix networks?
 
 First: you can probably be observed using them.  Unless too many people
 use mix networks you might just end up attracting unwanted attention:
 more passive surveillance, maybe even active attacks (at the limit very
 physical attacks).

I do wonder what the problem with being observed using it is though.  I
understand the problem and the want to not have traffic analysis done
on your communications but what's the practical effect on your communications
if they are?

If I think about what I'm bothered about.  I do work part-time for an arm of 
government.  I don't like the idea that someone is out there with a big 
ear-trumpet
recording all my communications.  I like to be able to discuss the rights 
wrongs of mass surveillance but at the same time I don't want to be labelled
a dangerous subversive.  I like to have a moan about things I dislike but 
I don't want those to re-appear at some meeting where I'm called in for
a meeting, hat on, without coffee.  At least not where I've not been compelled
to produce them (at least I know what's coming!).  So privacy on the messages 
is important to me but not
necessarily is it of *equal* importance that my communications partners are 
hidden.  I might swap emails
with Ben, Ben likes a good moan too, we both work for the same branch. 
The fact that I work with Ben and talk to him is neither here nor there.

For example, Hemlis is taking on the problem of obscuring traffic with regards
to the 'who' you're talking to and not just the 'what'.  I wonder how important
that is, really, especially when they're talking about centralised control of 
user information to ensure security, but haven't addressed what happens 
when they're compelled to help people game their own system (the it's ok, we'll
go to prison before we help the spooks I always find a bit weak, what if they
turn up with a car battery and a pair of pliers?) It's not clear how they're 
going to do 
any of this yet.  All in all they seem to have good intentions but I fear 
they're falling
into the trap of trying to solve the 'interesting' problems as a priority 
without having
a consistant plan.

I'm sure they'll come up with some sort of mix network.


 
 Second: I suspect that to be most effective the mix network also has to
 be most inconvenient (high latency, for example).  That probably means
 mix networks won't be popular enough to help with the first problem.

As Perry points out in his August posts, latency is less important although
for instant messaging traffic people do kind of want 'instant' for a low enough
value of latency.  The latency though is only of massive importance if it's 
critical
that who you talk to be obscured as well.  If you have *some* idea
of the people in a network who are communicating with each other there
also needs to be enough bandwidth to hide your messages in, as you're 
probably already observing the traffic close (or fairly close) to the endpoint
it's being delivered to.  

I took an approach in the system that I built of batching messages together
inside an encrypted bundle and padding them with junk so that you got a 
message every x minutes or x seconds and it was always at least y 
size regardless of if there was anything in it for you of 
interest or not.  If messages were over y size, they split and queued up for 
the next interval.

 
 Third: the mix network had better cross multiple jurisdictions that are
 not accustomed to cooperating with each other.  This seems very
 difficult to arrange.

Specifically on the jurisdictional point:

I've looked into this, I did some research into cloud providers in different 
jurisdictions.  After all if it's going to scale you're unlikely to be building 
data 
centres on the way to the system becoming successful.  It is possible that
you don't actually need to go to the extremes of routing stuff via Russia, China
Egypt and Pakistan.  I've got another discussion on another list about what
entities that are allowed to co-opoerate can actually do on behalf of each 
other. 
It turns out there is an interesting disconnect between Irish law and the UK law
(I picked Irish law because Amazon's european operations are in Ireland)

You have to decide if you are worried about co-operation as allowed by law 
or not for the jurisdiction you're in, i.e. are you going to go to prison or 
not.

The main instrument of cooperation here is a thing called an MLAT, a mutual
legal assistance treaty and they're signed with an awesome number of countries.

They only enable cooperation to the extent that local law allows and have 
different
rules about support that allows evidence that can be admissible in court and 
other
kinds of support.

So it comes back to 

Re: [Cryptography] Summary of the discussion so far

2013-09-13 Thread Nico Williams
On Wed, Sep 11, 2013 at 04:03:44PM -0700, Nemo wrote:
 Phillip Hallam-Baker hal...@gmail.com writes:
 
  I have attempted to produce a summary of the discussion so far for use
  as a requirements document for the PRISM-PROOF email scheme. This is
  now available as an Internet draft.
 
  http://www.ietf.org/id/draft-hallambaker-prismproof-req-00.txt
 
 First, I suggest removing all remotely political commentary and sticking
 to technical facts.  Phrases like questionable constitutional validity
 have no place in an Internet draft and harm the document, in my opinion.

Privacy relative to PRISMs is a political problem first and foremost.
The PRIM operators, if you'll recall, have a monopoly on the use of
force.  They have the rubber hoses.  No crypto can get you out of that
bind.

I'm extremely skeptical of anti-PRISM plans.  I'd start with:

 - open source protocols
 - two or more implementations of each protocol, preferably one or more
   being open source
 - build with multiple build tools, examine their output[*]
 - run on minimal OSes, on minimal hardware [**]

After that... well, you have to trust counter-parties, trusted third
parties, ...  It get iffy real quick.

The simplest protocols to make PRISM-proof are ones where there's only
one end-point.  E.g., filesystems.  Like Tahoe-LAFS, ZFS, and so on.
One end-point - no counter-parties nor third parties to compromise.
The one end-point (or multiple instances of it) is still susceptible to
lots of attacks, including local attacks involving plain old dumb
security bugs.

Next simplest: real-time messaging (so OTR is workable).

Traffic analysis can't really be defeated, not in detail.

On the other hand, the PRISMs can't catch low-bandwidth communications
over dead drops.  The Internet is full of dead drops.  This makes one
wonder why bother with PRISMs.  Part of the answer is that as long as
the PRISMs were secret the bad guys might have used weak privacy
protection methods.  But PRISMs had to exist by the same logic that all
major WWII powers had to have atomic weapons programs (and they all
did): if it could be built, it must be, and adversaries with the
requisite resources must be assumed to have built their own.

Anti-PRISM seems intractable to me.

Nico

[*] Oops, this is really hard; only a handful of end-users will ever do
this.  The goal is to defeat the Thonpson attack -- Thompson trojans
bit-rot; using multiple build tools and dissassembly tools would be
one way to increase the bit-rot speed.

[**] Also insanely difficult.  Not gonna happen for most people; the
 ones who manage it will still be susceptible to traffic analysis
 and, if of interest, rubber hose cryptanalysis.
___
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography


Re: [Cryptography] Summary of the discussion so far

2013-09-13 Thread Perry E. Metzger
On Thu, 12 Sep 2013 14:53:28 -0500 Nico Williams
n...@cryptonector.com wrote:
 Traffic analysis can't really be defeated, not in detail.

What's wrong with mix networks?

Perry
-- 
Perry E. Metzgerpe...@piermont.com
___
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography


Re: [Cryptography] Summary of the discussion so far

2013-09-13 Thread Perry E. Metzger
On Fri, 13 Sep 2013 15:46:58 -0500 Nico Williams
n...@cryptonector.com wrote:
 On Fri, Sep 13, 2013 at 03:17:35PM -0400, Perry E. Metzger wrote:
  On Thu, 12 Sep 2013 14:53:28 -0500 Nico Williams
  n...@cryptonector.com wrote:
   Traffic analysis can't really be defeated, not in detail.
  
  What's wrong with mix networks?
 
 First: you can probably be observed using them.

Sure, but the plan I described a few weeks ago would presumably end
with hundreds of thousands or millions of users if it worked at all.

 Second: I suspect that to be most effective the mix network also
 has to be most inconvenient (high latency, for example).

Sure, that's true for voice and such. However, for messaging
apps, that's not an issue. See my claims here:
http://www.metzdowd.com/pipermail/cryptography/2013-August/016874.html

(That was part of a three message sequence that began with these two:
http://www.metzdowd.com/pipermail/cryptography/2013-August/016870.html
and
http://www.metzdowd.com/pipermail/cryptography/2013-August/016872.html

but only the second of those two is really relevant to this
particular discussion.)

 Third: the mix network had better cross multiple jurisdictions that
 are not accustomed to cooperating with each other.  This seems very
 difficult to arrange.

That's important for onion networks, not mix networks. I understand
that the distinction isn't well understood by most, but it can be
summarized thus: an onion network depends on no one observing the
whole network to provide security, while a mix network uses
sufficient cover traffic and delay induction to prevent people from
being able to learn much even if they can observe the whole network
and control a minority of nodes.

Perry
-- 
Perry E. Metzgerpe...@piermont.com
___
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography


Re: [Cryptography] Summary of the discussion so far

2013-09-11 Thread Nemo
Phillip Hallam-Baker hal...@gmail.com writes:

 I have attempted to produce a summary of the discussion so far for use
 as a requirements document for the PRISM-PROOF email scheme. This is
 now available as an Internet draft.

 http://www.ietf.org/id/draft-hallambaker-prismproof-req-00.txt

First, I suggest removing all remotely political commentary and sticking
to technical facts.  Phrases like questionable constitutional validity
have no place in an Internet draft and harm the document, in my opinion.

Second, your section on Perfect Forward Secrecy ignores the purpose of
PFS, which has nothing to do with defense against cryptanalytic attacks.
The purpose of PFS is this: Should an attacker compel you to disclose
your private key, or should they compromise or confiscate the system
where your private key is stored, they could then decrypt all of your
earlier communications...  unless you used PFS.

 - Nemo
___
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography