Re: traffic analysis
Quoting John S. Denker <[EMAIL PROTECTED]>: > More specifically, anybody who thinks the scheme > I described is vulnerable to a timing attack isn't > paying attention. I addressed this point several > times in my original note. All transmissions > adhere to a schedule -- independent of the amount, > timing, meaning, and other characteristics of the > payload. > And this does not require wide-area synchronization. > If incoming packets are delayed or lost, outgoing > packets may have to include nulls (i.e. cover traffic). Scheduled communications are secure against passive observers, but not an attacker who can implement the "clogging attack" mentioned in Adam's paper. Selectively DoSing various end-users to see if the network traffic continues, either at the endpoints or by doing a binary search of routing nodes, would definitely be possible for a national government or slightly competent script kiddie. Persistent interactive communications with low-latency require some form of cascade (either synchronization or DC-style) such that attacking nodes attacks the system. I think the ultimate solution is to rearchitect systems to not require interactive anonymous communications, and implement less interactive long term distribution, which can be effectively synchronized. Software agents acting largely autonomously on infrequent orders, ideally executing in some kind of tamper-resistant environment, is the best chance for high security in a deployable system. There really is no fundamental need for high bandwidth interactive communications with low latency in most interesting applications, it's just how traditional client-server and p2p software has been designed so far. -- Ryan Lackey [RL960-RIPE AS24812] [EMAIL PROTECTED] +1 202 258 9251 OpenPGP DH 4096: B8B8 3D95 F940 9760 C64B DE90 07AD BE07 D2E0 301F - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
web apps with large volumes of bidirectional http traffic
I need to find some relatively widely deployed applications which have frequent user interactions (rapid clicking on links, from as large a population of links as possible, and also form filling and such). (it should be pretty obvious what this is for) I'd like: 0) *rapid*/frequent user interactions; fast clicking on things (like every second, no more than 5 seconds) 1) "sticky"...long interactions with a given site (on the order of hours) (also all links need to be under the same url/same server) 2) large number of potential links for users to click on, with desirable properties for click distribution (I *think* I want them to be nearly equally likely, but I might just want a defined distribution, or I might even want the opposite of that) 3) relatively small data sizes for downloaded data, UNLESS downloaded data is generated unique and "randomly" 4) widely deployed already on the internet, or compelling enough that there would be a decent number of potential server operators. Obviously I could *create* an app which has the desirable characteristics, but I'd like something which can deal with existing data or apps served over the internet) 5) good data on how likely users are to click on things, how fast they click, etc., so one could easily operate within those parameters. So far, the best ideas: 1) Porn 2) Mailing lists with lots of internal links (next, reply, etc.) 3) Sites with search engines with lots of linked data (encyclopedia, etc.) 4) html games (or flash, maybe) -- either imagemaps, or just tables, things like chess, or puzzles, or whatever I'd definitely appreciate any suggestions on possible web apps which meet these criteria; reply to lists or [EMAIL PROTECTED] I'll post when it's ready. Thanks, Ryan -- Ryan Lackey [RL960-RIPE AS24812] [EMAIL PROTECTED] +1 202 258 9251 OpenPGP DH 4096: B8B8 3D95 F940 9760 C64B DE90 07AD BE07 D2E0 301F - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
