- cypherpunks-legacy - lists.cpunks.org

Re: 25 tbreg relays in directory
by Pei Hanru 06 Jul '18

06 Jul '18

On 2009-04-27 18:27 CST, Scott Bennett wrote: > torstatus currently shows 25 different relays that are all named "tbreq" > and appear to be in China. I wonder whether these are due to some benighted > user restarting tor after clearing its key files every time, or whether there > may be several that are all owned by one organization. All but four are > marked as being "offline". I finally got a plausible answer a few days ago. The short answer is, someone are making use of Tor to do nasty things, and all "tbreg"s aren't aware they are running Tor relays. The long answer. "tbreg" stands for "TaoBao REGistrar". TaoBao is an eBay-like website in China. Some sellers want to quickly increase their reputations (so-called refresh) in order to attract more buyers. The first thing for them is to register multiple accounts. However, TaoBao is rigorous on this, a single IP is only allowed to register one or two accounts. So, someone realize this need and begin to sell softwares which automatically register large number of TaoBao accounts. Tor, together with Privoxy are used as a HTTP proxy to bypass the IP restriction. For some reasons I don't understand, this software will run Tor as a relay. I've downloaded the software and tested, the version of Tor in it is indeed 0.2.1.2-alpha, torrc in it is SocksPort 9050 # what port to open for local application connections SocksListenAddress 127.0.0.1 # accept connections only from localhost ControlPort 9051 Nickname tbreg ORPort 9001 You may test yourself, the download link is http://www.wintaobao.com/download/tbreg_v1.3.8.msi (from http://bbs.wintaobao.com/viewthread.php?tid=135) Finally some random thoughts. 1. We shall be reassured for a moment, these relays won't do much harm to the Tor network. I'm more concerned about the people running these relays, their computers aren't protected at all. But considering the things these guys are doing... well, let it go! 2. Why Tor runs in a relay mode? 3. Should these "tbreg"s be banned from the Tor network? If so, what's the best way to do? Hanru ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE

1 0

PGP, Snow Leopard, and Technological Illiteracy
by Christopher Smith 06 Jul '18

06 Jul '18

R.A. Hettinga wrote: > It dawns on me that Apple PGP-signs all its security announcements, > etc. > > Are *they* using Snow Leopard? As a software developer (in no way affiliated with PGP --not even a customer), this thread has fascinated me, particularly given the long discussion about "technological literacy". Let me clarify some things. 1) PGP signatures still work fine. The core encryption mechanism in PGP is actually open source and not closely coupled with any operating system as it uses little more than the standard C runtime. I'd be willing to bet big money it doesn't even require a recompile to work with Snow Leopard. This is all that is needed to create PGP signatures or verify them, or to encrypt or decrypt data. 2) That has almost nothing to do with PGP's commercial products. What PGP sells isn't the encryption algorithm, but rather an integration of said encryption in to your computer's operation. This necessarily involves a LOT of hooks in to the operating system. 3) In order to do what PGP does, you become sensitive to changes in both the kernel and user space. While Snow Leopard may seem like a trivial update to the operating system to end users, it was involved some pretty significant changes to parts of the underlying platform (which is why it didn't take Apple just a couple of months to do it). To get an idea of the changes, if you are in Apple's Developer program (free for base membership), you can look at this link: http://developer.apple.com/mac/library/releasenotes/MacOSX/WhatsNewInOSX/Ar… /apple_ref/doc/uid/TP40008898-SW1 This is a 7000+ word document providing an *overview* of the changes. It contains links to 15 pdf documents that describe specific changes to different parts of the application level API, including two just for security. It also includes a link to a document providing a summary of the kernel level changes, which itself has links to at least a dozen different articles describing different changes and design challenges involved with the new kernel design. I can tell you that even all this documentation misses some of the more subtle changes. These are NOT trivial changes. The changes involved unsurprisingly effect different kinds of programs differently. I'm sure a whole host of applications were barely impacted by the changes. However, what PGP does is particularly likely to be impacted, because it is very closely coupled with the kernel, needs to integrate kernel changes throughout user space, and most importantly of all: it is a security product. 4) PGP is far from the only vendor effected this way. Particularly in the security space, I've seen a ton of problems. Even the giant Cisco is having problems getting all their security products to work with Snow Leopard. 5) Snow Leopard is particularly problematic because of its unique mix of 64-bit and 32-bit options. Most platforms allow for 32-bit kernel + 32-bit drivers + 32-bit applications. If they have a 64-bit kernel, then it requires 64-bit drivers and 64-bit applications, often with support for 32-bit applications as well. Snow Leopard, because of concerns about getting everyone to update in time for the release, supports almost every permutation you could manage of the above. This was done using all kinds of memory management tricks. Ironically, all of this work makes compatibility far more difficult for products like PGP that tightly integrate with the OS's memory management and have to deal with application space/kernel space interactions, because they need to cover all the possible permutations and combinations of the above, and they need to have work arounds for the various "tricks" employed to make this work (some of which may break fundamental assumptions in how the product works). 6) Commercial security software is a real pain. You have to handle all the little corner cases that nobody ever thinks about. It is VERY common for new features in an operating system or even new features in applications to be released without full consideration of the security consequences of this, and commercial security software has to not only fix these problems, but identify them before they every ship their product. The problems are often quite subtle, and it isn't unusual for security researchers to discover them only years after they first occurred. If you fail on those, the solution isn't as simple as "download this update", because at that point security has been breached, and the cat is out of the bag, or worse still with an encryption product: you can have irrecoverable data loss. Different firms react to this differently, but PGP and a few other firms involved with encryption in particular consider this kind of a problem a failure of the product. So, it isn't sufficient just to look at changes in the operating system, you also have to look at changes application and driver developers are making in reaction to changes in the platform. This makes it terribly difficult to have a ready product on the day a new operating system is released. Now, despite all of the above, it is entirely possible to have a commercial security product ready for a new operating system release. It requires a devotion of significant resources and careful management, but given that people are paying you money (although PGP doesn't get nearly as much as a lot of other vendors) to make it happen, it is achievable. It is, however, difficult to predict how many resources and how much time you'll need to be ready, and so it is actually quite likely you can miss your deadline. Some commercial vendors choose to cut a lot of corners to avoid this happening. I see it all the time and it gets really ugly. The stuff I've seen specifically with security products are absolutely horrific, and they rely on users not really knowing what the software is doing (because if they did, they'd never run it). The irony here is that the technological illiteracy of the market place means that it rewards bad behavior and punishes good behavior. This is the kind of dysfunction caused by technological illiteracy that we ought to be concerned about. Honestly, if you care at all about security and rely on commercial security software, I wouldn't recommend switching to Leopard right off the dot no matter what your commercial vendors tell you, because it is highly improbable that a given product really is "ready", and it is virtually impossible to determine which ones are. I for one applaud PGP for making the tough call and holding off on a release until they felt 100% confident about their product. They did this knowing full well that the "technological illiteracy" of their user base means that the move will be interpreted negatively and seen ironically as a sign of them not being sensitive to their user's needs. --Chris -- If you want to unsubscribe or change your address, use this link: http://emperor.tidbits.com/webx?unsub@@.3c3f6899!u=30544749

1 0

Tor 0.2.2.6-alpha is out
by Roger Dingledine 06 Jul '18

06 Jul '18

Tor 0.2.2.6-alpha lays the groundwork for many upcoming features: support for the new lower-footprint "microdescriptor" directory design, future-proofing our consensus format against new hash functions or other changes, and an Android port. It also makes Tor compatible with the upcoming OpenSSL 0.9.8l release, and fixes a variety of bugs. https://www.torproject.org/download.html.en Changes in version 0.2.2.6-alpha - 2009-11-19 o Major features: - Directory authorities can now create, vote on, and serve multiple parallel formats of directory data as part of their voting process. Partially implements Proposal 162: "Publish the consensus in multiple flavors". - Directory authorities can now agree on and publish small summaries of router information that clients can use in place of regular server descriptors. This transition will eventually allow clients to use far less bandwidth for downloading information about the network. Begins the implementation of Proposal 158: "Clients download consensus + microdescriptors". - The directory voting system is now extensible to use multiple hash algorithms for signatures and resource selection. Newer formats are signed with SHA256, with a possibility for moving to a better hash algorithm in the future. - New DisableAllSwap option. If set to 1, Tor will attempt to lock all current and future memory pages via mlockall(). On supported platforms (modern Linux and probably BSD but not Windows or OS X), this should effectively disable any and all attempts to page out memory. This option requires that you start your Tor as root -- if you use DisableAllSwap, please consider using the User option to properly reduce the privileges of your Tor. - Numerous changes, bugfixes, and workarounds from Nathan Freitas to help Tor build correctly for Android phones. o Major bugfixes: - Work around a security feature in OpenSSL 0.9.8l that prevents our handshake from working unless we explicitly tell OpenSSL that we are using SSL renegotiation safely. We are, but OpenSSL 0.9.8l won't work unless we say we are. o Minor bugfixes: - Fix a crash bug when trying to initialize the evdns module in Libevent 2. Bugfix on 0.2.1.16-rc. - Stop logging at severity 'warn' when some other Tor client tries to establish a circuit with us using weak DH keys. It's a protocol violation, but that doesn't mean ordinary users need to hear about it. Fixes the bug part of bug 1114. Bugfix on 0.1.0.13. - Do not refuse to learn about authority certs and v2 networkstatus documents that are older than the latest consensus. This bug might have degraded client bootstrapping. Bugfix on 0.2.0.10-alpha. Spotted and fixed by xmux. - Fix numerous small code-flaws found by Coverity Scan Rung 3. - If all authorities restart at once right before a consensus vote, nobody will vote about "Running", and clients will get a consensus with no usable relays. Instead, authorities refuse to build a consensus if this happens. Bugfix on 0.2.0.10-alpha; fixes bug 1066. - If your relay can't keep up with the number of incoming create cells, it would log one warning per failure into your logs. Limit warnings to 1 per minute. Bugfix on 0.0.2pre10; fixes bug 1042. - Bridges now use "reject *:*" as their default exit policy. Bugfix on 0.2.0.3-alpha; fixes bug 1113. - Fix a memory leak on directory authorities during voting that was introduced in 0.2.2.1-alpha. Found via valgrind. ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE

1 0

Re: 0wned .gov machines (was Re: Russian cyberwar against Estonia?)
by John Levine 06 Jul '18

06 Jul '18

>I've heard nothing formal, but my strong understanding is a lot of US >government machines, at least if we're talking workstations on >non-classified nets, are in fact "0wn3d" at this point. Well, here's an anecdote: at last year's CEAS conference, Rob Thomas of Team Cymru gave the keynote on the underground economy, with a most horrifying set of both live demos and selected snapshots of the online bazaars where online warez are traded, everything from zombie farms to spamware to stolen credit cards. One of the more amusing was a guy who offered a zombie in some part of the government that you'd hope would be moderately secure, NASA or someplace like that, at a higher than normal price. The immediate response was ridicule, bots on government nets are a dime a dozen, and aren't worth any more than any other bot. R's, John --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo(a)metzdowd.com ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE

1 0

Re: 25 tbreg relays in directory
by Pei Hanru 06 Jul '18

06 Jul '18

On 2009-04-27 18:27 CST, Scott Bennett wrote: > torstatus currently shows 25 different relays that are all named "tbreq" > and appear to be in China. I wonder whether these are due to some benighted > user restarting tor after clearing its key files every time, or whether there > may be several that are all owned by one organization. All but four are > marked as being "offline". I finally got a plausible answer a few days ago. The short answer is, someone are making use of Tor to do nasty things, and all "tbreg"s aren't aware they are running Tor relays. The long answer. "tbreg" stands for "TaoBao REGistrar". TaoBao is an eBay-like website in China. Some sellers want to quickly increase their reputations (so-called refresh) in order to attract more buyers. The first thing for them is to register multiple accounts. However, TaoBao is rigorous on this, a single IP is only allowed to register one or two accounts. So, someone realize this need and begin to sell softwares which automatically register large number of TaoBao accounts. Tor, together with Privoxy are used as a HTTP proxy to bypass the IP restriction. For some reasons I don't understand, this software will run Tor as a relay. I've downloaded the software and tested, the version of Tor in it is indeed 0.2.1.2-alpha, torrc in it is SocksPort 9050 # what port to open for local application connections SocksListenAddress 127.0.0.1 # accept connections only from localhost ControlPort 9051 Nickname tbreg ORPort 9001 You may test yourself, the download link is http://www.wintaobao.com/download/tbreg_v1.3.8.msi (from http://bbs.wintaobao.com/viewthread.php?tid=135) Finally some random thoughts. 1. We shall be reassured for a moment, these relays won't do much harm to the Tor network. I'm more concerned about the people running these relays, their computers aren't protected at all. But considering the things these guys are doing... well, let it go! 2. Why Tor runs in a relay mode? 3. Should these "tbreg"s be banned from the Tor network? If so, what's the best way to do? Hanru ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE

1 0

PGP, Snow Leopard, and Technological Illiteracy
by Christopher Smith 06 Jul '18

06 Jul '18

R.A. Hettinga wrote: > It dawns on me that Apple PGP-signs all its security announcements, > etc. > > Are *they* using Snow Leopard? As a software developer (in no way affiliated with PGP --not even a customer), this thread has fascinated me, particularly given the long discussion about "technological literacy". Let me clarify some things. 1) PGP signatures still work fine. The core encryption mechanism in PGP is actually open source and not closely coupled with any operating system as it uses little more than the standard C runtime. I'd be willing to bet big money it doesn't even require a recompile to work with Snow Leopard. This is all that is needed to create PGP signatures or verify them, or to encrypt or decrypt data. 2) That has almost nothing to do with PGP's commercial products. What PGP sells isn't the encryption algorithm, but rather an integration of said encryption in to your computer's operation. This necessarily involves a LOT of hooks in to the operating system. 3) In order to do what PGP does, you become sensitive to changes in both the kernel and user space. While Snow Leopard may seem like a trivial update to the operating system to end users, it was involved some pretty significant changes to parts of the underlying platform (which is why it didn't take Apple just a couple of months to do it). To get an idea of the changes, if you are in Apple's Developer program (free for base membership), you can look at this link: http://developer.apple.com/mac/library/releasenotes/MacOSX/WhatsNewInOSX/Ar… /apple_ref/doc/uid/TP40008898-SW1 This is a 7000+ word document providing an *overview* of the changes. It contains links to 15 pdf documents that describe specific changes to different parts of the application level API, including two just for security. It also includes a link to a document providing a summary of the kernel level changes, which itself has links to at least a dozen different articles describing different changes and design challenges involved with the new kernel design. I can tell you that even all this documentation misses some of the more subtle changes. These are NOT trivial changes. The changes involved unsurprisingly effect different kinds of programs differently. I'm sure a whole host of applications were barely impacted by the changes. However, what PGP does is particularly likely to be impacted, because it is very closely coupled with the kernel, needs to integrate kernel changes throughout user space, and most importantly of all: it is a security product. 4) PGP is far from the only vendor effected this way. Particularly in the security space, I've seen a ton of problems. Even the giant Cisco is having problems getting all their security products to work with Snow Leopard. 5) Snow Leopard is particularly problematic because of its unique mix of 64-bit and 32-bit options. Most platforms allow for 32-bit kernel + 32-bit drivers + 32-bit applications. If they have a 64-bit kernel, then it requires 64-bit drivers and 64-bit applications, often with support for 32-bit applications as well. Snow Leopard, because of concerns about getting everyone to update in time for the release, supports almost every permutation you could manage of the above. This was done using all kinds of memory management tricks. Ironically, all of this work makes compatibility far more difficult for products like PGP that tightly integrate with the OS's memory management and have to deal with application space/kernel space interactions, because they need to cover all the possible permutations and combinations of the above, and they need to have work arounds for the various "tricks" employed to make this work (some of which may break fundamental assumptions in how the product works). 6) Commercial security software is a real pain. You have to handle all the little corner cases that nobody ever thinks about. It is VERY common for new features in an operating system or even new features in applications to be released without full consideration of the security consequences of this, and commercial security software has to not only fix these problems, but identify them before they every ship their product. The problems are often quite subtle, and it isn't unusual for security researchers to discover them only years after they first occurred. If you fail on those, the solution isn't as simple as "download this update", because at that point security has been breached, and the cat is out of the bag, or worse still with an encryption product: you can have irrecoverable data loss. Different firms react to this differently, but PGP and a few other firms involved with encryption in particular consider this kind of a problem a failure of the product. So, it isn't sufficient just to look at changes in the operating system, you also have to look at changes application and driver developers are making in reaction to changes in the platform. This makes it terribly difficult to have a ready product on the day a new operating system is released. Now, despite all of the above, it is entirely possible to have a commercial security product ready for a new operating system release. It requires a devotion of significant resources and careful management, but given that people are paying you money (although PGP doesn't get nearly as much as a lot of other vendors) to make it happen, it is achievable. It is, however, difficult to predict how many resources and how much time you'll need to be ready, and so it is actually quite likely you can miss your deadline. Some commercial vendors choose to cut a lot of corners to avoid this happening. I see it all the time and it gets really ugly. The stuff I've seen specifically with security products are absolutely horrific, and they rely on users not really knowing what the software is doing (because if they did, they'd never run it). The irony here is that the technological illiteracy of the market place means that it rewards bad behavior and punishes good behavior. This is the kind of dysfunction caused by technological illiteracy that we ought to be concerned about. Honestly, if you care at all about security and rely on commercial security software, I wouldn't recommend switching to Leopard right off the dot no matter what your commercial vendors tell you, because it is highly improbable that a given product really is "ready", and it is virtually impossible to determine which ones are. I for one applaud PGP for making the tough call and holding off on a release until they felt 100% confident about their product. They did this knowing full well that the "technological illiteracy" of their user base means that the move will be interpreted negatively and seen ironically as a sign of them not being sensitive to their user's needs. --Chris -- If you want to unsubscribe or change your address, use this link: http://emperor.tidbits.com/webx?unsub@@.3c3f6899!u=30544749

1 0

Tor 0.2.2.6-alpha is out
by Roger Dingledine 06 Jul '18

06 Jul '18

Tor 0.2.2.6-alpha lays the groundwork for many upcoming features: support for the new lower-footprint "microdescriptor" directory design, future-proofing our consensus format against new hash functions or other changes, and an Android port. It also makes Tor compatible with the upcoming OpenSSL 0.9.8l release, and fixes a variety of bugs. https://www.torproject.org/download.html.en Changes in version 0.2.2.6-alpha - 2009-11-19 o Major features: - Directory authorities can now create, vote on, and serve multiple parallel formats of directory data as part of their voting process. Partially implements Proposal 162: "Publish the consensus in multiple flavors". - Directory authorities can now agree on and publish small summaries of router information that clients can use in place of regular server descriptors. This transition will eventually allow clients to use far less bandwidth for downloading information about the network. Begins the implementation of Proposal 158: "Clients download consensus + microdescriptors". - The directory voting system is now extensible to use multiple hash algorithms for signatures and resource selection. Newer formats are signed with SHA256, with a possibility for moving to a better hash algorithm in the future. - New DisableAllSwap option. If set to 1, Tor will attempt to lock all current and future memory pages via mlockall(). On supported platforms (modern Linux and probably BSD but not Windows or OS X), this should effectively disable any and all attempts to page out memory. This option requires that you start your Tor as root -- if you use DisableAllSwap, please consider using the User option to properly reduce the privileges of your Tor. - Numerous changes, bugfixes, and workarounds from Nathan Freitas to help Tor build correctly for Android phones. o Major bugfixes: - Work around a security feature in OpenSSL 0.9.8l that prevents our handshake from working unless we explicitly tell OpenSSL that we are using SSL renegotiation safely. We are, but OpenSSL 0.9.8l won't work unless we say we are. o Minor bugfixes: - Fix a crash bug when trying to initialize the evdns module in Libevent 2. Bugfix on 0.2.1.16-rc. - Stop logging at severity 'warn' when some other Tor client tries to establish a circuit with us using weak DH keys. It's a protocol violation, but that doesn't mean ordinary users need to hear about it. Fixes the bug part of bug 1114. Bugfix on 0.1.0.13. - Do not refuse to learn about authority certs and v2 networkstatus documents that are older than the latest consensus. This bug might have degraded client bootstrapping. Bugfix on 0.2.0.10-alpha. Spotted and fixed by xmux. - Fix numerous small code-flaws found by Coverity Scan Rung 3. - If all authorities restart at once right before a consensus vote, nobody will vote about "Running", and clients will get a consensus with no usable relays. Instead, authorities refuse to build a consensus if this happens. Bugfix on 0.2.0.10-alpha; fixes bug 1066. - If your relay can't keep up with the number of incoming create cells, it would log one warning per failure into your logs. Limit warnings to 1 per minute. Bugfix on 0.0.2pre10; fixes bug 1042. - Bridges now use "reject *:*" as their default exit policy. Bugfix on 0.2.0.3-alpha; fixes bug 1113. - Fix a memory leak on directory authorities during voting that was introduced in 0.2.2.1-alpha. Found via valgrind. ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE

1 0

Re: 0wned .gov machines (was Re: Russian cyberwar against Estonia?)
by John Levine 06 Jul '18

06 Jul '18

>I've heard nothing formal, but my strong understanding is a lot of US >government machines, at least if we're talking workstations on >non-classified nets, are in fact "0wn3d" at this point. Well, here's an anecdote: at last year's CEAS conference, Rob Thomas of Team Cymru gave the keynote on the underground economy, with a most horrifying set of both live demos and selected snapshots of the online bazaars where online warez are traded, everything from zombie farms to spamware to stolen credit cards. One of the more amusing was a guy who offered a zombie in some part of the government that you'd hope would be moderately secure, NASA or someplace like that, at a higher than normal price. The immediate response was ridicule, bots on government nets are a dime a dozen, and aren't worth any more than any other bot. R's, John --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo(a)metzdowd.com ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE

1 0

Re: [tor-talk] End-to-end correlation for fun and profit
by Mike Perry 06 Jul '18

06 Jul '18

Thus spake Ted Smith (tedks(a)riseup.net) > On Mon, 2012-08-20 at 10:33 +0300, Maxim Kammerer wrote: > > Hello gentlemen, > <snip> > > [1] http://pastebin.com/hgtXMSyx > > I ran this script on the current consensus. The full results (the > nodes-sniff-summary file) are below my signature. How did you compile > the country-codes to IPs list? That wasn't produced by the script. > > It's comforting that this approach yields quickly diminishing returns. > Going from 25 to 60 networks only gets you a 10% increase in networks > surveillance (if I'm reading the output correctly), and returns plateau > entirely at that point (I'm considering about two percent to be in the > noise, which may not be appropriate to this domain). > > Also, it's not immediately clear whether eavesdropping those networks > would actually get you strong enough correlation to accurately > de-anonymize users[1]. If our rodent(?) friend(s?) could comment on > this, I'd appreciate their expertise. The Raccoon has made a believer out of me, but there are some limits to both of his/her proofs.. The full proofs can still be found here: http://web.archive.org/web/20100416150300/http://archives.seul.org/or/dev/S… https://lists.torproject.org/pipermail/tor-dev/2012-March/003347.html The actual numbers from the examples of the first proof are affected by the resolution of the data retention. The core concept of the proof seems to hold no matter what (that full dragnet n^2 correlation is hard, and the amount of similar co-incident traffic - aka the base rate - is what makes it hard), but if the adversary has full observation of *all* traffic data, they *might* be able to do better than 99.9% true positive rate. It's not clear that low-resolution connection-level data retention or even sampled netflow data can provide anywhere near that true positive rate, though. A full adversary may also get to combine repeat observations (assuming it is possible to identify them as from the same user), but the post mentions that. Incidentally, my guess is that's probably one of the reasons for the huge boondoggle^W datacenter in Utah. They probably realized that to reliably track large botnet activity, they really needed to log all data forever. Well, keep sitting on the unpublished 0day software vulnerabilities, guys. That should totally help you solve both those problems, once and for all. Oh wait. ;) Anyways, the key thing I think the first proof tells us is that even sloppy defenses against correlation attacks are likely to work against dragnet surveillance/data retention, especially if you have a lot of co-incident traffic to blend in with and if the data retention resolution is low. I think this alone can justify experimentation with traffic padding to/from Guard nodes, where bandwidth is relatively cheap and plentiful. It especially justifies minimal amounts of Guard node padding to defend against the single-ended version of the end-to-end correlation attack, which is also known as the "website traffic fingerprinting attack". The single ended version is even *more* vulnerable to the properties of background traffic than the double-ended version, and has far fewer reliably recognizable traffic features to extract from data streams as well. See this blog post and its links for more details: https://blog.torproject.org/blog/experimental-defense-website-traffic-finge… It's my personal opinion that we should also experiment with Guard padding against the website traffic fingerprinting attack, and see how far that gets us against e2e correlation while we're at it. Unfortunately, current academic religious dogma tends to hold that correlation is unbeatable no matter what. This publication and research bias already has hindered and will likely continue to hinder research into viable defenses :(. The second proof wrt tagging attacks scared the crap out of me. However, the "c/n" compromise result at the end hinges crucially on nodes that fail circuits being able to attract additional traffic to make up for it. The bandwidth authorities might do this to a certain extent currently, and will certainly do it if operated in "PID feedback mode". However it's still not clear that the 3 guard node round-robin circuit selection properties of Tor wouldn't end up also hampering the attack against specific clients (unless the Guard nodes' keys were stolen and the attack is locally targeted). Either way, it's caused me to drive Nick nuts by pushing hard to include at least *some* kind of simple defense for circuit failure attacks on the client-side. How much of that actually survives in 0.2.3.x in a functional form remains to be seen :/. P.S. Incidentally, you used to be able to get the full copy of the first proof in the old seul archives at http://archives.seul.org/or/dev/Sep-2008/msg00016.html, but since seul is currently down with unknown hardware and disk issues, http://web.archive.org/web/20100416150300/http://archives.seul.org/or/dev/S… might be the last full public copy other than your repost. I've added the Raccoon on Cc so s/he can hopefully do a full repost if the seul archives end up being destroyed forever. -- Mike Perry _______________________________________________ tor-talk mailing list tor-talk(a)lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE

1 0

Re: Jim Bell arrested, documents online
by None 06 Jul '18

06 Jul '18

At 09:48 PM 11/24/00 -0500, Greg Newby wrote: > >But seriously, folks: How would you work with a like-minded >distributed group to murder someone? Preferably with guaranteed >no risk of discovery or prosecution to the participants. RTFM

1 0