Re: [tor-talk] Tor (and other nets) probably screwed by Traffic Analysis by now
On 6/2/16, Allen <allenpmd@gmail.com> wrote:
Another alternative would be to re-architect the services of interest to use a message or packet store-and-forward protocol with a random delay to thwart traffic analysis.
Perhaps different terms for same derivative thing?
From other searchable and recent threads... Fill traffic needs store and forward with random delay, for low latency requirements it could be called reclocking with jitter, rearchitecting for higher latency adds additional bounds on time to the interval and jitter clocks. Packet / message oriented / UDP seems useful to remove constraints of TCP-in-TCP allowing for management of fill traffic, multipath traffic spreading, pluggables, and so on.
Ineffective is say rearchitecting web "services" to deliver a tarball of a website for offline reading, if said delivery is over a traditional non fill network, it will be TA'd. Fill / chaff seem needed, otherwise in an all wheat network, input traffic on one side seems to match output traffic on the other side at some point, regardless of storage / delay. Fixed packet sizes seem to help. Fill ratios up to 100% utilization can mask the wheat. Minimum fill is amount needed for plausible deniability that single input can't be mapped to a single output. ie: 10MiB in, must have at least two outputs that received 10MiB. Is there any group / list that is actively researching or developing such networks? Or that wants to?
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 06/02/2016 12:29 PM, grarpamp wrote:
On 6/2/16, Allen <allenpmd@gmail.com> wrote:
Another alternative would be to re-architect the services of interest to use a message or packet store-and-forward protocol with a random delay to thwart traffic analysis.
Perhaps different terms for same derivative thing?
It seems to me that high capacity routers would take a performance hit from the number crunching and caching requirements of semi-anonymizing all network traffic. A proposal to redo the whole Internet in some such protocol would be hard to sell. People who "want" some measure of privacy are willing to make cost and performance trade-offs proportional to their motivation; but bulk data carriers and large hosting providers are more interested in shaving fractional pennies off data transactions than in end user privacy.
Fill / chaff seem needed, otherwise in an all wheat network, input traffic on one side seems to match output traffic on the other side at some point, regardless of storage / delay.
How much of the network can an adversary see, vs. how big a performance hit do you need to take to reduce your profile? Dummy traffic makes matching the ends of a hidden path orders of magnitude harder, so the numbers crunched and bandwidth consumed might be an overall performance tradeoff win. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQEcBAEBAgAGBQJXUGzmAAoJEECU6c5XzmuqfgcH+QFak6wq83axLkDPVT7DQ2tK KbG5G/oaNdIijsv6iDGXeTw9c2HNB8LM16hFsZYvwAI4SECNn/b8knjxyS2xe4or qLI1GbTB/8dyO7rotIq9ZNzoJYL1HExYA/glMKO0dJZk3+6z4M/E6tE8y/aFlZ5N iYH7PcWpVypg9UFlAXpdVrqzaILD10hqi5w97rWFEAsJ7PZrdmQZn8mkzfHXq6Jh 0Q1c6G1P10MR5paNq8HMEcN7JJA7YBiTkjJrsrBdTcn0Qiskpqa4J2olqWBBLPvN wq4V84ArIcX8YvHTwXpUGIEuzafrxxMYlez4j/Kg4QvnJQsbahkl1+QJXgdUuJY= =Ol35 -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 grarpamp <grarpamp@gmail.com> writes:
Fill / chaff seem needed, otherwise in an all wheat network, input traffic on one side seems to match output traffic on the other side at some point, regardless of storage / delay. Fixed packet sizes seem to help. Fill ratios up to 100% utilization can mask the wheat. Minimum fill is amount needed for plausible deniability that single input can't be mapped to a single output. ie: 10MiB in, must have at least two outputs that received 10MiB.
This stuff has been in daily use since the last millennium. The links below are out of date but should get you started.
Is there any group / list that is actively researching or developing such networks? Or that wants to?
See usenet newsgroup alt.privacy,anon-server - -- -- StealthMonger <StealthMonger@nym.mixmin.net> Long, random latency is part of the price of Internet anonymity. anonget: Is this anonymous browsing, or what? http://groups.google.ws/group/alt.privacy.anon-server/msg/073f34abb668df33?dmode=source&output=gplain stealthmail: Hide whether you're doing email, or when, or with whom. mailto:stealthsuite@nym.mixmin.net?subject=send%20index.html Key: mailto:stealthsuite@nym.mixmin.net?subject=send%20stealthmonger-key -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.9 <http://mailcrypt.sourceforge.net/> iEYEARECAAYFAldQ2XwACgkQDkU5rhlDCl7KWwCeImYXWb+tWLOd4GT6g/8PLDFM /1wAoK0Wl1r418g7JN8nmegEj058hHH1 =1Sdo -----END PGP SIGNATURE-----
On 6/3/16, StealthMonger <StealthMonger@nym.mixmin.net> wrote:
This stuff has been in daily use since the last millennium. The links below are out of date but should get you started.
Anonget looks interesting. Seems better if used over an anonymizing network to help de-identify use of the particular applictions anonget and nntp. Perhaps be aware of submitting relatively very much longer lists of URL's than everyone else if it does not break up both the submission before sending, and the posting by hsub to a.a.m. If not already, posting could maybe use --throw-keyids and no hsub. Did not see server code, or look closely at it all yet.
participants (3)
-
grarpamp -
StealthMonger -
Steve Kinney