- cypherpunks-legacy@lists.ogf.org

SUBSCRIBE
by umhc＠sunyit.edu 24 Aug '93

24 Aug '93

SUBSCRIBE --

1 0

Chaum criticism
by Kent Hastings 24 Aug '93

24 Aug '93

Chaum criticism#000# Hal Finney writes: > ... I think that Chaum has gone off in the wrong direction > in the last few years [by] concentrating on protocols which rely > on a tamper-proof, hardware ... "observer"... chip ... etc. Amen. > ... it seems that many of the papers out of his group are designed > to explore observer-based protocols. I am trying to read and understand the Niels Ferguson "Off-line Coins" article, the "Efficient Off-line Digital Cash" paper also from CWI and the Netcash paper. Were you the one critical of the Netcash paper because it didn't offer unconditional untraceability? Do the papers I just listed require observer chips, or are they OK for software-only? > This means that these ideas are not useful for software-only > implementations. One of the (relatively few) strengths that we > and the forces we represent have is that free software can be > spread very far and very fast, making it hard for those opposed > to privacy to successfully stop our efforts. Any technology based > on special chips is going to lose these advantages. We have PageMaker, CAD ware, someday we may have "ChipMaker" to create "chipscript" robotic control files to make our own monolithic IC's. In the short term, perhaps we can distribute shareware hardware designs using low-cost components to avoid back doors in manufactured comm gear. > ... people may still feel uncomfortable about having a > mechanical "conscience" in their pocket ... there have already > been comparisons on sci.crypt between Chaum's observers and > the Clipper chip ... In other words, if we can't see the "source code" for the hardware design, or "compile" it ourselves, maybe we shouldn't really trust it. > I think that a realistic appraisal of the pros and cons > suggests that non-observer protocols are more likely to > further our ultimate goal of personal privacy. What particular design would you like to see widely implemented now given these objections to observer chips? Is there software we can use NOW for ATM's and banks? Kent - jkhastings(a)aol.com

3 2

Large factoring attempt on RSA-129
by explorer＠iastate.edu 24 Aug '93

24 Aug '93

CALL FOR PARTICIPANTS --------------------- In 1977, a 129-digit integer appeared in the pages of Scientific American. This number, the RSA challenge modulus or RSA-129, has not yet been successfully factored. Factoring it, a 425-bit number, would be a major milestone in cryptography, as it would show that current technology is able to break commonly-used RSA-cryptosystem keys within a reasonable time. Excerpted from the RSA Factoring Challenge news: The "RSA challenge" published in the August 1977 issue of Scientific American (in Martin Gardner's column) is still open, and the $100 prize offer still stands. This prize can be won by factoring the RSA modulus published there, which is: RSA-129 = 11438162575788886766923577997614661201021829672124236256256184 29357069352457338978305971235639587050589890751475992900268795 43541 (129 digits, checksum = 105443) --- End of RSA Factoring Challenge news --- As with several other recent large scale factoring projects, we propose to attack this number with a very large number of workstations independently operating at dozens of research and corporate networks around the world. We are soliciting volunteers to provide compute cycles to help us towards our goal. With the permission of the authors, we will use the publicly available code of the Lenstra/Manasse Factoring by Email project, with modifications by Paul Leyland for RSA-129. The sieving will be distributed around the Internet, with relations transferred to a central site by email or ftp as convenient. Combining the relations and matrix elimination will be performed at ISU, using a combination of structured Gauss and a MasPar dense matrix eliminator. Each participant will be provided with complete source code for the siever. You can easily verify that the program takes no input from your machines and does not pose a security risk. It requires only an email connection to transmit partial results -- the software does not require communication with other machines except for this purpose. It is easy to install, and is designed so that it will take up no CPU cycles on your machine when interactive users or other important processes are active. If preferred, participants can accumulate the results locally and ftp them to the central site manually. The project currently has around 500 workstations which are ready to begin sieving. However, to finish in a reasonable amount of time, this count needs to increase greatly. We are attempting to enroll around 10,000 workstations in this project. This is a call for participants, who have workstations or MasPars at their disposal and would like to participate in this project. All contributions help a great deal. There is a $100 prize associated with factoring this number. The prize, if we win it, will be donated to the GNU project of the Free Software Foundation to help generate more of the excellent software they currently provide. For more information, please mail rsa129-request(a)iastate.edu. We will respond to all questions quickly. --Michael Graff [project coordinator/programmer] --Derek Atkins [coordinator/programmer] --Paul Leyland [advisor/programmer] --Daniel Ashlock [faculty advisor ISU]

1 0

Private Message to BlackNet
by anonymous＠extropia.wimsey.com 24 Aug '93

24 Aug '93

1 0

Wimsey Remailer Alive!
by anonymous＠extropia.wimsey.com 23 Aug '93

23 Aug '93

M. Stirner said here: "OK. It seems that remail(a)extropia.wimsey.com (#15) is down. This is a shame, as it was the _only_ remailer that would function as an anonymous remailer for me. It worked beautifully while it was up. Its apparent demise has been reported by other users as well," Reports of the wimsey remailer's demise are premature. I just used it to post this message! One possible cause of problems might be use of PGP version 2.3 or 2.3a WITHOUT the following set in CONFIG.TXT: pkcs_compat = 0 # Use backwards-compatible formats The PGP in use by the remailer may be version 2.0 or 2.1, which will not read PKCS-compatible PGP Messages. The wimsey remailer has an ingenious method of returning error messages anonymously. Specify a subject in the message sent to wimsey that will be meaningful to you, but won't identify you (like a set of random letters). This subject does not appear in the remailed message. Then subscribe to the mailing list errors-request(a)extropia.wimsey.com by sending a message with Subject: subscribe. You will receive a msg for ALL errors detected in incoming messages and ALL bounced messages. Errors in incoming messages are identified by the subject field. Errors from bounced messages are identified by the subject in the bounced message, which is specified following the To: line in the encrypted message sent to wimsey. Wimsey also has an anonymous reply mechanism using a message pool. For more info, send "help" to pool0-request(a)extropia.wimsey.com I think wimsey is also the only Cypherpunks remailer which resides outside the USA (It's in Canada). This obviously makes it much more inconvenient for USA Law Enforcement to broach the physical security of the remailer. Stirner also says: ". All other cypherpunks remailers, reliable or not, retain the footer addresses automagically inserted by the host box here & are therefore not in any way anonymous for my purposes. There was a discussion of a "cut line" syntax before I temporarily lost access to cypherpunks, but as far as I know there was never any agreement or implementation (I shall be pleased to be corrected if this is not the case)." I think the Hall Remailer at <nowhere(a)bsu-cs.bsu.edu> recognizes a "cut line" of --ignore-- I tried this and it failed the first time, but worked the second. You should try a message to yourself before relying on it. Unfortunately this remailer doesn't support encrypted remailing requests. You also may be able to alter or eliminate the automatic signature or footer produced by your BBS. Check your local documentation or ask your SYSOP.

1 0

Attacks on remailers
by hfinney＠shell.portal.com 23 Aug '93

23 Aug '93

Chaum, in his first paper on "Mixes" (anonymous remailers) described protocols which were designed to resist several attacks. (See the February, 1981, Communications of the ACM, p. 84.) These can be understood by considering a series of attacks of increasing sophis- tication, with corresponding responses. Our opponent has as his goal to track a message through a chain of remailers. Attack 1: Just intercept the message from the sender, and look at the commands of the form: :: Request-Remailing-To: first-remailer :: Request-Remailing-To: second-remailer :: Request-Remailing-To: final-destination The final command shows where the message is finally going to go. Response: Encrypt the messages. Use "nesting", so that all that is visible as each message leaves a remailer is the destination of the next remailer. Attack 2: Look at the mail logs on the system running the remailer to see which message goes out from the remailer account shortly after each message comes in. Response: Run the remailer on a machine which does not keep mail logs, or on a machine to which you can deny the attackers access. Attack 3: Monitor the messages in real time as they flow into and out of each remailer machine, again looking for the message which comes out just after each incoming message. Response: Batch up many messages which arrive over a period of time, only sending them out at regular intervals or when a certain number have accumulated. Send them out in random order. Alternatively, delay each message by a random amount of time before the message goes out. (This response will also deal with the previous attack.) Attack 4: Look at distinguishing features of the messages which are preserved by the remailers, such as subject line or message size, to match up incoming and outgoing messages within each batch. Response: Do not retain any header fields through remailers, not even subject. Use an encryption mode in which messages are rounded up to some standard size so that all messages appear to be the same size. Attack 5: Record an incoming message to the remailer, and insert a copy of it into the incoming message stream, so that the batch will have two identical messages. Look for two identical outgoing messages. Remove one. This is the match to that incoming message. Response: Check for duplicate incoming messages in the remailer, and remove all but one copy of each duplicate. Attack 6: Insert a duplicate message multiple times in separate batches. Observe the outgoing batches and look for a pattern of destinations which are correlated with those batches in which the incoming message is inserted. Response: Check for messages which have been duplicated from earlier batches and remove them. Include time/date stamps on incoming messages with a time limit so that they are no good after a certain number of days; this way the check for duplicates only has to go back that many days. Attack 7: Look at all messages coming out of the first remailer, and follow them into their 2nd remailers; take all messages from those and follow them on, and so on. This will eventually lead to a number of destinations, one of which must have been the destination of the original message. Over a period of time, look for correlations between destinations and sources. Response: Use large remailer chains of popular remailers. With enough mixing at each stage of the chain, the number of possible destinations will become astronomically large, making correlations statistically impossible. Attack 8: Correlate messages being sent from person A with messages being received a certain time later by person B. Even without the ability to track messages through the remailers this can show a communication pattern. Response: Send dummy messages at regular intervals, which bounce through the remailer network and then die. When you have a real message to send, replace one of the dummies with this. The sender's traffic pattern is then constant and no information can be gained from it. Attack 9: Bribe or coerce one or more remailer operators into revealing their keys, or into decrypting the desired messages. Alternatively, run many remailers, pretending to be dedicated to privacy, while secretly gathering information on the messages. Response: Use many remailers in a variety of geographical locations, so that it is unlikely that all of them can be corrupted in this way. These are all the attacks I can remember being implicitly considered in Chaum's paper. Other people who have ideas for attacks should mention them so we can think of responses. Chaum also discusses anonymous return addresses. We have a simple form of these enabled in our encrypting remailers. The idea is to encrypt a series of remailing requests for the path the message will follow, with the last request directing the message to the user whose anonymous address this is. Some more attacks are possible in this case: Attack 1A: Look at the message content as it passes through each remailer, to correlate incoming and outgoing messages. Response: Encrypt the message at each stage to prevent this matching. This raises the problem of how to determine the encryption key in such a way that the final user can decrypt the message. Chaum suggested including the encryption key in the anonymous address (a different key at each stage of the chain), so that the user can decrypt the message. Eric Messick has proposed letting the remailer choose the key, with a protocol for the user to communicate again with the remailer to get the message decrypted. Attack 1B: Send two different messages to the same return address with different contents, and look for duplicate address blocks in the outgoing batches. Response: Apply some randomization to the address blocks at each stage so that messages to the same address don't look identical. (Chaum did not give this solution, as he viewed the next attack as being essentially unanswerable.) Attack 1C: Send many addresses to the anonymous address, and look for a destination which receives that many messages in a correlated fashion. Response: Chaum's response is that the remailer must not accept more than one message with a given anonymous return address, just as it must not accept more than one copy of a message in the regular case. This implies that anonymous return addresses must be use-once to be truly secure. This conclusion is uncomfortable, as the requirement that an address be use-once will severely impair its usability. But this attack appears hard to avoid. There is always the possibility of giving up on anonymous addresses in the Chaumian sense, and instead using other ideas which have been suggested here, such as posting to newsgroups, or message broadcast pools. All of these ideas have the problem that they expose everyone in some group to all of the messages intended for every group member, hence the number of messages will scale as the square of the number of group members. This will quickly become unmanageable for large groups, therefore providing only a limited amount of anonymity. It's also worth noting that our remailers are vulnerable to almost all of these attacks; at best we are safe against two or three of them. Hal Finney hfinney(a)shell.portal.com

2 2

Re: "Secure Voice"
by wcs＠anchor.ho.att.com 23 Aug '93

23 Aug '93

geoffw(a)nexsys.net (Geoff White) writes: > Anybody know about the voice capabilities of the ZyXel class modems? > I own a ZyXel 1496E which can digitize voice and also transmit > voice data that has been digitized. It would be easy to > first encript this stream before sending it out. > The 1496E+ also support CELP (or is it (CLEP?) but that one > cost about $400. (The 1496E is around $300) It also is a 14.4 K > baud modem and does FAX. The ZyXel has a 68xxx and a DSP chip. It's able to digitize and compress voice, and also to play back digitized voice, and also to do 9600/14400 modeming, but it can't do all three at once. To build a secure voice phone with Zyxels, you'd need either 2 or 3 modems - one to handle the modem functions, one to compress the voice, and either the same or a separate one to play voice. But it's a good start. What I'd like to see is a SoundBlaster followon with a DSP chip. It IS possible to get DSP boards for PCs and I think for Macs, so you could build a system easily enough with a DSP board and a SoundBlaster, but the last time I checked, the DSP boards tended to be expensive and packaged with lots of fancy waveform analysis tools. Bill Stewart

2 1

Munged account feeding old mai
by s.summers1＠genie.geis.com 23 Aug '93

23 Aug '93

Subject: Munged account feeding old mail? >From Paul Ferguson: >Am I the only one getting carbon copies of many of my own messages >from someone else's munged account? Nope. Even got it here (twice)... Sean

1 0

Digicash
by plmoses＠unix.cc.emory.edu 23 Aug '93

23 Aug '93

>From hughes(a)toad.com Sun Aug 22 20:06:38 1993 >To: plmoses(a)unix.cc.emory.edu (Paul L. Moses) >Subject: [plmoses(a)unix.cc.emory.edu (Paul L. Moses): Digicash....I think] >Date: Sun, 22 Aug 93 17:06:29 -0700 >From: hughes(a)toad.com > >Mail to owner-cypherpunks goes to the bounce box, where it gets looked >at occasionally. Mail to cypherpunks(a)toad.com to send to the whole list. > >Eric > >------- Forwarded Message > >Return-Path: plmoses(a)unix.cc.emory.edu >Received: from emoryu1.cc.emory.edu ([128.140.1.1]) by toad.com id AA06687; Fri, 20 Aug 93 19:36:07 PDT >Received: by > emoryu1.cc.emory.edu (5.65/Emory_cc.3.4.6) via MAILPROG > id AA19400 ; Fri, 20 Aug 93 23:49:26 -0400 >Return-Path: plmoses(a)unix.cc.emory.edu >Date: Fri, 20 Aug 93 23:49:26 -0400 >From: plmoses(a)unix.cc.emory.edu (Paul L. Moses) >Message-Id: <9308210349.AA19400(a)emoryu1.cc.emory.edu> >To: owner-cypherpunks(a)toad.com >Subject: Digicash....I think > > >I hesitate to mention this, since I have *NO* idea of any of the mathematics >behind the digicash articles you all have mention....BUT... > >I was out running errands today and used my ATM card for a cash purchase. >This led me to think, aha, I could simply get this card "charged" every >so often with another denomination ($20, $50, $200, $2000, whatever) and >go around spending my money without the Store having to phone in the transaction. This raises a couple of thought in my mind, namely > 1) Reverse the function of current ATM units, ie use them to >"charge" (as in, activate, add money to) the BANK CARD, rather than the >opposite that we do now... > 2) Find some way to ensure that the card itself does not contain >an identifier, so that the user is not recorded during the transaction. > 3) The card then becomes a bearer instrument of sorts. No big deal; >IT'S JUST LIKE MONEY. People have to be careful with money, so they ought >to be careful with these things too. You could still probably use PIN #s >(personal code), since they're pretty generic and can be selected and >changed by the end user himself....whoops no, on second thought, not unless >the user can encode the PIN himself. Hmm. I dunno. PIN could be OK as long >as it was never recorded in the transaction, but there's the danger of the >transaction program taking a look surreptitiously... > > 4) Digicash exists already. I buy a copy card at the library and >put money onto it, then use it at will in the copy machines. If I lose the >card, I'm outta luck, cos anyone who finds it can use it. Primitive, single >function, but basically what this is about, I think? > >So, what I'm trying to say is that it is possible now to do this, without >any huge breakthrough or legal innovations. If I have missed something obvious, >please enlighten me (gently!). > >- -Paul > >------- End of Forwarded Message > >

3 2

Secure Voice
by Brian J Harvey 23 Aug '93

23 Aug '93

On 8/22/93 Harry Bartholomew mentioned a new "secure voice" product from SVC in College Station, TX. Does anyone have more info on this product, ie a phone number? Question: He states that they offer "lifetime upgrades" but also that they do not mantain cust. records (for privacy), so how does one find out about new releases. Wouldn't one need to "poll the company" to learn of a new release and wouldn't that turn into a headache for the company? (Assuming they've sold significant numbers) Brian

1 0