- cypherpunks-legacy@lists.ogf.org

Remailer Reliability
by norm＠netcom.com 05 Sep '93

05 Sep '93

sameer(a)netcom.com (Sameer Parekh) says: > Didn't someone mention a while back a scheme by which a > message can be split up into a bunch of parts and only requires about > 50% of them or so to be completely rebuilt? Something like that would > be very useful I think to deal with remailer reliability problems. > That would require a good deal more user work though. There was a paper sometime back (10 years I would guess) called "Sharing Secrets". For any j and k such that 0<j<k you could arrange that the secret was divided into k parts, any j of which sufficed to reconstruct the secret. Each part was the size of the secret. Any collection of less than k parts yielded absolutly no information even with exhaustive search. If I have a third degree real polynomial y=f(x) and have computed y for six different values of x then the polynomial can be resonstituted from knowing any four of those <x, y> pairs. The secret was the value of f(x) for yet another public value of x. The paper described how to do this in finite fields.

1 0

Two digital cash technical papers
by nobody＠shell.portal.com 05 Sep '93

05 Sep '93

There are two papers at ftp.cwi.nl descibing some of the mathemathics, /pub/CWIreports/CS/CS-R9318.ps.Z and /pub/CWIreports/CS/CS-R9323.ps.Z CS-R9318 N. Ferguson "Single Term Off-Line Coins" CS-R9323 Stefan Brands "An Efficient Off-line Electronic Cash System Based On The Representation Problem"

1 0

Re: Gubment Bombmaker's Cookbook
by George A. Gleason 05 Sep '93

05 Sep '93

This case brings up the same larger issue as does privacy in all its forms: the question of whether and to what degree the protection of the Bill of Rights extends into the realm of electronic media. I strongly suggest it's time to start a grassroots campaign for a new constitutional amendment which extends all constitutional protections to include and encompass "any electronic or optical or other means of information storage, processing, and communication." With a relatively liberal, pro-technology administration in the White House, this stands a better chance of passing now than it did a few years ago. A constitutional amendment would put BBSs etc. on the same footing as the spoken word and the printed page. Without this, we're doomed to a future of petty tyrrany and censorship. -gg

1 0

A question about pasting
by nobody＠eli-remailer 05 Sep '93

05 Sep '93

-----BEGIN PGP SIGNED MESSAGE----- This probably a naive question, but: Is there any way, using a remailer, to paste something into the header that will provide a return address (different from the reamiler's) that can be recognized by a garden variety unix mail program? Because it seems to me that if it is, then it would be possible to set up a mail forwarding site that would work in the following way: 1. A user would send in and register, possibly (preferably) via a remailer chain, a public-key and a remailer return address. A remailer return address would be a PGP encrypted command bundled with a remailer address; the PGP command would cause the remailer to forward the mail to the user through a chain of remailers. 2. These would be stored under an alias, either user-defined or automatically allocated (like anon.penet.fi). 3. Once registered, the server would send encrypted mail back to the user via the chain, and request that the user take some specific action (ie., send mail with the a random ten character string in the subject line, or whatever) to verify the address. This would prevent people from creating anonymous identities that forwarded mail to someone else. 4. Once the identity was registered and confirmed, then whenever mail is sent to that address, the forwarder will encrypt it with the public key and use the remailer chain to forward the mail. The identity of the person sending mail to the alias and the subject line would be buried in the cyhpertext. 5. The server will also make the public key of all identities available via a mail request, so that signatures can be verified by people who want to do that. The whole point of this is that it would then be possible to have mail that's very secure (except for traffic analysis). You could use PGP encrypted outgoing mail to everyone, even people who don't know or care about remailers. Your sysadmin wouldn't know what your outgoing mail contained or who it was to. None of the people operating remailers would know that either, because you're using a chain. If you could paste a line into a header that would allow others to mail to your alias by just pressing 'r' on their mailer, then you wouldn't be asking your correspondents to sacrifice any convenience on their end. The people running the alias server wouldn't know who you really were, and niether would any of the people running the remailers on on the encrypted return chain. The result of all this would be that all of your incoming and outgoing mail would be encrypted, and the identities of your correspondents would be hidden, as would the contents of your letters; and you wouldn't be depending upon any single person to hold your secrets for you, because none of the individual remailers would be able to piece anything together, and the alias server wouldn't know anything about you at all. And all of this would be 100% compatible with the existing email system (you could communicate with non-participants). It's almost an axiom that any simple idea like this can't work, or else it would already be implemented. That suggests to me that you *can't* paste something in the header that will automatically route replies to an alias rather than back to where the letter came from. Is that the case? Alex astrashe(a)nyx.cs.du.edu -----BEGIN PGP SIGNATURE----- Version: 2.3a iQCVAgUBLImSLbGKvmrRrQghAQGs8QQAsVR4TKqKEda04dYarEuwWgwN5eejQbKP SCdRwEYhl7UhzcVuTCoRezHeqLYWa56a00hBu3qGY+HE/0VPWns7bmNodt4Ykdxl sbpPfwTwS+dPDrQBUAIhYSxT1A1dxhjkI5uKK7zj4PqbUjcp0e9BBuiClQk6Yz3K WXmsJ3byvEw= =xMN5 -----END PGP SIGNATURE-----

1 0

REMAIL: sendmail invocation
by Karl Barrus 05 Sep '93

05 Sep '93

I just adjusted the sendmail invocation in the remailer scripts on menudo to include the -oi option ("/usr/lib/sendmail -oi "). This option tells sendmail to not treat a period on a line by itself as the end of input. (I remember having fun posting a message where I showed forging a usenet post - my post had such a line, and the rest of the message kept on getting truncated. Miron brought the -oi option to our attention!) However, it just occured to me that this is a simple, if unplanned, way for people who have signatures automatically appended to messages to use a remailer and have trailing lines cut! No fancy "cut here" marks for the scripts to recognize, let sendmail do the work! On the other hand, I plan to not use sendmail in the long run. I plan to upgrade to an smtp package (hopefully to avoid logging like syslog) sent to me by Peter Honeyman, so I'm going to leave the sendmail invocation with -oi. -- Karl L. Barrus - klbarrus(a)owlnet.rice.edu

1 0

REMAIL: RIPEM and PGP remailer
by Karl Lui Barrus 05 Sep '93

05 Sep '93

-----BEGIN PGP SIGNED MESSAGE----- Cypherpunks, I have turned my old account (elee9sf(a)menudo.uh.edu) into a cypherpunks remailer that supports BOTH pgp and ripem. In addition to the pgp pasting token :: Encrypted: PGP there is also a ripem pasting token :: Encrypted: RIPEM I've just tested the remailer with pgp, ripem, pgp nested inside ripem, and ripem nested inside pgp, and all the messages have come back successfully. The installation went fairly quickly with Sameer's scripts; I essentially added the necessary lines to the maildelivery file, copied the pgpmail.pl file to ripemmail.pl (that's what I indicated in the maildelivery file), altered ripemmail.pl to recognize RIPEM message delimiters, and changed around the string that is built with the $system call. I apologize to those who have asked for a RIPEM remailer for taking so long; I was bogged down trying to get RIPEM compiled on rosebud, an HP/UX (cc, c89, -Aa flags: nothing worked; no gcc or disk space to install gcc, unproto didn't help - I now think the compiler is way broken). The only drawback is that account is due to expire sometime. Plus, if many people decide to support ripem in addition to pgp the scripts are going to need some reworking :-) In order to update the dos batch files I'll need an MSDOS ripem executable - has anyone seen any? (Apparently I don't have a command line compiler to build it myself; I have Turbo C++ for Windows) Here are the public keys: For the pgp half - -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.3a mQCNAiyIBzwAAAEEALgRUlovklKVnasbE6qyNB82RL8emHh6+BwRwt49Yqt/YJaP Yl7V6k83/pnTE4w73S6rcWBo9jrSH1u1/Fcz7uUbRmGhteuMBEnB64wPqbxKEIrt vKJAx4xuNkTPGeNBCGOq5RtiEHbEt99hKF2H6lk9iLb8UwQCnV45xNlD3J7pAAUT tCByZW1haWxlciA8ZWxlZTlzZkBtZW51ZG8udWguZWR1PokAlQIFECyICuyDgOzq S1rWMwEBE44D/3Wwl0SLFvcN6BHe3BJhh6m1KBs3pRXsy2SBGN/y3+/NVRHbYhgy Q0MLEAPJ0PZnsJjH1pIyEDnoybcIvFyd5B3e9txawQJvaq238dyuzj5nzaTxe43H KUlh52fJzLCvXNa035p5ApvkaD1PpdAo6Vk3BGuYGOtEtGQLzLFntaqv =kIeo - -----END PGP PUBLIC KEY BLOCK----- and for the ripem half - -----BEGIN PUBLIC KEY----- User: elee9sf(a)menudo.uh.edu PublicKeyInfo: MFowCgYEVQgBAQICAgkDTAAwSQJCAXLNDW+7UU+XsgEfhDVdhgH0gq68Ss056URr 3VDg7lSUu61anW2wABEeVEzCgQwYR4/hYdV3rojbADx9UOAp+cOzAgMBAAE= MD5OfPublicKey: B6DB0C696304C9092F8A4493326461D3 - -----END PUBLIC KEY----- -----BEGIN PGP SIGNATURE----- Version: 2.3a iQCVAgUBLIlj+YOA7OpLWtYzAQEx8gP/YejO5r9+dCAQa2jdypuQTQmZOeLvXZLu UKK9sfn6Q2HJu0cp+ll0JVKh4qujLCmCFgFAeXwMbdBibJLByIowKzul6W0dNUEq haLRnhrI/iGiDO9VgD8463TpA7BHxM13t7iJp5TaaYI3KfwIxj7J6H43bjr9Ea6u aniKxu5WrDI= =imPY -----END PGP SIGNATURE----- Karl L. Barrus: klbarrus(a)owlnet.rice.edu keyID: 5AD633 hash: D1 59 9D 48 72 E9 19 D5 3D F3 93 7E 81 B5 CC 32 "One man's mnemonic is another man's cryptography" - my compilers prof discussing file naming in public directories

1 0

Denning in Govt Comp News
by L. Detweiler 05 Sep '93

05 Sep '93

FYI, on sci.crypt W.H. Murray passes along quotes of D. Denning in an article in Government Computer News, p14, Aug. 30, 1993 by Kevin Power. If anyone could scan this for the cypherpunk collection it would be appreciated. ===cut=here=== From: WHMurray(a)DOCKMASTER.NCSC.MIL Subject: Denning on Skipjack Date: Fri, 3 Sep 1993 00:25:00 GMT In Government Computer News, p14, August 30, 1993, Kevin Power quotes Dorothy Denning as saying "I am 100 percent certain that there are no weak keys." William Hugh Murray, Executive Consultant, Information System Security 49 Locust Avenue, Suite 104; New Canaan, Connecticut 06840 1-0-ATT-0-700-WMURRAY; WHMurray at DOCKMASTER.NCSC.MIL From: WHMurray(a)DOCKMASTER.NCSC.MIL Subject: And again, Denning on SKIPJACK Date: Fri, 3 Sep 1993 02:30:00 GMT In the same article kevin Power quotes Denning as having said "The people at NSA have done more to evaluate than the public algorithm in DES. They're way ahead of the game." I hope Dr. Denning never said anything like that for the record. Even if it were true, it would not be knowable. It would be unprofessional to make such an unscientific assertion. William Hugh Murray, Executive Consultant, Information System Security 49 Locust Avenue, Suite 104; New Canaan, Connecticut 06840 1-0-ATT-0-700-WMURRAY; WHMurray at DOCKMASTER.NCSC.MIL From: WHMurray(a)DOCKMASTER.NCSC.MIL Subject: Denning and the cost of attack against SKIPJACK Date: Fri, 3 Sep 1993 02:20:00 GMT On page 14 of the August 30, 1993 issue of Government Computer News Kevin Power reports that Dorothy Denning told the Computer System Security and Privacy Advisory Board that SKIPJACK would not be compromised by exhaustive attack methods in the next 30 to 40 years. [...]

1 0

Phil Z Comments on ViaCrypt
by edgar＠spectrx.Saigon.COM 05 Sep '93

05 Sep '93

I received the following comments on ViaCrypt from Phil Z. Reposting here with permission. I'll try to forward a summary of your comments. ==================================================================== Subject: Re: Your visit To: spectrx!edgar (Edgar W. Swank) *Edgar* Date: Wed, 1 Sep 93 20:40:08 MDT From: Philip Zimmermann <szebra!columbine.cgd.ucar.EDU!prz> Hello Edgar. Thanks for your hospitality. I enjoyed our conversations during my visit. The PKP/Viacrypt contract requires that ViaCrypt use THEIR OWN RSA cryptographic engine, not PKP's or RSADSI's. I will be working closely with them to ensure that they do a good job on that. Actually, RSA calculations are fairly straightforward, and it's hard to screw them up. I will probably try to get them to stick with my own keygen routines, if they are allowed to use them in the PKP contract. The keygen stuff would be the most important place to look for any security holes. My discussions with ViaCrypt's president, Lenny Mikus, and his programming staff, suggest to me that they are genuinely interested in making a very secure product. It's possible, I suppose, that maybe I could talk to ViaCrypt about maybe publishing the source code for the rest of ViaCrypt PGP, minus the RSA engines that the PKP contract won't let them publish. We'll see. The current plans are for them to use the straight PGP source code with no changes except for using their own RSA engines. So publishing the source code would not yield many new insights anyway, since it's the same. Other than as a confidence builder, which is nice to have. You may repost this to cypherpunks if you wish. Phil -- edgar(a)spectrx.saigon.com (Edgar W. Swank) SPECTROX SYSTEMS +1.408.252.1005 Cupertino, Ca

1 0

Re: Remailer Reliability
by doug＠netcom5.netcom.com 05 Sep '93

05 Sep '93

sameer(a)netcom.com (Sameer Parekh) >install-script I can add this little feature. Which newsgroup? Should >someone create an alt.remail? How exactly would it be implemented? I'm >thinking that simply the user would do: > [...] > And the remailer would post to alt.remail: There are two problems here. One is that the remailer exposes itself and defeats traffic analysis avoidance. The other is a standard transaction processing sort of problem; the posting to alt.remail might fail even though all else worked. Although I've dealt with transaction processing problems, it's a tricky area, and I don't have a good text on the subject. Any recommendations? b44729(a)achilles.ctd.anl.gov (Samuel Pigg) said: >By breaking a message into pieces and sending them via different paths >to the same destination ("path forking"), this can only make traffic >analysis easier, because all the pieces lead to the same destination, >and you can follow any of them to get to the anonymous recipient. Depends on how it's done. As stated this analysis implies that traffic analysis is *always* possible, since after all, the message must somehow make it to its destination. In other words, I disagree. Traffic analysers will have access to only some limited subset of information. If a certain kind of blind remailing with multiple pathways is practiced, then traffic analysis can be statistically defeated. The bad guys might sometimes know that X sent a message somewhere. Other times they might know Y received a message. Only improbably (under ideal implementation circumstances) would powerful bad guys own so many machines & networks that they would be able to deduce both sender and recipient, and even then, if traffic were heavy (as it will be in some years), it would be a statistical rather than certain deduction. (This of course raises the (no doubt old-hat) problem that no single remailer can be trusted, since it might be in the hands of the NSA or KGB or something. In fact, since the NSA is famous for doing their job well, this list must have NSA watchers, no question, even without paranoia, and if I were them I'd be experimenting with remailers even now, to keep up with trends. We'll never know how many remailers are trustworthy, so we'll have to use statistical schemes to make compromise unlikely.) This is all standard parallel remailing stuff. Add to this the possibility that the different remailing paths may contain message fragments rather than full messages, and it doesn't really change the security relative to full message parallel remailing...unless it's done badly. Badly would mean that some remailer is the one that finally recombines fragments prior to final delivery. Better is if the recipient's host does the recombination (and I worry about *that*, too). This needs to be done in conjunction with other standard cypherpunk fare, of course. The major design problem I've had is not with security, it's with fault tolerance. Statistical fault tolerance is available, but I prefer leaving that kind to the underlying base systems and networks, and trying to find a top level algorithm that is 100% guaranteed to either work or report failure, so long as the host systems/networks don't fail undetectably. A handshake ACK of receipt would help, except that it might not get back even if the original reached its destination. Which is why I'm starting to think I need to research transaction processing more thoroughly; some years back I'd heard that a centralized server was still state of the art for 100% fail-safe/soft operation. Is this still the case? If so, then we'll have to fall back on probabilistic fault-tolerance, to avoid issues of central authority compromise. >follow them all), as only one will arrive there and the rest would die >after a number of remailer hops. This is actually less safe than an approach which requires multiple pieces to arrive via multiple paths. Bad luck might leave your one path completely in the hands of bad guys (posing as cypherpunks, let's say). >I really think that non-deterministic "smart messages" are the way to >go here. This I agree with; but the way that is done is critical. >A simple command language for the remailers would allow >the header construction software already being worked on by >ebrandt(a)jarthur.Claremont.EDU (CRM) and others to use tricks >like this to defend against attacks. Cool. More info? > The defense complexity would be a function of the users' >header construction software and needs. People who need "minimal" >anonymity would have simpler anonymous address blocks, as compared to >those who require "serious" anonymity, and the remailers themselves >would have a lighter load (not having to implement very serious >security for *all* messages-- just those that need it). Strongly agree. BTW I consider this emphasis on batch mail to be short sighted. I'm designing for interactive cyberspace. I have a complete algorithm in mind, except I think it still needs some more OLTP wisdom added in. People have been telling me for a long while that I should hook up with cypherpunks; seeing traffic over the last week since I joined shows me why I heard that from so many sources. Tip of the hat to y'all; this is a much juicier forum than I had guessed. I only hope I can continue weathering the storm of heavy traffic, on top of other email lists. :-) Doug

3 3

CRM (again)
by nobody＠shell.portal.com 04 Sep '93

04 Sep '93

-----BEGIN PGP SIGNED MESSAGE----- (Note: this was sent through a remailer, and the return address is inaccurate. My address is astrashe(a)nyx.cs.du.edu.) | I'm not saying that CRM actually uses a command language (it can't-- | nothing has been agreed upon/worked out yet!) but tools like CRM | would be able to use a remailer command language to tailor the | message's (or anonymous address block's) anonymity protection. | See that same long, boring post I made about a few suggestions | for what such a language could contain/be useful with. CRM doesn't do anything grandiose. All it does is pick a random path of a specified length from a list of remailers, and wrap up an input file with remailing requests, encrypted PGP tags, and nested PGP encryptions. For example, if you start out with a file like: - -+---snip----- Subject: Just a test... I'm going to wrap up this file with CRM and make a /bin/sh script that will mail it to myself through a chain of remailers. - -+---snip----- and do one of these: c:\>crm infile astrashe(a)nyx.cs.du.edu you'll end up (with no further intervention on your part) with the /bin/sh script that's at the end of this post. If you run that script, it will mail the above short note to me through a chain of three remailers. Each of the remailers gets PGP encrypted input. The subject line will show up as the subject on my mailer. (Please don't run the script; my mailbox is full enough already.) The reason I had CRM wrap the final output in a script is that because the chain of remailers is random, the first remailer in the chain varies each time CRM is invoked. This way you don't have to worry about keeping track which one to mail the cyphertext to. This is obviously more of a hassle than using elm to send your mail; but if you're already writing letters offline and uploading them (which you ought to be doing anyway, to take full advantage of PGP's protection), it's only marginally more difficult than mailing stuff without the remailers. And it could be argued that it's *easier* to use CRM and the remailers than standard mailing, because the shell script keeps track of the subject lines and the destination for you. You could write ten letters, wrap them with CRM, keep concatenating the new scripts onto a outgoing mail file, then upload the whole thing at once and mail it in one fell swoop. If you want a copy of CRM, let me know. (Write to astrashe(a)nyx.cs.du.edu, not the return address on this post). It's an msdos program, written in turbo pascal. - -+---snip----- #!/bin/sh # # This is a shell script produced by CRM. # sed -e '/^BEGINCRM/d' -e '/^ENDCRM/d' << \End_of_File > crm.tmp BEGINCRM :: Encrypted: PGP - -----BEGIN PGP MESSAGE----- Version: 2.3a hIwCPhjICRQCw4kBBACpc6PDQEH8FR03Y1nO1IgMiG/ypCqe9c4oFcZzmx8jQaJ+ hDLpM5VcCHCGEQJUcmd0i3FCOFw1qKsWY612BdYMETPGpfDvK7SOqTmzBESF/NHE VhYgUuk06AYlhpcH5hNZ85DDXJLVLL7EJ/sLWy2mmV0p3CrIHK0aljddQmPbbKYA AAL0GwZ1Z+1XUvIhKpyk2W4l2fbrGdfflox5TQy8MuBkgSAxelm5DNNdYz7IDD5w G1X0G/YETmOs//7u7xL8gPAx2dYUi2raLSCXJ941Y4FtRc2W2Eci4M0uiDIYbTNT 45YBFW+emw6jawLvwKj5jlF2QAqn/6wuT1Px+azZSS39z8jyzcClhEEaEQSGBGcg o1NpSR6Bk9myQG5hEezB7j92s+D6D6APkTtc/LgyX/UG3jkCt86dbrhljoGQcIku NDS2lWHEJEXUJ4I/QwL8gwZLKcVkyxW1h8GB1Y8/LjfhnrjQXjig1jumPqbzOmBu 1u4exeV/kFADW2iDq8trjzkcBI7k/xGljtkaR1I9lVhIimyMz8bUr1WYuUte5u4P 4SxK9lSdS8TnK4pDwaubDL41aZ4eERNxuquerXbH1x3L7eDbUuerSI+vCM4uinWS c/ZDsIGYc0xgNzg4bq9ji04KK/FA6Y5HsnKAkdNV2V65GaNxk8IwAlkSQBygvf0R kdwOkJ+Y1L+k05lkI7N5AXOF+5cZQMw2oZElsF9pvbflzRIkJJBn+//Zx9cDJE6I SaISCg/c/DFeuH21zyv06Xrs8kRvX7183dD6I40RuGx5pg5eOalbBZFTqda5PV6w C6jtv2GxjfNYmOFLo/7uRpscrfAr2APvdR6/cTfb869tR22DcfYUOI5COxU0VH++ Lwq5Z6wVykrYWSZbUePO0MjzzRWCnAYOdlbJN0qFJXceNSKKIjYwZR/M4HlUTwYn 14jIfgvekaKWXL2ydk11S2eCPl9GrbNyptJUSjVteMFO333xjeoPMKST/yybvVsH JTlKy0XfmV3jUzjiOxy2yCLxeTJRjXFK8gKtIPpgfD1TEYdBELDTbQSbqm0f4aWE uHFEMI59IHPS0Dunu+Yn2QNyCw0NJbvclBUyYqrRFMyPT8R4V8qECYwZtcHbtP2z eJxRlQNx43GHfS5GxgQdJGB4Urb0y3AhsuEm+gWYoX6xuJSQ+GRX =42WF - -----END PGP MESSAGE----- ENDCRM End_of_File mail remail(a)tamsun.tamu.edu < crm.tmp rm crm.tmp - -+---snip----- - -+ Alex Strasheim | astrashe(a)nyx.cs.du.edu | PGP public key available via finger -----BEGIN PGP SIGNATURE----- Version: 2.3a iQCVAgUBLIj1fLGKvmrRrQghAQEniQP7BSeTbv9NtzMFAryrXAH0l6HdQ6dFTgxK AdWGts1zxGhJxoBO+ULwnaApuVgJoFz9iKEJ5GWWjpvs6f4tlG69MiTrb6vTW+0+ H8ceNIC15uyUWQR0fyy28SqgQhQLB2Ys3Y54fPDU5kvZKxa6hi38ZY6hTIg4b8BY 6zWwiGnJI2w= =kQ9/ -----END PGP SIGNATURE-----

1 0