December 2003 - cypherpunks-legacy

Re: Latency vs. Reordering (Was: Remailer ideas (Was: Re: Latency vs. Reordering))
by jdd＠aiki.demon.co.uk 17 Dec '03

17 Dec '03

In message <199408080514.WAA28015(a)netcom7.netcom.com> "Timothy C. May" writes: > Jim Dixon writes: > (quoting Hal Finney) > > > If this idea seems valid, it suggests that the real worth of a network of > > > remailers is to try to assure that there are at least some honest ones > > > in your path. It's not to add security in terms of message mixing; a > > > single remailer seems to really provide all that you need. > > > > Yes, in an ideal world. Each additional remailer introduces another > > chance of being compromised. > > No, I'm afraid you have this backwards. A remailer cannot introduce > a chance of increase the chance of being compromised. There are at least two models of remailer networks being kicked around. In what I have called RemailerNet, if a gateway is compromised, then some degree of traffic analysis is possible, and other parts of the system become less secure. Security increases when there are two remailers handling your traffic, because then neither should know the identity of both sender and receiver. Whether the addition of more intervening remailers increases the security of the system in RemailerNet is a complex question. In the second model of remailer networks, I also believe that using more than two remailers and the random selection of remailers decreases the security of the system if there is regular traffic between correspondents. To argue this at all, one would need a much clearer model with all of the assumptions spelled out in detail. For the argument to be interesting, the model would have to be realistic. My personal impression is that the second model is highly insecure in cases where there is regular traffic between two parties and some third party has significant resources. -- Jim Dixon

1 0

RemailerNet v0.2
by jdd＠aiki.demon.co.uk 17 Dec '03

17 Dec '03

RemailerNet v0.2 (RN0.2 for short) 1.0 a number N of RN gateways exist 1.1 these communicate using encrypted packets of a fixed length L 1.2 messages may originate from gateways or from outside the network 1.3 messages are passed across the network in packets 1.4 a packet may contain data from 0, 1, or more messages 1.5 routing of the packets is randomized (this does not mean that the probability of a route being chosen is equal for all routes, it means that if N>2, there is no route for which the probability is 1) 1.6 the order of dispatch of packets is randomized 1.7 on average, all gateways are required to send and receive the same number of packets per unit of chronological time 1.8 the dispatch randomization function adjusts the average latency and the distribution of latencies so that the preceding commitment is met, introducing noise packets as required 1.9 mechanisms allow the traffic level to rise quickly but constrain them to fall slowly 1.10 gateways are required to exchange the same number of packets in any session 1.11 inter-gateway connections may be either open at all times (in which case sessions begin only when the connection has gone down by accident) or they may be established periodically 2.0 any message has a source gateway and a destination gateway 2.1 message fragmentation takes place at the source gateway 2.2 message reassembly takes place at the destination gateway 2.3 all packets are acknowledged 2.4 message delivery is reliable, in the sense that the destination gateway will report delivery of incomplete or damaged messages to the gateway 2.5 messages may be sent to a gateway for forwarding to another gateway 2.6 message delivery time can be specified 2.7 message delivery policy can be specified 2.8 delivery policies include (a) hold until picked up, (b) hold for a specified period of time, (c) discard if not received immediately 2.9 gateways should always destroy mail after delivery is acknowledged [unless the mail is to an as-yet-unspecified persistent store] 3.0 gateways frequently exchange routing information 3.1 that routing information has an expiration date 3.2 gateway operators can choose who they announce routing information to and accept routing information from 3.3 gateways can settle accounts with one another periodically 4.0 level 2 gateways will communicate with one another using RN protocols using IP datagrams 4.1 level 1 and 2 gateways will communicate using the same protocols using email (SMTP) datagrams 4.2 where gateways are operated by users, the requirement that gateways should exchange the same number of packets per unit time would be weakened in some as yet unspecified way 5.0 end users may either operate gateways or communicate with a level 1 or 2 gateway using email 5.1 in either case, users may have accounts with gateways and may be charged for usage 6.0 RN gateway software should be available only from trusted sites by FTP 6.1 RN bootstrap software should be available on diskette 6.2 the bootstrap software should allow the secure downloading of system updates over RemailerNet 7.0 an alt.? group could be used to announce new gateways 7.1 established gateways would be encouraged to rate new gateways 7.2 software updates would be announced in the alt.? group 7.3 a FAQ would be published in the alt.? group every ten days or so 8.0 users would be encouraged to use gateways in geographically distant locations -- Jim Dixon [adding the notion of a persistent store would allow the creation of electronic safety deposit boxes]

2 1

RE: CreditCard info
by Mike Markley 17 Dec '03

17 Dec '03

Garth Brown writes: ---------- | From: Garth Brown (Semaphore Software) <v-garthb> | To: <cypherpunks(a)toad.com>; <owner-cypherpunks(a)toad.com> | Subject: RE: CreditCard info | Date: Sunday, August 07, 1994 5:41PM | | It's my understanding that it's technically illegal for anyone to require | your SSN for anything if they are not using it for SS related purposes. | I had heard that congress passed a law when SSNs were issued to this | effect. | | Am I hallucinating, or has someone else heard this too?! | I have heard this also. On a related note it is also no longer legal to require credit cards for identification when writing a check. Mike. ===================================================== Mike Markley <mmarkley(a)microsoft.com> I'm not a Microsoft spokesperson. All opinions expressed here are mine. =====================================================

1 0

TOMMY THE TOURIST IS COMPROMISED DON'T USE IT
by Jeff Gostin 17 Dec '03

17 Dec '03

Tommy the Tourist (Anon User) <nobody(a)CSUA.Berkeley.EDU> writes: > Tommy the Tourist is compromised, it is possible to trace who sent the > message from the anonymous remiler called "Tommy the Tourist" > Anonymity cannot be assured, please direct anonymous traffic through > other anonymous remailers. I'll believe you when you post this signed with TtT's PGP key? Is there a 'punk that can verify this, or is just an assanine game played by adolesents? --Jeff -- ====== ====== +----------------jgostin(a)eternal.pha.pa.us----------------+ == == | The new, improved, environmentally safe, bigger, better,| == == -= | faster, hypo-allergenic, AND politically correct .sig. | ==== ====== | Now with a new fresh lemon scent! | PGP Key Available +---------------------------------------------------------+

2 1

Re: reordering
by tcmay＠netcom.com 17 Dec '03

17 Dec '03

Steve Witham writes: > > (Oh, you mean the key is to _randomly reorder_ the messages, not just > > delay them by an hour when the average number of messages in an hour > > is less than 1 anyway? Oh, now I see. Never mind!) > > > > --Tim May, who is as tired as Eric is of hearing the hoary old > > chestnuts about 'random delays,' this without regard to calculating > > the amount of reordering. > > Tim, you sound like you mean calculating the amount of reordering based > on the delay vs. average traffic--exactly what Eric is arguing against! > The thing is to write the software to do reordering directly, not > calculate how much it's going to do after you've written it... No, I mean that if it is desired to reorder with a batch of 10 messages (10 messages in, 10 messages out), then that's what one does, whether it takes 10 minutes or 10 hours to get this many messages. I think in my last paragraph above I made it clear that "random delays" are a lose, generally, and that the "amount of reordering" is what's needed. --Tim May -- .......................................................................... Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay(a)netcom.com | anonymous networks, digital pseudonyms, zero 408-688-5409 | knowledge, reputations, information markets, W.A.S.T.E.: Aptos, CA | black markets, collapse of governments. Higher Power: 2^859433 | Public Key: PGP and MailSafe available. "National borders are just speed bumps on the information superhighway."

1 0

Re: Improved remailer reordering
by jdd＠aiki.demon.co.uk 17 Dec '03

17 Dec '03

In message <199408081502.IAA08127(a)jobe.shell.portal.com> Hal writes: > >You need not pass over the 'flaw of lack of message quantization in > >the final sending'. Someone running a private high security gateway, > >an "empowered user", participates in the same way as the other RemailerNet > >gateways, and there is in fact no way to determine even whether he is > >sending or receiving, or in fact whether he is doing anything at all. > >He may be just sending and receiving noise packets. > > >Users accessing the net using low security versions of the software do > >have less security, but that is a consequence of their use of low > >security software. > > I could see this would come up in Jim's description. Who exactly are these > "empowered users"? And how much security do the second-class citizens ac- > tually get? Will it work for everyone to become "empowered", or are there > scaling problems in terms of bandwidth? > > It seems to me that the most sensible approach is to make message fragmen- > tation into standard-sized packets, along with reassembly, be at the > end user site. This way everyone becomes a first-class citizen. I think that you want at least three levels in this system, with increasingly strong requirements as you go up the levels and (necessarily) increasingly weak security as you go down. You should be able to pop messages into the system from any terminal anywhere, just using ordinary email. But you should also be able to casually dump a few hundred megabytes into the system without making too big a splash, if you have the right equipment. Ideally, the empowered user's (your term, yes?) system is functionally a gateway, but it has a nice front end on it, something like Mosaic. It is probably a single user system with a RemailerNet interface bolted on to it; it probably runs under Windows; it may even be a modified version of Mosaic. The system at the next level up is a workhorse. Its user interface would be a system manager's, designed to show him how traffic is flowing, highlighting bottlenecks, etc. It would be designed to run automatically. -- Jim Dixon

1 0

PGP 2.6 for UNIX
by dwomack＠runner.utsa.edu 17 Dec '03

17 Dec '03

I've been having difficulty compiling PGP 2.6 for UNIX V, Release 4.0. There *_were_* some compiled executables out there for 2.3, but I've failed to find the same for the 2.6 version. Any ideas? Thanks! Dave

1 0

Re: Digicash address?
by Vinod Valloppillil 17 Dec '03

17 Dec '03

If you're looking for info on digicash, it might be more polite to mail to info(a)digicash.nl than to mail directly to David Chaum's account.... Vinod ---------- From: Dave Banisar <tc(a)phantom.com> To: Adam Shostack <adam(a)bwh.harvard.edu> Cc: Cypherpunks Mailing List <cypherpunks(a)toad.com> Subject: Re: Digicash address? Date: Monday, August 08, 1994 8:53AM You can reach David Chaum at chaum(a)digicash.nl -dave On Mon, 8 Aug 1994, Adam Shostack wrote: > > Could someone send me contact information for David Chaum's > Digicash company? An email address would be great... > > Thanks in advance, > > Adam >

1 0

Re: Digicash address?
by jim＠bilbo.suite.com 17 Dec '03

17 Dec '03

I see others have posted e-mail addresses..here's DigiCash's Web URL in case you're looking for general info: http://digicash.support.nl/ Jim_Miller(a)suite.com

1 0

RE: Remailer ideas
by John Douceur 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- >From: Eric Hughes <hughes(a)ah.com> >Date: Saturday, August 06, 1994 4:02PM >Hal's random-send spool has an expected value of latency which is >approximately the size of the spool but has no deterministic upper >bound for that latency. Fine. Great. No problem. There should be >zero hesitation here, because the expected value -- the probabilistic >average -- is what you want. There is an important distinction between systems for which the only observable behavior is the probabilistic average and those for which the observable behavior is that of the individual actions. An example of the former system is a hash table with open addressing: The absolute worst case for a lookup is as bad as that in an unsorted list; however, this is not usually a problem, because programs generally perform large numbers of lookups, and the performance that the user observes is therefore equal to the probabilistic average. An example of the latter system is the case in point, a remailer: If a message is delayed unduly, the sender is unlikely to be contented by the fact that many other users' messages were serviced with considerably greater promptness. Therefore, the probabilistic distribution of service times is as important a metric of a remailer's performance as the probabilistic average service time. It may thus be quite reasonable to build in a hard cutoff in service time, such that any message that has been delayed by more than a set amount will be guaranteed to be sent on the next transmission. For some user of the remailer, this will make an observable improvement in performance; and since the extreme delay which triggers the expedited transmission is an unpredictable and infrequent event, it will not make cryptanalysis of the remailer any easier. JD -----BEGIN PGP SIGNATURE----- Version: 2.6 iQCVAgUBLkaHjEGHwsdH+oN9AQGOjAP/eCDAPlVfsdzB7HsBO5FLmFaxt5udMAPE UrFYw1EvrFP8gbMd6976dU6+o/A6xtDbZXCN8UOX5SYsY4+ixWxR3X5x86f4VAPi BowglJWs9hrGH/iSGH1tk2+ehbpFNKA4vUlvRtjKfX5vudYr5+fHWjCndFiVTo6K VXy0N2iQI4U= =uTv6 -----END PGP SIGNATURE-----

2 1