December 2003 - cypherpunks-legacy

TOMMY THE TOURIST IS COMPROMISED DON'T USE IT
by Tommy the Tourist 17 Dec '03

17 Dec '03

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. ------------ To respond to the sender of this message, send mail to remailer(a)soda.berkeley.edu, starting your message with the following 8 lines: :: Response-Key: the-clipper-key ====Encrypted-Sender-Begin==== MI@```%Q^&2?(E<U9BPG1]W7L'=6KH_SN(JMX.Q@RG7^7D(SA%FB(8Q2K4A!M M*VFU=N2XN6?V.C4S.N7*XRQ"*_P0<S5^+Z$37-UG%HN:!,.D5QTC_#9^S][: '.U5H*[Z8-P`` ====Encrypted-Sender-End====

2 1

SSN Quandary (was: CreditCard info)
by Garth Brown 17 Dec '03

17 Dec '03

---------- | From: "Pat Farrell" <pfarrell(a)netcom.com> | | I'm sure that you are correct. I talked just this past Friday to | David Banistar at EPIC/CPSR on this. But the law seems to | be mostly ignored, as is the fact that SSN's are not unique. | | The key is, what do we do about it? I routinely refuse to give my SSN to agencies that have no government affiliation. I've been hassled for this stance, and frequently refused service/credit. My phone company demanded an exorbitant deposit because I wouldn't give them my SSN when signing for service. I am greatly disturbed by the amount of personal information currently available on an individual, and accessible with keys as simple as SSN, full name, and mother's maiden name. I, however, have no clue what to do other than continue to refuse to supply data whenever possible. garthB> ------------------------------------------------------------------------------ Garth S. Brown, Semaphore Corporation 122 South Jackson Street, Suite 350 garthb(a)semaphore.com Seattle, Washington 98104 InterNIC WHOIS: GB(31) -Public key available via finger of garthb(a)semaphore.com -PGP2.6 Key fingerprint = 65 0E 48 A1 F7 38 DB 03 3F 77 77 9E B5 53 2E 96 ------------------------------------------------------------------------------ All problems can be solved with the proper application of high explosives.

1 0

Looking for info on PGP enabling mail apps. . . .
by Garth Brown 17 Dec '03

17 Dec '03

i'm looking for info on enabling automatic PGP signing of mail messages from PINE and ELM. Perhaps i'm babbling about something in a FAQ i missed, in which case i'll filter flames to /dev/null. =) thanks garthB> ------------------------------------------------------------------------------ Garth S. Brown, Semaphore Corporation 122 South Jackson Street, Suite 350 garthb(a)semaphore.com Seattle, Washington 98104 InterNIC WHOIS: GB(31) -Public key available via finger of garthb(a)semaphore.com -PGP2.6 Key fingerprint = 65 0E 48 A1 F7 38 DB 03 3F 77 77 9E B5 53 2E 96 ------------------------------------------------------------------------------ All problems can be solved with the proper application of high explosives.

2 1

Anonymous Transport Agents (Was: Latency vs. Reordering)
by Jeff Gostin 17 Dec '03

17 Dec '03

hughes(a)ah.com (Eric Hughes) writes: > Simulating any of the salient features of a link encryptor over the > Internet is an interesting exercise, particularly in regard to price > negotiation with your service provider. I'm about to branch into the limits of my knowledge on this particular topic: I run a DOS site under a heavily modified version of Waffle (1.65 base), so the Unix-ish transport mechanisms are a tad out of my realm of knowledge. With that in mind... Suppose an encryption-savvy mail transport agent, say ESMTP, was developed. Further suppose that part of handshaking protocol for this transport protocol included an ENCRYPTED reverse lookup on IP identities to check that the message is actually coming from where it claims it's coming from. Suppose again that the results of this lookup were only checked for correctness (boolean), and then discarded WITHOUT LOGGING, or at least with minimal logging. If the reverse lookup was TRUE (IE: the sending machine was who it said it was), the message was accepted. If it failed, the message would be accepted, and then sent to the bit bucket. In this model, one could provide anonymous transportation of anonymous mail FOR EVERY MACHINE ON INTERNET providing that the original message wasn't forged. All that would be required (beyond running ESMTP) is an encrypted version of the return address (a la Soda remailer) to be placed some predetermined place in the message. This seems too easy: What am I missing? Have I actually come up with a way to do this? --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: Problem in draft FIPS `CRYPTOGRAPHIC SERVICE CALLS'
by koontzd＠lrcs.loral.com 17 Dec '03

17 Dec '03

It appears to be an attempt to formalize the interface to the Tessera card. The file cryptcal.txt can be found on csrc.ncsl.nist.gov

1 0

RE: CreditCard info
by sidney＠taurus.apple.com 17 Dec '03

17 Dec '03

[various people speculated about legality of a company requiring your SSN] There's a Social Security Number FAQ posted regularly on alt.privacy, and also available from the usual usenet FAQ sites. It says that government agencies in the U.S. have restrictions regarding asking for and using your SSN, but private sector organizations do not. There's a lot more detail, but I don't need to repeat it here. -- sidney <sidney(a)apple.com>

1 0

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

17 Dec '03

In message <9408072325.AA18643(a)ah.com> Eric Hughes writes: > Imagine a RemailerNet (v0.2) that maintained a fixed level of > traffic between gateways. > > This is exactly what I was talking about when I posted earlier about > link encryptors, and effective collapse of nodes for traffic analysis > purposes. Traffic analysis of mixes and remailers assumes, as an > abstraction, that all the messages going into and coming out of a > particular node are visible. As soon as you remove this condition, > the analytical situation changes completely. There is little difference between RemailNet v0.1 and v0.2 in this regard. Fragmenting messages into packets of fixed length, randomizing routing, and noise injection were all present in v0.1. > The problem with implementation of link encryption is, like everything > else, cost. Link encryption off the Internet requires dedicated > lines. I think that there is some confusion here. Time is defined in terms of steps, each one of which represents the dispatch of one packet. The packets can be received and dispatched in batches. > In general, the messages do not exist > as wholes along the lines connecting the gateways, so a discussion of > their reordering is a good way to waste time. > > You still have to worry about reordering in the network as a whole. > The system you've described has reassembly done at the endpoints, who > might not be the final receiver. I pass over the flaw of lack of > message quantization in the final sending of reassembled messages. > We may assume for discussion that they're all the same length. 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. > Now, you still need to calculate the likelihood that a particular > outgoing message is the same message as a particular incoming message. > These probabilities have to do with message reordering. You still > need to do the calculation. Some of the discussion here is at cross purposes. My focus has been on specifying a system which is itself very difficult to attack using cryptoanalytic techniques. An "empowered" user of RemailerNet v0.2 who sends messages via a system which acts as a gateway need not worry very much about traffic analysis. A user whose access to RemailerNet is via a low security system will be exposed to a higher level of risk. Which factors are the most important element in causing risk depend upon the nature of the traffic through the system and the size and geographic distribution of the network itself. A functioning RemailerNet with widely distributed gateways and at least a moderate level of traffic from at least a moderate number of widely distributed users is not easily subjected to what I might call external traffic analysis. Essentially, you make a model of the system which removes many of the features that defeat traffic analysis and then say, hey, this thing is easily subject to traffic analysis. Well, if you go far enough, sure. -- Jim Dixon

2 1

RE: CreditCard info
by rah＠shipwright.com 17 Dec '03

17 Dec '03

At 11:49 PM 8/7/94 -0500, Brian Lane wrote: > ....in 10 years all >newborns will have a small uP implanted into their hand(ala Demolition >Man) that will keep track of all their electronic data. Scares the crap >out of me. We just had thread about that. I had brought up Gerry O'Neill's old book "2081", which had a discussion of buying things by picking them up and walking away with them (everything, including you, had an identifying transponder). There was some talk about Xerox PARC's work with transponders in their "Ubiquitous Computing" office concept. What I didn't understand was how to implement Esther Dyson's idea about people owning all their personal information and protecting all that "property" with strong crypto. Paradoxically, I bet both these ideas (transponders and personal information as property through strong crypto) can work together. Cheers, Bob Hettinga ----------------- Robert Hettinga (rah(a)shipwright.com) "There is no difference between someone Shipwright Development Corporation who eats too little and sees Heaven and 44 Farquhar Street someone who drinks too much and sees Boston, MA 02331 USA snakes." -- Bertrand Russell (617) 323-7923

1 0

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