crypto on sonet is free, Tyler
At 03:15 PM 6/8/04 -0400, Tyler Durden wrote: Well, it's interesting to consider how/if that might be possible. SONET scrambles the payload prior to transmission..adding an additional crypto layer prior to transmission would mean changing the line rate, so probably a no-no. Tyler, one can implement crypto at *arbitrary* line rates though the use of multiple hardware engines and the right mode of operation. If you don't use crypto you are broadcasting, as well as accepting anything from anyone as authentic. Its that simple. Caveat receiver. --- Impeach or frag.
RE: crypto on sonet is free, Tyler
Yo Variola! Did you notice the date stamp on that post? Did you do a stint on Survivor or something? Or as I said to the short-lived Tom Veil, What, no Starbucks near your Unabomber shack? -TD From: Major Variola (ret) [EMAIL PROTECTED] To: [EMAIL PROTECTED] [EMAIL PROTECTED] Subject: crypto on sonet is free, Tyler Date: Tue, 25 Oct 2005 19:52:10 -0700 At 03:15 PM 6/8/04 -0400, Tyler Durden wrote: Well, it's interesting to consider how/if that might be possible. SONET scrambles the payload prior to transmission..adding an additional crypto layer prior to transmission would mean changing the line rate, so probably a no-no. Tyler, one can implement crypto at *arbitrary* line rates though the use of multiple hardware engines and the right mode of operation. If you don't use crypto you are broadcasting, as well as accepting anything from anyone as authentic. Its that simple. Caveat receiver. --- Impeach or frag.
Re: [PracticalSecurity] Anonymity - great technology but hardly used
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 begin:vcard fn:Stephan Neuhaus n:Neuhaus;Stephan org;quoted-printable:Universit=C3=A4t des Saarlandes;Department of Informatics adr;quoted-printable:;;Postfach 15 11 50;Saarbr=C3=BCcken;;66041;Germany email;internet:[EMAIL PROTECTED] title:Researcher tel;work:+49-681/302-64018 tel;fax:+49-681/302-64012 x-mozilla-html:FALSE url:http://www.st.cs.uni-sb.de/~neuhaus version:2.1 end:vcard
Re: [PracticalSecurity] Anonymity - great technology but hardly used
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. --
Re: On the orthogonality of anonymity to current market demand
From: R.A. Hettinga [EMAIL PROTECTED] Sent: Oct 25, 2005 8:34 AM To: cryptography@metzdowd.com, [EMAIL PROTECTED] Subject: On the orthogonality of anonymity to current market demand .. That is to say, your analysis conflicts with the whole trend towards T-0 trading, execution, clearing and settlement in the capital markets, and, frankly, with all payment in general as it gets increasingly granular and automated in nature. The faster you can trade or transact business with the surety that the asset in question is now irrevocably yours, the more trades and transactions you can do, which benefits not only the individual trader but markets as a whole. The prerequisite for all this is that when the asset changes hands, it's very nearly certain that this was the intention of the asset's previous owner. My point isn't to express my love for book-entry payment systems. There's plenty to hate about them. But if the alternative is an anonymous, irreversible payment system whose control lies in software running alongside three pieces of spyware on my Windows box, they probably still win for most people. Even bad payment systems are better than ones that let you have everything in your wallet stolen by a single attack. .. However anonymous irrevocability might offend one's senses and cause one to imagine the imminent heat-death of the financial universe (see Gibbon, below... :-)), I think that technology will instead step up to the challenge and become more secure as a result. What's with the heat-death nonsense? Physical bearer instruments imply stout locks and vaults and alarm systems and armed guards and all the rest, all the way down to infrastructure like police forces and armies (private or public) to avoid having the biggest gang end up owning all the gold. Electronic bearer instruments imply the same kinds of things, and the infrastructure for that isn't in place. It's like telling people to store their net worth in their homes, in gold. That can work, but you probably can't leave the cheapest lock sold at Home Depot on your front door and stick the gold coins in the same drawer where you used to keep your checkbook. And, since internet bearer transactions are, by their very design, more secure on public networks than book-entry transactions are in encrypted tunnels on private networks, they could even be said to be secure *in spite* of the fact that they're anonymous; that -- as it ever was in cryptography -- business can be transacted between two parties even though they don't know, or trust, each other. Why do you say internet bearer transactions are more secure? I can see more efficient, but why more secure? It looks to me like both kinds of payment system are susceptible to the same broad classes of attacks (bank misbehavior (for a short time), someone finding a software bug, someone breaking a crypto algorithm or protocol). What makes one more secure than the other? .. Cheers, RAH --John Kelsey
Re: [EMAIL PROTECTED]: Skype security evaluation]
On Mon, 24 Oct 2005, cyphrpunk wrote: Is it possible that Skype doesn't use RSA encryption? Or if they do, do they do it without using any padding, and is that safe? You may want to read the report itself: http://www.skype.com/security/files/2005-031%20security%20evaluation.pdf and perhaps section 3.2.3 (about padding) and 3.2.2 (about how RSA is used) may help with this (and what it is used for in section 2). Dw.
Re: [PracticalSecurity] Anonymity - great technology but hardly used
--- Travis H. [EMAIL PROTECTED] 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). Jörn __ Yahoo! Mail - PC Magazine Editors' Choice 2005 http://mail.yahoo.com
Re: [fc-discuss] Financial Cryptography Update: On Digital Cash-like Payment Systems
If you have to be that confident in your computer security to use the payment system, it's not going to have many clients. Maybe the trusted computing platform (palladium) may have something to offer after all, namely enabling naive users to use services that require confidence in their own security. One could argue it's like going to a Vegas casino; software vendors (MS *cough* MS) probably won't cheat you in such a system because they don't have to; the odds are in their favor already. The whole system is designed to assure they get paid, and they have a lot to lose (confidence in the platform) by cheating you (at least in ways that can be detected). And since you won't be able to do anything to compromise the security, you can't screw it up. While I wouldn't see an advantage in that, I might recommend it for my grandmother. More on topic, I recently heard about a scam involving differential reversibility between two remote payment systems. The fraudster sends you an email asking you to make a Western Union payment to a third party, and deposits the requested amount plus a bonus for you using paypal. The victim makes the irreversible payment using Western Union, and later finds out the credit card used to make the paypal payment was stolen when paypal reverses the transaction, leaving the victim short. -- 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
RE: [EMAIL PROTECTED]: Skype security evaluation]
Is it possible that Skype doesn't use RSA encryption? Or if they do, do
they do it without using any padding, and is that safe?
No ,Skype use RSA encryption:
Each party contributes 128 random bits toward the 256-bit session key.
The contributions are exchanged as RSA cryptograms. The two
contributions are then combined in a cryptographically-sound way to form
the shared session key.
I.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of cyphrpunk
Sent: Monday, October 24, 2005 8:51 PM
To: Travis H.
Cc: [EMAIL PROTECTED]; cryptography@metzdowd.com; [EMAIL PROTECTED]
Subject: Re: [EMAIL PROTECTED]: Skype security evaluation]
On 10/23/05, Travis H. [EMAIL PROTECTED] wrote:
My understanding of the peer-to-peer key agreement protocol (hereafter
p2pka) is based on section 3.3 and 3.4.2 and is something like this:
A - B: N_ab
B - A: N_ba
B - A: Sign{f(N_ab)}_a
A - B: Sign{f(N_ba)}_b
A - B: Sign{A, K_a}_SKYPE
B - A: Sign{B, K_b}_SKYPE
A - B: Sign{R_a}_a
B - A: Sign{R_b}_b
Session key SK_AB = g(R_a, R_b)
But what you have shown here has no encryption, hence no secrecy.
Surely RSA encryption must be used somewhere along the line. The report
doesn't say anything about the details of how that is done. In
particular, although it mentions RSA signature padding it says nothing
about RSA encryption padding.
Is it possible that Skype doesn't use RSA encryption? Or if they do, do
they do it without using any padding, and is that safe?
CP
-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to
[EMAIL PROTECTED]
-
This e-mail is intended for the addressee(s) named above. It may contain
confidential information, and any unauthorised disclosure, use or
dissemination, either in whole or in part, is prohibited. If you have received
this e-mail in error, please notify the sender immediately via e-mail and
delete this e-mail from your system.
Communications by e-mail are not subject to the same verification procedures as
paper-based communications, therefore this e-mail is in no way whatsoever
binding on the Bank of Latvia.
Re: [fc-discuss] Financial Cryptography Update: On Digital Cash-like Payment Systems
John Kelsey wrote: From: cyphrpunk [EMAIL PROTECTED] Digital wallets will require real security in user PCs. Still I don't see why we don't already have this problem with online banking and similar financial services. Couldn't a virus today steal people's passwords and command their banks to transfer funds, just as easily as the fraud described above? To the extent that this is not happening, the threat against ecash may not happen either. Well, one difference is that those transactions can often be undone, if imperfectly at times. The whole set of transactions is logged in many different places, and if there's an attack, there's some reasonable hope of getting the money back. And that said, there have been reports of spyware stealing passwords for online banking systems, and of course, there are tons of phishing and pharming schemes to get the account passwords in a more straightforward way. Right, the Microsoft operating system as host for virus / malware attack for stealing bank and payment systems value has been going on for a couple of years or so in a serious (industrial) way. The payment system operators will surely be sued for this, because they're the only ones who will be reachable. They will go broke, and the users will be out their money, and nobody will be silly enough to make their mistake again. They might be sued but they won't necessarily go broke. It depends on how deep the pockets are suing them compared to their own, and most especially it depends on whether they win or lose the lawsuit. I don't think so. Suppose there's a widespread attack that steals money from tens of thousands of users of this payment technology. That sounds like a version of phishing, 'cept for being 2 orders of magnitude too small. There seem to be two choices: a. The payment system somehow makes good on their losses. b. Everyone who isn't dead or insane pulls every dime left in that system out, knowing that they could be next. Er, no, that doesn't sound like any finance system I know. See that post to the Register which I think RAH forwarded, with 2000 in the class. That's just this week's news. As per my observations, all FC systems bubble along with something about 1% fraud plus/minus an order of magnitude. The credit card people currently report about 0.1-0.2 % although I think that might be under- reporting on their part. Out of that, some people might get recovered, but enough do not that we wouldn't be able to push proposition b. with any strength. We know for example that even though the banks might recover any direct losses, they won't accept liability for any other costs including where their fault caused problems elsewhere. iang
Legally thwarting FBI surveillance of libraries and ISPs
I'm one of those that believes that agrees with Louis Brandice's dissenting opinion about the constitutionality of wiretaps. That they violate the privacy of those parties who call or are called by the party being wiretapped. I have written on this in 2002/2003. There seem to be at least two legal ways to both obey court orders and also allow the monitored parties a way to learn of the activity. 1 - The basic notion is for the University/ISP/library to allow all its premises to be bugged. Every room (except maybe the restroom) by its clients (or their proxies). All communication could be monitored and the ISP would have no control. My understanding of court orders is that they must be served on the ISP at its business address. Once the order is opened or discussed by the designated employee who receives the data all its clients would know in short order. The employees and management will not have been responsible because they have not taken any affirmative actions to allow the information to escape their custody. They will have protected the info with the same diligence they show their own data. ;-) 2 - Alternatively, the organization implements a policy of replying positively to all inquiries if asked by a patron/student the when their account is free of such court orders. If a request does come in then the db admin can either: fail to respond (monitoring implied), tell them they are being monitored (violating the law) or lie and say they are not even if they are. They can charge a fee for this service and use it as a new revenue source. Looks like at least one library is trying a variation the method I suggested... The Patriot Act also prohibits libraries and others from notifying patrons and others that an investigation is ongoing. At least one library has tried a solution to beat the system by regularly informing the board of directors that there are no investigations. If the director does not notify the Board that there are no investigations, it can serve as a clue that something may be happening. http://www.ombwatch.org/article/articleview/1706/1/41 Can the Feds require a librarian to lie to a customer who inquires whether their library usage is being monitored? 3 - For libraries another is available. Libraries routinely assess overdue fines and thus most have a cash register at the checkout desk. If they allow patrons to remove books without showing ID and charge them, as a refundable deposit, the full replacement value in cash, then no records need be created which can be turned over to law enforcement. A receipt might be provided to the patron showing them the last day they may return the book without forfeiting the deposit. They can charge a fee for this service and use it as a new revenue source. Steve
Re: [PracticalSecurity] Anonymity - great technology but hardly used
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.
Re: [PracticalSecurity] Anonymity - great technology but hardly used
On Wed, 26 Oct 2005, JЖrn Schmidt wrote: --- Travis H. [EMAIL PROTECTED] 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
Re: [fc-discuss] Financial Cryptography Update: On Digital Cash-like Payment Systems
-- Steve Schear [EMAIL PROTECTED] Yes, but unfortunately it is not clear at all that courts would find the opposite, either. If a lawsuit names the currency issuer as a defendant, which it almost certainly would, a judge might order the issuer's finances frozen or impose other measures which would impair its business survival while trying to sort out who is at fault. It would take someone with real cojones to go forward with a business venture of this type in such uncharted waters. Anyone can sue for anything. Paypal is entirely located in the US, making it easy to sue, has done numerous bad things, but no court orders have been issued to put it out of business. If a business's main assets are gold located in offshore banks, courts are apt to be quite reluctant to attempt to shut it down, as issuing ineffectual or difficult to enforce orders makes a judge look stupid. People fuss too much about what courts might do. Courts are as apt, perhaps more apt, to issue outrageous orders if you are as innocent. as the dawn. Courts are like terrorists in that there is no point in worrying what might offend the terrorists, because they are just as likely to target you no matter what you do. Government regulators are a bigger problem, since they are apt to forbid any business model they do not understand, but they tend to be more predictable than courts. --digsig James A. Donald 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG CY46prGSdN80nLrJL5G79zdH2Uu2lRjQHD9mlSsf 4JTEpYw1dnco9AMX6Fvv3Uce0bPsG1TJYg+qpwG5n
Re: On the orthogonality of anonymity to current market demand
-- John Kelsey What's with the heat-death nonsense? Physical bearer instruments imply stout locks and vaults and alarm systems and armed guards and all the rest, all the way down to infrastructure like police forces and armies (private or public) to avoid having the biggest gang end up owning all the gold. Electronic bearer instruments imply the same kinds of things, and the infrastructure for that isn't in place. It's like telling people to store their net worth in their homes, in gold. That can work, but you probably can't leave the cheapest lock sold at Home Depot on your front door and stick the gold coins in the same drawer where you used to keep your checkbook. Some of us get spyware more than others. Further, genuinely secure systems are now becoming available, notably Symbian. While many people are rightly concerned that DRM will ultimately mean that the big corporation, and thus the state, has root access to their computers and the owner does not, it also means that trojans, viruses, and malware does not. DRM enables secure signing of transactions, and secure storage of blinded valuable secrets, since DRM binds the data to the software, and provides a secure channel to the user. So secrets representing ID, and secrets representing value, can only be manipulated by the software that is supposed to be manipulating it. --digsig James A. Donald 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG 3CepcQ59MYKAZTizEycP1vkZBbexwbyiobaC/bXS 44hfxMF4PBKXmc5uavnegOFFCMtNwDmpIMxLBcyI3
packet traffic analysis
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!
Re: [PracticalSecurity] Anonymity - great technology but hardly used
Hello, At 25/10/05 07:18, cyphrpunk wrote: 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. ...snip... 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. ...snip... I agree with what you say, especially regarding the frustration with TOR, but I am not sure it contradicts the message I tried to lay out in my post. Secure browsing is one instance of anonymity applications, which, as I mentioned, is used. I completely agree that technology may not be mature enough for this other instance of anonymity applications, which is anonymous file sharing. My point was that there is a lot of anonymity-related technology that is not used, especially in the field of finance; I did not claim that there are technological solutions available for each and every anonymity problem out there. I apologize if this spirit was not communicated well. It's not that we have everything - it's that we don't use most of what we do have, although we once spent a lot of efforts designing it. Regards, Hagai.
