Re: [PracticalSecurity] Anonymity - great technology but hardly used
http://www.hbarel.com/Blog/entry0006.html
I believe that for anonymity and pseudonymity technologies to survive they have to be applied to applications that require them by design, rather than to mass-market applications that can also do (cheaper) without. If anonymity mechanisms are deployed just to fulfill the wish of particular users then it may fail, because most users don't have that wish strong enough to pay for fulfilling it. An example for such an application (that requires anonymity by design) could be E-Voting, which, unfortunately, suffers from other difficulties. I am sure there are others, though.
The truth is exactly the opposite of what is suggested in this article. The desire for anonymous communication is greater today than ever, but the necessary technology does not exist. For the first time there are tens or hundreds of millions of users who have a strong need and desire for high volume anonymous communications. These are file traders, exchanging images, music, movies, TV shows and other forms of communication. The main threat to this illegal but widely practiced activity is legal action by copyright holders against individual traders. The only effective protection against these threats is the barrier that could be provided by anonymity. An effective, anonymous file sharing network would see rapid adoption and would be the number one driver for widespread use of anonymity. But the technology isn't there. Providing real-time, high-volume, anonymous communications is not possible at the present time. Anyone who has experienced the pitiful performance of a Tor web browsing session will be familiar with the iron self-control and patience necessary to keep from throwing the computer out the window in frustration. Yes, you can share files via Tor, at the expense of reducing transfer rates by multiple orders of magnitude. Not only are there efficiency problems, detailed analysis of the security properties of real time anonymous networks have repeatedly shown that the degree of anonymity possible is very limited against a determined attacker. Careful insertion of packet delays and monitoring of corresponding network reactions allow an attacker to easily trace an encrypted communication through the nodes of the network. Effective real-time anonymity is almost a contradiction in terms. Despite these difficulties, file trading is still the usage area with the greatest potential for widespread adoption of anonymity. File traders are fickle and will gravitate rapidly to a new system if it offers significant benefits. If performance can be improved to at least approximate the transfer rates of non-anonymous networks, while allowing enough security to make the job of the content lawyers harder, that could be enough to give this technology the edge it needs to achieve widespread acceptance. CP
Part of the problem is using a packet-switched network; if we had circuit-based, then thwarting traffic analysis is easy; you just fill the link with random garbage when not transmitting packets. I considered doing this with SLIP back before broadband (back when my friend was my ISP). There are two problems with this; one, getting enough random data, and two, distinguishing the padding from the real data in a computationally efficient manner on the remote side without giving away anything to someone analyzing your traffic. I guess both problems could be solved by using synchronized PRNGs on both ends to generate the chaff. The two sides getting desynchronzied would be problematic. Please CC me with any ideas you might have on doing something like this, perhaps it will become useful again one day. On packet-switched networks, running full speed all the time is not very efficient nor is it very friendly to your neighbors. Again, if you have any ideas on how to deal with this, email me. Many of the anonymity protocols require multiple participants, and thus are subject to what economists call "network externalities". The best example I can think of is Microsoft Office file formats. I don't buy MS Office because it's the best software at creating documents, but I have to buy it because the person in HR insists on making our timecards in Excel format. In this case, the fact that the HR person (a third party to the transaction) is using it forces me to buy it from Microsoft. Similarly, the more people use digital cash, the more likely I am to decide to use it. The more Tor nodes we have, the more high speed and close nodes there will be, and the more enjoyable the experience will be (assuming Tor is smart enough to use the close, fast nodes). For more information on network externalities, see the book "Information Rules", available from Amazon for just over $4. Everyone working in IT or interested in computers should read that book. Another issue involves the ease of use when switching between a [slower] anonymous service and a fast non-anonymous service. I have a tool called metaprox on my website (see URL in sig) that allows you to choose what proxies you use on a domain-by-domain basis. Something like this is essential if you want to be consistent about accessing certain sites only through an anonymous proxy. Short of that, perhaps a Firefox plug-in that allows you to select proxies with a single click would be useful. It would be nice if the protocols allowed you to specify a chain of proxies, but unfortunately HTTP only allows you to specify the next hop, not a chain of hops. Perhaps someone could come up with an encapsulation method and cooperative proxy server that is more like the old cpunk remailers, using nested encrypted "envelopes" in the body of the request. Perhaps crowds or Tor already does this, I don't know. Where anonymizing facilities fail are fairly obvious to anyone who has used them, listed in descending order of importance: ease of configuration (initial setup cost) ease of use locator services for peers or servers network effects (not enough people using it) efficient use of resources (see quote in sig about why this is the least important) There are some technical concerns limiting their security: resistance to traffic analysis or trojaned software ad-hoc systems for crypto key updates or revocation I think one way to encourage adoption is to amortize the cost of setup over a group of people. For example, everyone who reads this could set up a hardened co-loc box and install all the relevant software, then charge their friends a small fee to use it. An ISP could make these services available to their customers. An ASP could make them available to customers over the web. People could start creating open-source Live! CD distributions* with all the software clients installed and preconfigured (or configured easily through a wizard-like set of menus invoked automatically at bootup). With Live! CDs in particular, you'd have a bit of a problem with generating crypto keys since the RNG fires up in the same state for everyone, but perhaps you could seed it by hashing the contents of a disk drive, or the contents of memory-mapped hardware ROMs (e.g. ethernet MAC address), network traffic, and/or with seed state persisted on a removable USB drive. [*] See http://www.frozentech.com/content/livecd.php I don't see a distro specifically for anonymity; if you have friends who want to create Yet Another Linux Distro, perhaps they could fill this niche. Two alternatives suggest themselves; a client distro for end-users and a server distro for people with a machine that's not doing anything. You'd just pop in the CD and it announces its availability to various locator services to act as a Tor, mixmaster, or whatever node. Again, keep me informed if anyone starts work on this. -- http://www.lightconsulting.com/~travis/ -><- "We already have enough fast, insecure systems." -- Schneier & Ferguson GPG fingerprint: 50A1 15C5 A9DE 23B9 ED98 C93E 38E9 204A 94C2 641B
--- "Travis H." <solinym@gmail.com> wrote: [snip]
Another issue involves the ease of use when switching between a [slower] anonymous service and a fast non-anonymous service. I have a tool called metaprox on my website (see URL in sig) that allows you to choose what proxies you use on a domain-by-domain basis. Something like this is essential if you want to be consistent about accessing certain sites only through an anonymous proxy. Short of that, perhaps a Firefox plug-in that allows you to select proxies with a single click would be useful.
You can already do the latter with SwitchProxy (http://www.roundtwo.com/product/switchproxy). Basically, it's a Firefox extension that saves you the trouble of going into the 'preferences' dialogue everytime you want to switch from one proxy to another (or go from using a proxy to not using one, that is). It works like a charm with tor and a local proxy. It also has a "Anonymizer mode", which cycles through a list of proxies in an attempt to give you some kind of pseudo-anonymity (which I guess is good enough for many people). Jvrn __________________________________ Yahoo! Mail - PC Magazine Editors' Choice 2005 http://mail.yahoo.com
On Wed, 26 Oct 2005, Jvrn Schmidt wrote:
--- "Travis H." <solinym@gmail.com> wrote:
[snip]
Another issue involves the ease of use when switching between a [slower] anonymous service and a fast non-anonymous service. I have a tool called metaprox on my website (see URL in sig) that allows you to choose what proxies you use on a domain-by-domain basis. Something like this is essential if you want to be consistent about accessing certain sites only through an anonymous proxy. Short of that, perhaps a Firefox plug-in that allows you to select proxies with a single click would be useful.
You can already do the latter with SwitchProxy (http://www.roundtwo.com/product/switchproxy). Basically, it's a Firefox extension that saves you the trouble of going into the 'preferences' dialogue everytime you want to switch from one proxy to another (or go from using a proxy to not using one, that is).
In fact, it is possible to setup it all thru privoxy alone: # 5. FORWARDING # ============= # # This feature allows routing of HTTP requests through a chain # of multiple proxies. It can be used to better protect privacy # and confidentiality when accessing specific domains by routing # requests to those domains through an anonymous public proxy (see # e.g. http://www.multiproxy.org/anon_list.htm) Or to use a caching # proxy to speed up browsing. Or chaining to a parent proxy may be # necessary because the machine that Privoxy runs on has no direct # Internet access. # # Also specified here are SOCKS proxies. Privoxy supports the SOCKS # 4 and SOCKS 4A protocols. [...] # 5.1. forward # ============ # # Specifies: # # To which parent HTTP proxy specific requests should be routed. # # Type of value: # # target_pattern http_parent[:port] # # where target_pattern is a URL pattern that specifies to which # requests (i.e. URLs) this forward rule shall apply. Use / # to denote "all URLs". http_parent[:port] is the DNS name or # IP address of the parent HTTP proxy through which the requests # should be forwarded, optionally followed by its listening port # (default: 8080). Use a single dot (.) to denote "no forwarding". Btw, I guess everybody who installs tor with privoxy has to know about this since he has to change this section. The problem is that it is not clear how to protect against `malicious' sites: if you separate fast and tor-enabled sites by the site's name, e.g., tor for search.yahoo.com, and no proxy for everything else, yahoo can trace you thru images served from .yimg.com; OTOH if you change proxy `with one click' first of all you can easily forget to do it, but also a site can create a time-bomb -- a javascript (or just http/html refresh) which waits some time in background (presumably, until you switch tor off) and makes another request which allows to find out your real ip. -- Regards, ASK
Travis H. wrote:
Part of the problem is using a packet-switched network; if we had circuit-based, then thwarting traffic analysis is easy; you just fill the link with random garbage when not transmitting packets. ....
OK so far ...
There are two problems with this; one, getting enough random data, and two, distinguishing the padding from the real data in a computationally efficient manner on the remote side without giving away anything to someone analyzing your traffic. I guess both problems could be solved by using synchronized PRNGs on both ends to generate the chaff.
This is a poor statement of the problem(s), followed by a "solution" that is neither necessary nor sufficient. 1) Let's assume we are encrypting the messages. If not, the adversary can read the messages without bothering with traffic analysis, so the whole discussion of traffic analysis is moot. 2) Let's assume enough randomness is available to permit encryption of the traffic ... in particular, enough randomness is available _steady-state_ (without stockpiling) to meet even the _peak_ demand. This is readily achievable with available technology. 3) As a consequence of (1) and (2), we can perfectly well use _nonrandom_ chaff. If the encryption (item 1) is working, the adversary cannot tell constants from anything else. If we use chaff so that the steady-state traffic is indistinguishable from the peak traffic, then (item 2) we have enough randomness available; TA-thwarting doesn't require anything more. 4) Let's consider -- temporarily -- the scenario where the encryption is being done using IPsec. This will serve to establish terminology and expose some problems heretofore not mentioned. 4a) IPsec tunnel mode has "inner headers" that are more than sufficient to distinguish chaff from other traffic. (Addressing the chaff to UDP port 9 will do nicely.) 4b) What is not so good is that IPsec is notorious for "leaking" information about packet-length. Trying to make chaff with a distribution of packet sizes indistinguishable from your regular traffic is rarely feasible, so we must consider other scenarios, somewhat like IPsec but with improved TA-resistance. 5) Recall that IPsec tunnel mode can be approximately described as IPIP encapsulation carried by IPsec transport mode. If we abstract away the details, we are left with a packet (called an "envelope") that looks like ---------------++++++++++++++++++++++++++ | outer header | inner header | payload | [1] ---------------++++++++++++++++++++++++++ where the inner header and payload (together called the "contents" of the envelope) are encrypted. (The "+" signs are meant to be opaque to prying eyes.) The same picture can be used to describe not just IPsec tunnel mode (i.e. IPIP over IPsec transport) but also GRE over IPsec transport, and even PPPoE over IPsec transport. Note: All the following statements apply *after* any necessary fragmentation has taken place. The problem is that the size of the envelope (as described by the length field in the outer header) is conventionally chosen to be /just/ big enough to hold the contents. This problem is quite fixable ... we just need constant-sized envelopes! The resulting picture is: ---------------++++++++++++++++++++++++++++++++++++ | outer header | inner header | payload | padding | [2] ---------------++++++++++++++++++++++++++++++++++++ where padding is conceptually different from chaff: chaff means packets inserted where there would have been no packet, while padding adjusts the length of a packet that would have been sent anyway. The padding is not considered part of the contents. The decoding is unambiguous, because the size of the contents is specified by the length field in the inner header, which is unaffected by the padding. This is a really, really tiny hack on top of existing protocols. If your plaintext consists primarily of small packets, you should set the MTU of the transporter to be small. This will cause fragmentation of the large packets, which is the price you have to pay. Conversely, if your plaintext consists primarily of large packets, you should make the MTU large. This means that a lot of bandwidth will be wasted on padding if/when there are small packets (e.g. keystrokes, TCP acks, and voice cells) but that's the price you have to pay to thwart traffic analysis. (Sometimes you can have two virtual circuits, one for big packets and one for small packets. This degrades the max performance in both cases, but raises the minimum performance in both cases.) Remark: FWIW, the MTU (max transmission unit) should just be called the TU in this case, because all transmissions have the same size now!
Good catch on the encryption. I feel silly for not thinking of it.
If your plaintext consists primarily of small packets, you should set the MTU of the transporter to be small. This will cause fragmentation of the large packets, which is the price you have to pay. Conversely, if your plaintext consists primarily of large packets, you should make the MTU large. This means that a lot of bandwidth will be wasted on padding if/when there are small packets (e.g. keystrokes, TCP acks, and voice cells) but that's the price you have to pay to thwart traffic analysis.
I'm not so sure. If we're talking about thwarting traffic on the link level (real circuit) or on the virtual-circuit level, then you're adding, on average, a half-packet latency whenever you want to send a real packet. And then there's the bandwidth tradeoff you mention, which is probably of a larger concern (although bandwidth will increase over time, whereas the speed of light will not). I don't see any reason why it's necessary to pay these costs if you abandon the idea of generating only equal-length packets and creating all your chaff as packets. Let's assume the link is encrypted as before. Then you merely introduce your legitimate packets with a certain escape sequence, and pad between these packets with either zeroes, or if you're more paranoid, some kind of PRNG. In this way, if the link is idle, you can stop generating chaff and start generating packets at any time. I assume that the length is explicitly encoded in the legitimate packet. Then the peer for the link ignores everything until the next "escape sequence" introducing a legitimate packet. This is not a tiny hack, but avoids much of the overhead in your technique. It could easily be applied to something like openvpn, which can operate over a TCP virtual circuit, or ppp. It'd be a nice optimization if you could avoid retransmits of segments that contained only chaff, but that may or may not be possible to do without giving up some TA resistance (esp. in the presence of an attacker who may prevent transmission of segments). -- http://www.lightconsulting.com/~travis/ -><- "We already have enough fast, insecure systems." -- Schneier & Ferguson GPG fingerprint: 50A1 15C5 A9DE 23B9 ED98 C93E 38E9 204A 94C2 641B
I assume that the length is explicitly encoded in the legitimate packet. Then the peer for the link ignores everything until the next "escape sequence" introducing a legitimate packet.
I should point out that encrypting PRNG output may be pointless, and perhaps one optimization is to stop encrypting when switching on the chaff. The peer can then encrypt the escape sequence as it would appear in the encrypted stream, and do a simple string match on that. In this manner the peer does not have to do any decryption until the [encrypted] escape sequence re-appears. Another benefit of this is to limit the amount of material encrypted under the key to legitimate traffic and the escape sequences prefixing them. Some minor details involving resynchronizing when the PRNG happens to produce the same output as the expected encrypted escape sequence is left as an exercise for the reader. -- http://www.lightconsulting.com/~travis/ -><- "We already have enough fast, insecure systems." -- Schneier & Ferguson GPG fingerprint: 50A1 15C5 A9DE 23B9 ED98 C93E 38E9 204A 94C2 641B
In the context of:
If your plaintext consists primarily of small packets, you should set the MTU of the transporter to be small. This will cause fragmentation of the large packets, which is the price you have to pay. Conversely, if your plaintext consists primarily of large packets, you should make the MTU large. This means that a lot of bandwidth will be wasted on padding if/when there are small packets (e.g. keystrokes, TCP acks, and voice cells) but that's the price you have to pay to thwart traffic analysis.
Travis H. wrote:
I'm not so sure. If we're talking about thwarting traffic on the link level (real circuit) or on the virtual-circuit level, then you're adding, on average, a half-packet latency whenever you want to send a real packet.
I very much doubt it. Where did that factor of "half" come frome.
I don't see any reason why it's necessary to pay these costs if you abandon the idea of generating only equal-length packets
Ah, but if you generate unequal-length packets then they are vulnerable to length-analysis, which is a form of traffic analysis. I've seen analysis systems that do exactly this. So the question is, are you trying to thwart traffic analysis, or not?
I should point out that encrypting PRNG output may be pointless,
*is* pointless, as previously discussed.
and perhaps one optimization is to stop encrypting when switching on the chaff.
A better solution would be to leave the encryption on and use constants (not PRNG output) for the chaff, as previously discussed.
Some minor details involving resynchronizing when the PRNG happens to
The notion of synchronized PRNGs is IMHO crazy -- complicated as well as utterly unnecessary.
I very much doubt it. Where did that factor of "half" come frome.
During lulls, you are constantly sending chaff packets. On average, you're halfway through transmitting a chaff packet when you want to send a real one. The system has to wait for it to finish before sending another. QED.
Ah, but if you generate unequal-length packets then they are vulnerable to length-analysis, which is a form of traffic analysis.
I'm talking about a stream, with packets embedded in it. For circuit-switched circuits, this is no problem. For a packet-switched network, you must packetize the stream, which is unrelated to the packets embedded in the stream. This is somewhat inefficent, which is why I suggested that it is more applicable ot something like PPP, SSH, or OpenVPN links, which are already virtual circuits. This is a fair criticism, but just think of the number of such circuit/packet conversions when someone uses a TCP virtual circuit over packet-based IP over an analog POTS link, which is itself a virtual circuit that is packetized and sent over a circuit (long-haul wirepair or fiber) in the telco network. If you explain to me how an eavesdropper can tell where plaintext packet begins or ends, then I'll agree with you that it is indeed vulnerable to length analysis.
A better solution would be to leave the encryption on and use constants (not PRNG output) for the chaff, as previously discussed.
That might or might not be a problem. With ECB, it's vulnerable to analysis (chaff is constant, so encryption of it is constant). With some modes, the amount you can transmit is limited (e.g. CTR mode). Modes that are based on a small window of previous plaintext, such as OFB, would be vulnerable too. It could very well be that it's a bad idea to send a lot of constant plaintext under other modes, as well. For example, if most of the data is constant, then you have a close approximation of known-plaintext.
The notion of synchronized PRNGs is IMHO crazy -- complicated as well as utterly unnecessary.
It's not necessary to run a PRNG on the receiver. You just have to be able to tell when you're looking at random data, or an encrypted version of an escape sequence and a valid packet, which can be recognized, as per your point 4a. If you find that it's not a legitimate packet, you treat it as PRNG data, and start looking for the encrypted escape sequence. However, with a 32-bit escape sequence, the chances of getting such a false positive are low. I personally think sending encrypted versions of constant data under the same key you use for real data is not crazy, but somewhat imprudent. Do you know what the unicity distance is? Have you read of attacks that require a large amount of ciphertext encrypted under the same key? -- http://www.lightconsulting.com/~travis/ -><- "We already have enough fast, insecure systems." -- Schneier & Ferguson GPG fingerprint: 50A1 15C5 A9DE 23B9 ED98 C93E 38E9 204A 94C2 641B
Modes that are based on a small window of previous plaintext, such as OFB, would be vulnerable too.
My mistake, OFB does not have this property. I thought there was a common mode with this property, but it appears that I am mistaken. If it makes you feel any better, you can consider the PRNG the encryption of constant text, perhaps using the real datastream as some kind of IV. The content of the chaff is not relevant; ideally you would use a high-bandwidth HWRNG such as Quantis. -- http://www.lightconsulting.com/~travis/ -><- "We already have enough fast, insecure systems." -- Schneier & Ferguson GPG fingerprint: 50A1 15C5 A9DE 23B9 ED98 C93E 38E9 204A 94C2 641B
Travis H. wrote:
Part of the problem is using a packet-switched network; if we had circuit-based, then thwarting traffic analysis is easy; you just fill the link with random garbage when not transmitting packets. I considered doing this with SLIP back before broadband (back when my friend was my ISP). There are two problems with this; one, getting enough random data, and two, distinguishing the padding from the real data in a computationally efficient manner on the remote side without giving away anything to someone analyzing your traffic. I guess both problems could be solved by using synchronized PRNGs on both ends to generate the chaff. The two sides getting desynchronzied would be problematic. Please CC me with any ideas you might have on doing something like this, perhaps it will become useful again one day.
But this is trivial. Since the traffic is encrypted, you just have a bit that says "this is garbage" or "this is traffic". OTOH, this can leave you open to traffic marking attacks. George Danezis and I wrote a paper on a protocol (Minx) designed to avoid marking attacks by making all packets meaningful. You can find it here: http://www.cl.cam.ac.uk/users/gd216/minx.pdf. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff
On Tue, 2005-10-25 at 23:40 -0500, Travis H. wrote:
Many of the anonymity protocols require multiple participants, and thus are subject to what economists call "network externalities". The best example I can think of is Microsoft Office file formats. I don't buy MS Office because it's the best software at creating documents, but I have to buy it because the person in HR insists on making our timecards in Excel format.
1) You have told your HR person what a bad idea it is to introduce a dependency on a proprietary file format, right? 2) OpenOffice can read Excel spreadsheets, and I would assume it can save the changes back to them as well. -- Shawn K. Quinn <skquinn@speakeasy.net>
On Wed, Oct 26, 2005 at 08:41:48PM -0500, Shawn K. Quinn wrote:
1) You have told your HR person what a bad idea it is to introduce a dependency on a proprietary file format, right?
Telling is useless. Are you in a sufficient position of power to make them stop using it? I doubt it, because that person will be backed both by your and her boss. Almost always. It's never about merit, and not even money, but about predeployed base and interoperability. In today's world, you minimize the surprise on the opposite party's end if you stick with Redmondware. (Businessfolk hate surprises, especially complicated, technical, boring surprises).
2) OpenOffice can read Excel spreadsheets, and I would assume it can save the changes back to them as well.
OpenOffice & Co usually supports a subset of Word and Excel formats. If you want to randomly annoy your coworkers, use OpenOffice to process the documents in MS Office formats before passing them on, without telling what you're doing. Much hilarity will ensue. -- Eugen* Leitl <a href="http://leitl.org">leitl</a> ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE [demime 1.01d removed an attachment of type application/pgp-signature which had a name of signature.asc]
On 10/26/05, Shawn K. Quinn <skquinn@speakeasy.net> wrote:
On Tue, 2005-10-25 at 23:40 -0500, Travis H. wrote:
Many of the anonymity protocols require multiple participants, and thus are subject to what economists call "network externalities". The best example I can think of is Microsoft Office file formats. I don't buy MS Office because it's the best software at creating documents, but I have to buy it because the person in HR insists on making our timecards in Excel format.
1) You have told your HR person what a bad idea it is to introduce a dependency on a proprietary file format, right?
This is off-topic. Let's not degenerate into random Microsoft bashing. Keep the focus on anonymity. That's what the cypherpunks list is about. CP
At 8:18 PM -0700 10/27/05, cyphrpunk wrote:
Keep the focus on anonymity. That's what the cypherpunks list is about.
Please. The cypherpunks list is about anything we want it to be. At this stage in the lifecycle (post-nuclear-armageddon-weeds-in-the-rubble), it's more about the crazy bastards who are still here than it is about just about anything else. Cheers, RAH Who thinks anything Microsoft makes these days is, by definition, a security risk. -- ----------------- R. A. Hettinga <mailto: rah@ibuc.com> The Internet Bearer Underwriting Corporation <http://www.ibuc.com/> 44 Farquhar Street, Boston, MA 02131 USA "... however it may deserve respect for its usefulness and antiquity, [predicting the end of the world] has not been found agreeable to experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire'
On Thu, 2005-10-27 at 23:28 -0400, R.A. Hettinga wrote:
RAH Who thinks anything Microsoft makes these days is, by definition, a security risk.
Indeed, the amount of trust I'm willing to place in a piece of software is quite related to how much of its source code is available for review. Surprisingly, I'm not the only one that feels this way. -- Shawn K. Quinn <skquinn@speakeasy.net>
On Thu, Oct 27, 2005 at 11:28:42PM -0400, R.A. Hettinga wrote:
The cypherpunks list is about anything we want it to be. At this stage in the lifecycle (post-nuclear-armageddon-weeds-in-the-rubble), it's more about the crazy bastards who are still here than it is about just about anything else.
While I don't exactly know why the list died, I suspect it was the fact that most list nodes offered a feed full of spam, dropped dead quite frequently, and also overusing that "needs killing" thing (okay, it was funny for a while). The list needs not to stay dead, with some finite effort on our part (all of us) we can well resurrect it. If there's a real content there's even no need from all those forwards, to just fake a heartbeat. -- Eugen* Leitl <a href="http://leitl.org">leitl</a> ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE [demime 1.01d removed an attachment of type application/pgp-signature which had a name of signature.asc]
-- From: Eugen Leitl <eugen@leitl.org>
While I don't exactly know why the list died, I suspect it was the fact that most list nodes offered a feed full of spam, dropped dead quite frequently, and also overusing that "needs killing" thing (okay, it was funny for a while).
The list needs not to stay dead, with some finite effort on our part (all of us) we can well resurrect it. If there's a real content there's even no need from all those forwards, to just fake a heartbeat.
Since cryptography these days is routine and uncontroversial, there is no longer any strong reason for the cypherpunks list to continue to exist. I recently read up on the Kerberos protocol, and thought, "how primitive". Back in the bad old days, we did everything wrong, because we did not know any better. And of course, https sucks mightily because the threat model is both inappropriate to the real threats, and fails to correspond to the users mental model, or to routine practices on a wide variety of sites, hence users glibly click through all warning dialogs, most of which are mere noise anyway. These problems, however, are no explicitly political, and tend to be addressed on lists that are not explicitly political, leaving cypherpunks with little of substance. --digsig James A. Donald 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG AnKV4N6f9DgtOy+KkQ9QsiXcpQm+moX4U09FjLXP 4zfMeSzzCXNSr737bvqJ6ccbvDSu8fr66LbLEHedb
I don't agree. One thing we do know is that, although Crypto is available and, in special contexts, used, it's use in other contexts is almost counterproduct, sending up a red flag so that those that "Protect Our Freedoms" will come sniffing around and bring to bear their full arsenal of technologies and, possibly, dirty tricks. Merely knowing that you are using stego/crypto in such contexts can cause a lot of attention come your way, possibly in actual meatspace, which in many cases is almost worse than not using crypto at all In addition, although strong and "unbreakable" Crypto exists, one thing a stint on Cypherpunks teaches you is that it is only rarely implemented in such a way as to actually be unbreakable to a determined attacker, particularly if there are not many such cases to examine in such contexts. The clear moral of this story is that, to increase the odds of truly secure communication, etc, Crypto in such contexts must become much more ubiquitous, and I still think Cypherpunks has a role to play there and indeed has played that role. Such a role is, of course, far more than a mere cheerleading role,a fact that merits a continued existence for Cypherpunks in some form or another. -TD Only when Crypto is used ubiquitousl
From: "James A. Donald" <jamesd@echeque.com> To: cypherpunks@jfet.org Subject: Return of the death of cypherpunks. Date: Fri, 28 Oct 2005 12:09:36 -0700
-- From: Eugen Leitl <eugen@leitl.org>
While I don't exactly know why the list died, I suspect it was the fact that most list nodes offered a feed full of spam, dropped dead quite frequently, and also overusing that "needs killing" thing (okay, it was funny for a while).
The list needs not to stay dead, with some finite effort on our part (all of us) we can well resurrect it. If there's a real content there's even no need from all those forwards, to just fake a heartbeat.
Since cryptography these days is routine and uncontroversial, there is no longer any strong reason for the cypherpunks list to continue to exist.
I recently read up on the Kerberos protocol, and thought, "how primitive". Back in the bad old days, we did everything wrong, because we did not know any better. And of course, https sucks mightily because the threat model is both inappropriate to the real threats, and fails to correspond to the users mental model, or to routine practices on a wide variety of sites, hence users glibly click through all warning dialogs, most of which are mere noise anyway.
These problems, however, are no explicitly political, and tend to be addressed on lists that are not explicitly political, leaving cypherpunks with little of substance.
--digsig James A. Donald 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG AnKV4N6f9DgtOy+KkQ9QsiXcpQm+moX4U09FjLXP 4zfMeSzzCXNSr737bvqJ6ccbvDSu8fr66LbLEHedb
On Thu, 2005-10-27 at 20:18 -0700, cyphrpunk wrote:
This is off-topic. Let's not degenerate into random Microsoft bashing. Keep the focus on anonymity. That's what the cypherpunks list is about.
Sorry, but I have to disagree. I highly doubt that Microsoft is interested in helping users of their software preserve anonymity, in fact, evidence has surfaced to indicate quite the opposite. (GUID in Office? The obnoxious "product activation" requirement? I'm sure there are others.) I would say that helping others get rid of dependencies on Microsoft products is thus advancing the cause of anonymity in cyberspace. -- Shawn K. Quinn <skquinn@speakeasy.net>
cyphrpunk wrote:
The main threat to this illegal but widely practiced activity is legal action by copyright holders against individual traders. The only effective protection against these threats is the barrier that could be provided by anonymity. An effective, anonymous file sharing network would see rapid adoption and would be the number one driver for widespread use of anonymity.
If I thought I was being ripped off by anonymous file sharing, I'd try to push legislation that would mandate registering beforehand any download volume exceeding x per month. Downloaded more than x per month but not registered? Then you'll have to lay open your traffic, including encryption keys. The reasoning would be that most people won't have any legitimate business downloading more than x per month. By adjusting x, you can make a strong case. Once you get this enacted, you first get the ones with huge download volumes; then you lower x and repeat until the number of false positives gets too embarassing. If that seems drastic, just take a look at other legislation that has been enacted recently. I certainly believe that it's possible. Fun, Stephan [demime 1.01d removed an attachment of type text/x-vcard which had a name of neuhaus.vcf]
On 2005-10-26T08:21:08+0200, Stephan Neuhaus wrote:
cyphrpunk wrote:
The main threat to this illegal but widely practiced activity is legal action by copyright holders against individual traders. The only effective protection against these threats is the barrier that could be provided by anonymity. An effective, anonymous file sharing network would see rapid adoption and would be the number one driver for widespread use of anonymity.
If I thought I was being ripped off by anonymous file sharing, I'd try to push legislation that would mandate registering beforehand any download volume exceeding x per month. Downloaded more than x per month but not registered? Then you'll have to lay open your traffic, including encryption keys.
The reasoning would be that most people won't have any legitimate business downloading more than x per month. By adjusting x, you can make a strong case. Once you get this enacted, you first get the ones with huge download volumes; then you lower x and repeat until the number of false positives gets too embarassing.
This legislation would also require mandatory reporting by ISPs of subscribers' traffic patterns? "Most people don't have any legitimate business writing for public consumption on blogs." "Most people don't have any legitimate business owning cars that can go over 75MPH." "Most people don't have any legitimate business for owning more scary-looking black rifles." If you tried to push this hypothetical legislation, you'd end up on some cypherpunk's to-kill list. Of course, those threats are all hot-air. Has anyone who's life has been threatened on cypherpunks-l (since Jim Bell) gotten so much as a scratch at the hands of a threatener? -- This is not the grand arena.
participants (13)
-
Alexander Klimov -
Ben Laurie -
cyphrpunk -
Eugen Leitl -
James A. Donald -
John Denker -
Justin -
J�rn Schmidt -
R.A. Hettinga -
Shawn K. Quinn -
Stephan Neuhaus -
Travis H. -
Tyler Durden