[messaging] Panoramix decryption mixnet messaging spec and design documents
dawuud at riseup.net
Sat Nov 25 14:06:42 PST 2017
On Sat, Nov 25, 2017 at 03:57:41PM -0500, grarpamp wrote:
> Dummy / decoy / fill / chaff traffic itself alone seems insufficient.
Insufficient for what purpose? I listed three in my previous e-mail for
which it is most definitely sufficient. Again that is:
1. detection of n-1 attacks
(if unclear on this point see:
[HEARTBEAT03] Danezis, G., Sassaman, L., "Heartbeat Traffic to Counter (n-1) Attacks",
Proceedings of the Workshop on Privacy in the Electronic Society, October 2003,
2. decrease needed latency for desired mix entropy
(if unclear on this point see:
[LOOPIX] Piotrowska, A., Hayes, J., Elahi, T., Meiser, S., Danezis, G.,
“The Loopix Anonymity System”,
USENIX, August, 2017
3. prevent short term statistical disclosure attacks
(see many papers listed below)
> If a global passive adversary GPA can inject their own
First of all, global passive adversary don't inject anything because
they are passive. Passive means not sending anything!
Why even mention GPA? Are we still talking about statistical
disclosure attacks? If so then, let it be known: "GPA not needed. a
weaker adversary will do". The adversary must be able to watch two
parts of the network, the input and the output; this is much less than
> traffic pattern into the net, and recognize it at some other
> useful vantage point, such as an exit or "hidden" destination,
> or intermediate hop towards a full disclosure... including if the
> pattern is being sent to or between you... they can surely
> do the same with whatever traffic a user pushes. Wherein
they can surely do what precisely?
> the users fill traffic may not be subject to the same influence
> or channel parameters as the users real data traffic.
what? no. decoy traffic is indistinguishable from legit traffic.
that's the whole point.
> Parhaps was talked with Briar / others on cryptography list,
> what would GPA proof Ethernet wire look like?
Again with the GPA. I don't understand what you mean here or why
the mention of a GPA is needed to make your point.
> The link level point to point p2p encrypted line / channel would
Do you mean link layer? We don't use link layer padding.
> be full 100% of the time, packet size outside attacker control,
> with fill traffic yielding for data traffic, with detection if it was ever
> not full or crypto failed (obviously includes received traffic suffered
> delays or missing packets), and all data traffic received from elsewhere
> for transport over such a line must be reclocked for insertion into the line
> to clean any timing / size / data perturbations received.
> It may be impossible to time or correlate a 100% full clocked bucket line,
> or network that uses the same principle.
I don't even understand a little of what you are saying here.
> The more strayed away towards looser more general more unchecked
> constraint upon random fill and the traffic channel, and the less network
> wide, perhaps the less benefit it is.
What do you mean by this?
> The lines may not need to be full, but they seem to must need
> to be fully parameterized, cleaned, checked and enforced.
I also do not understand this statement.
> These are only a few lines of thought among many out there.
> Is there a subset list of research papers being curated
> somewhere that deal specifically with these sorts of traffic
> issues (anti-GPA / fill / decoy / whatever)?
Currently our specifications do not *yet* include anything about decoy traffic:
I did previously post a few links to papers on the subject of
statistical disclosure attacks. I will be citing them as references
in our future decoy traffic specification. Here's a more complete list:
[POOLDUMMY] Diaz, C., Preneel, B.,
"Reasoning about the Anonymity Provided by Pool Mixes that Generate Dummy Traffic",
[MIXDUMMY] Diaz, C., Preneel, B.,
"Taxonomy of Mixes and Dummy Traffic",
[DUMMYLIMITS] Oya, S., Troncoso, C., Pérez-González, F.
"Do dummies pay off? Limits of dummy traffic protection in anonymous communications",
[DUMMYINTERSECTION] Berthold, O., Langos, H.,
"Dummy Traffic Against Long Term Intersection Attacks",
In the Proceedings of the PETS 2002,
[HANGBUDDIES] Wolinksy, D., Syta, E., Ford, B.,
"Hang with Your Buddies to Resist Intersection Attacks",
In the Proceedings of the 20th ACM conference on CCS November 2013,
[STATSDISCO] Danezis, G., Serjantov, A.,
"Statistical Disclosure or Intersection Attacks on Anonymity Systems",
In the Proceedings of 6th Information Hiding Workshop (IH 2004), Toronto, May 2004.
[RESISTDISCLOSURE] Mathewson, N., Dingledine, R.,
"Practical Traffic Analysis: Extending and Resisting Statistical Disclosure",
[2SIDEDSDA] Danezis, G., Diaz, C., Troncoso, C.,
"Two-sided Statistical Disclosure Attack",
In the Proceedings of the PETS 2007,
[PERFECTMATCHING] Troncoso, C., Gierlichs, B., Preneel, B., Verbauwhede, I.,
"Perfect Matching Disclosure Attacks",
In the Proceedings of the PETS 2008,
[LEASTSQUARESSDA] Perez-Gonzalez, F., Troncoso, C.,
"Understanding Statistical Disclosure: A Least Squares approach",
In the Proceedings of the PETS 2012,
[HITTINGSET] Kesdogan, D., Pimenidis, L.,
"The Hitting Set Attack on Anonymity Protocols",
In the Proceedings of 6th Information Hiding Workshop (IH 2004), Toronto, May 2004,
[SDA] Danezis, G.,
"Statistical Disclosure Attacks: Traffic Confirmation in Open Environments",
In the Proceedings of Security and Privacy in the Age of Uncertainty, May 2003,
[ANONLIMITS] Kedogan, D., Agrawal, D., Penz, S.,
"Limits of Anonymity in Open Environments",
In the Proceedings of Information Hiding Workshop, October 2002,
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 833 bytes
Desc: not available
More information about the Messaging