- cypherpunks-legacy - lists.cpunks.org

Crypto Chip in Eastern Europe
by adam.philipp＠ties.org 17 Dec '03

17 Dec '03

Does anyone know any more details on the crypto chip listed in the HTML http://jep.pld.ttu.ee/? It seems that this is a hardware PGP (uses RSA to encrypt IDEA key) project. They mention having prototype available RSN, as in December... or is this just some very interesting vapor-ware? Adam Philipp -- PGP Key available on the keyservers. Encrypted E-mail welcome. Sub rosa: Confidential, secret, not for publication. -Black's Law Dictionary

1 0

NYT on MS Network
by John Young 17 Dec '03

17 Dec '03

Laurie Flynn writes today twofer on MS Network and newbie 1/3 pres Robert Herbold. For combo send blank message with subject: NET_puf

1 0

Re: PGP .DLL
by Jonathan Cooper 17 Dec '03

17 Dec '03

> How do you plan to prevent passwords, plaintext, etc. being saved > in swap files, etc.? Munge the memory where they've been stored. There is really no way to protect absolutely, especially on something as unsecure as a PC where someone malevolent could just install a keyboard logger... It comes down to a "how-much-is-enough" question. -jon ( --------[ Jonathan D. Cooper ]--------[ entropy(a)intnet.net ]-------- ) ( PGP 2.6.2 keyprint: 31 50 8F 82 B9 79 ED C4 5B 12 A0 35 E0 9B C0 01 )

1 0

Re: School Admins
by Jonathan Cooper 17 Dec '03

17 Dec '03

> You definitely shouldn't be doing that! Unless you make it very clear to > the users that they should not have any expectation of privacy when using > the school's computers, then e-mail is covered by the Electronic Like I've told other people, it's easy to be objective when the rest of your life isn't on the line. But my college plans _DIRECTLY_ involve these people, and I can't afford to piss them off. And yes, the students now know that they're being logged, and I've taught them to use cheesy crypt(1) encryption to handle it. -jon ( --------[ Jonathan D. Cooper ]--------[ entropy(a)intnet.net ]-------- ) ( PGP 2.6.2 keyprint: 31 50 8F 82 B9 79 ED C4 5B 12 A0 35 E0 9B C0 01 )

1 0

Re: PGP .DLL
by Jonathan Cooper 17 Dec '03

17 Dec '03

> I'm way behind on messages currently, so maybe somebody mentioned > this... but have you looked at RSAREF? I know the license is > restrictive, but take a look at it architecturally. That is basically the way that I'd envisioned it functioning. Details have to be nailed down... anyone who is interested in helping, please mail me so we can take this chatter off the main cypherpunks list. -jon ( --------[ Jonathan D. Cooper ]--------[ entropy(a)intnet.net ]-------- ) ( PGP 2.6.2 keyprint: 31 50 8F 82 B9 79 ED C4 5B 12 A0 35 E0 9B C0 01 )

1 0

test file
by Gary Jeffers 17 Dec '03

17 Dec '03

This is only a test file.

1 0

Making Terminal Remailers Foreign
by Gary Jeffers 17 Dec '03

17 Dec '03

THIS TEXT FOR EDUCATIONAL USE ONLY. I DO NOT ADVOCATE THE BREAKING OF ANY LAW OR OF PROVOKING CIVIL LAW ACTIONS. MAKING TERMINAL REMAILERS FOREIGN Dear Cypherpunks, I have been concerned about the security of remailers & their ops & I think I have found a scheme to give them an extra magnitude of safety. With some little reflection, it is obvious that an indiscreet user could compromise the safety of a remailer & its op. The reckless user could violate local laws or could provoke civil legal actions, or could be "politically or culturally indiscreet". My general software solution could give a safety net to the remailer w/ op. Firstly, I would like to provide a small glossary: Collector remailer - The 1st remailer in a remailer chain. Fortress remailer - A remailer that, due to technological devices, is safe from all political, legal, & technical attacks. An ideal - no such thing yet. Hardened remailer - A remailer with security between that of a State Sufferance remailer & a Fortress remailer. Does not allow itself to be used as a domestic terminal remailer. It may have other political & technological safeties as well. This kind of remailer is the subject of this post. Inner link remailer - An inner remailer; between the collector & the terminal remailers. State sufferance remailer - A remailer that has no political or software safeties. Allows itself to be used as a domestic terminal remailer. Terminal remailer - The last remailer in the chain. My plan concerns making the terminal remailer more secure. Obviously, the terminal remailer takes the most heat & needs more security. The extra security should be easily achieved by putting code into the remailer that says: "If mail being delivered to another remailer, then continue; If mail being delivered to a foreign country, then continue; If mail being delivered to a a domestic end user (not remailer), then deliver that mail to a foreign remailer & instruct it to deliver to end user." This scheme would insure that for that remailer, all mail deliveries would be foreign. If there were legal or political problems, then that remailer would be protected by its foreign jurisdiction. This safety would not be bulletproof, but it would greatly raise the cost of hassling the remailer. A cautious remailer operator might choose a remailer in a country with really bad diplomatic relations with his own host country. This scheme has the advantage that it could be easily implemented by the concerned remailer operator without depending on cooperation by others. It would also seem to be a fairly simple coding problem. Due to the extra security provided to the terminal remailer, the remailer user should also be more secure. In fact, I believe it would make the whole chain more secure. PUSH EM BACK! PUSH EM BACK! WWWAAAYYY BBBAAACCCCK! BBBEEEAAATTTT STATE! Gary Jeffers

3 2

REMAILER PROPOSAL
by Sandy Sandfort 17 Dec '03

17 Dec '03

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ SANDY SANDFORT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C'punks, I put together the following proposal to demonstrate a quick and dirty way to implement a pay-to-play remailer system. I don't care much about the details. Change any of them you feel like. My main concern is the basic pre-paid postage system concept. If those of you who are--or plan to be--remailer operators like it, it's yours. No charge. If you don't like it, well, I guess it's back to the old drawing board. S a n d y P.S. I love the name Spoon-E; everyone else will probably hate it. Consider it one of those details that you should feel free to change. * * * THE ELECTRONIC MAIL FORWARDERS GUILD A Proposal In this Proposal, I briefly discuss the elements a mail forwarders guild might include. My main purpose, however, is to outline a low-tech, anonymous postage system that such a guild could deploy today. My proposed system is intended to serve only as a bridge until a more sophisticated, digital postage/money system is available on the Net. MISSION STATEMENT--The purpose of the Electronic Mail Forwarders Guild (EMFG) would be to: 1. Encourage the proliferation and use of privacy oriented electronic mail forwarding sites, 2. Encourage the adoption of privacy oriented electronic mail forwarding standards and protocols, 3. Create and deploy new products and services on existing electronic mail forwarding sites, 4. To provide mutual aid and assistance with regard to technical, legal and other problems, 5. Establish and maintain an anonymous electronic postage system acceptable by all EMFG members. ANONYMOUS ELECTRONIC POSTAGE SYSTEM POSTAGE RATES--The first questions the EMFG will have to decide concern how much the members wished to charge for their services. Such questions would include: Should each forwarding hop cost the same, or should first and/or last hops receive a premium? Should message lengths be limited? Should longer messages cost more than short ones? Should each kilobyte cost the same, or should each successive kilobytes cost less--or more? Will the EMFG support any free forwarding? What net postage-per-service should EMFG member receive? POSTAGE "STAMP" NAME--The basic unit of postage should be given a "brand name." Using a name instead of an amount, permits bulk discounts and allows price adjustments as circumstances warrant. I favor, "Spooner Electronic Postage Unit" or "Spoon-E" for short (pronounced, "spoonie"). Thus, no matter what a Spoon-E costs, it would always take one Spoon-E to go through one forwarder or whatever. SPOON-E STRUCTURE--Spoon-Es are random 12-digit numbers generated by the clients. POSTAGE ISSUER--The EMFG will need someone to issue Spoon-Es. The EMFG could elect any of the following options: Rotate the uncompensated job among its members, Have member bid for the job in exchange for fixed fee or a percentage cut of each Spoon-E issued, Hire a third-party to issue Spoon-Es in exchange for a fixed fee or a cut. PAYMENT AND ISSUANCE MECHANISM--There are various levels of anonymity available to clients. The choice will depend upon the client's degree of paranoia. They all, however, are processed following these steps: 1. Clients randomly generate a series of 12-digit numbers. 2. These random numbers, plus an extra random 12-digit ID number, are encrypted using the Issuer's public key. 3. This encrypted message and payment are sent to the Issuer. 4. After payment has been accepted, the Issuer puts the clients' random numbers into an "Outstanding Spoon-E" database, and lists the corresponding ID numbers on a "Just Issued Spoon-Es" bulletin board. 5. Clients may access the bulletin board to check when their Spoon-Es have been validated for use. The level of anonymity is determined by the clients' method of payment and transmission. Payment via money order is the most anonymous; personal check, the least. (Cash is even more anonymous, but with its own obvious risk.) The least anonymous method of transmitting the client's 12-digit numbers is via direct e-mail. The most anonymous is via an s-mailed floppy. E-mail through a forwarder is somewhere in between. USE OF POSTAGE--The following steps would be performed in order to forward messages through a series of EMFG sites: 1. Clients consult the Issuer bulletin board to verify that their Spoon-Es are valid. 2. Clients write their messages and include the appropriate number of Spoon-Es within each nested and encrypted "envelope" for each forwarding hop they intend to use. 3. Upon receipt, each forwarder strips out the Spoon-Es for that hop. The message is added to a mix file of other messages until a threshold number is reached. 4. When the threshold is reached, the forwarder contacts the Issuer and verifies the validity of the Spoon-Es. Valid Spoon-Es are removed from the "Outstanding Spoon-E" database and the corresponding messages are forwarded out of mix file in random order. The forwarder's account is credited with the appropriate payment. Messages with invalid or missing Spoon-Es go to the bit or into the free service channel if there is one. 5. Step "4" is repeated through each forwarder until the message is delivered to its ultimate destination. The various mix files help defeat traffic analysis and permit the Spoon-Es to be verified before the forwarding service is performed. CONCLUSIONS The existence of a for-profit (or at least self-funding), privacy enhanced, electronic mail forwarding system does not need to await the development of on-line digital money schemes. It can be deployed today, using readily available, low-tech methods. Such a system benefits from economies of scale, and thus argues in favor of the creation of a group of mail forwarders such as the EMFG. Sandy Sandfort 20 November 1994 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

1 0

remailer security, sendmail
by David A. Wagner 17 Dec '03

17 Dec '03

I just read an interesting post on alt.hackers. Apparently you can figure out who's sending mail to who by repeatedly running the command /usr/lib/sendmail -bp. I just tested this out and it *seems* to work, as does running /usr/ucb/mailq repeatedly. How's that for an obscure feature? Does anyone run a remailer on a multi-user machine where sendmail is used? Is this sendmail feature a problem? If so, how would one fix it? (write a wrapper for sendmail? but that requires root access *sigh*) Am I missing something? ------------------------------------------------------------------------------- David Wagner dawagner(a)princeton.edu

2 1

1st Draft Mixmaster chaining instructions
by lcottrell＠popmail.ucsd.edu 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- Here is the first draft of the instructions for using Mixmaster to build remailer messages. I am posting it to give a flavor of what the program does, and to request comments, both on the features and on the clarity of the help file itself. Instructions for using Mixmaster to create type 2 remailer messages. I assume that you have either compiled Mixmaster, or that you have acquired a precompiled copy. While you do not need PGP to use Mixmaster, it is useful for key management, and is required if you desire security of the content of the message you are sending (which will be visible to the last remailer). Theory and purpose of remailers: The purpose of anonymous remailers (hereafter simply remailers), is to provide protection against traffic analysis. Traffic analysis is the study of who you are communicating with, when, and how often. This reveals more than you might expect about your activities. It will indicate who your friends and colleagues are (and they can be told apart by looking at the times you contact them). What your interests are, from which catalog companies you contact, and which ftp and WWW sites you visit. Traffic analysis can even reveal business secrets, e.g. your frequent contact with a rival could give hints of an impending merger. Remailers protect your email from traffic analysis. The original remailers did this by removing all headers, except the subject line, from any message you sent to them and then forwarding them a destination of your choice. The recipient of such a message would not know who had sent it. The addition of encryption to this scheme gave significant protection from attackers who simply look at passing messages for to and from fields. Passing a message through several remailers in a row is much better, but still vulnerable to an attacker who can watch messages go into and out of each remailer. Two more elements are required: messages must be reordered within the remailer before being forwarded (this is being done by a few of the old style remailers), and all messages must be indistinguishable. This last is the primary improvement with the type 2 remailer, Mixmaster. Using type 2 remailers: The trend towards ever more complicated remailer message formats has been clear for some time. Several programs have been written to automatically build messages which will be remailed by several remailers. This process is called chaining. With type 2 remailers it is no longer possible to create these messages by hand. Mixmaster takes a message you wish to send, a list of remailers to chain it through, and a final destination, and builds the packet which the remailers will use. For simplicity I will first describe the interactive use of Mixmaster, then I will discuss how it can be controlled through command line arguments. Interactive use of Mixmaster: If you run Mixmaster with no arguments, you will be prompted for all the required information. First you will be asked to specify the final destination of the message. This is the full email address where you want your message delivered. Remember that the message is being sent by the last remailer in the chain, so you must specify the full internet address (e.g. name(a)machine.place.com) you may not use local mail aliases. You may enter multiple recipients on separate lines. Hit return on a blank line to stop entering destinations. You must have at least one. Next you will be asked to enter any headers you want to have inserted before the message. These are those lines at the beginning of email messages, like From: fred(a)bedrock.univ.edu, or Subject: Party invitation. If you want your message to have a subject when it is delivered, you must enter a line Subject: your subject here. Note that Subject must be capitalized, with the : and space as shown. A subject header can be added by using the -s command line argument. When you are done entering headers, hit return (it is OK to have zero headers). You will now be presented with a list of remailers through which you can chain your messages. The order in which you choose them is the order in which they will be traversed by your message. You may choose up to 20 of them, but remember that the reliability and speed of the chain diminish as the number of remailers in the chain increases. Four is a reasonable number of remailers to use. It is fine to use a given remailer more than once in your chain. Press return on a blank line to stop entering remailers. Finally you will be asked what file you want to send. This must be an ASCII file. You may either enter the name of an existing file, or you may choose to enter the message directly by typing "stdin" as the file name. This is intended for use by scripts. There are no editing capabilities when using stdin. Enter the end of file character (EOF is ^D) when you are done entering the file. Mixmaster will now build the type 2 remailer packet, and send it to the first remailer in the chain. Command line arguments to Mixmaster: Mixmaster [-c] [in.filename] [-f] [-s "subject"] [-o "outfile"] [-to a(a)b.com] [-l 3 2 6 ...] -c this indicates that chaining rather than remailer functions are desired. It is a NOP since chaining is the default operation. "filename" if a filename is given, then this will be used as the input file. As in the interactive mode, you may choose "stdin". No filename will be prompted for. -f filter mode. All prompts suppressed, but input still accepted as described in the interactive section. The remailer list must be specified on the command line. -s "subject" Adds a subject line to the message. The user should NOT include Subject: in this string. Mixmaster will not prompt for other headers if -s is used. -o "outfile" Specify an output file rather than sending the message to the first remailer automatically. If outfile is "stdout", then the remailer packet will be printed to stdout. -to foo(a)bar.org specifies the final destination of the message. Only one destination can be specified. Mixmaster will not prompt for other destinations if -to is used. -l 4 3 5 ... Specifies the list of remailers to chain through. This must be the last argument on the command line. A maximum of 20 remailers may be specified. Mixmaster will not prompt for other remailers if -l is used. - -------------------------------------------------- Lance Cottrell who does not speak for CASS/UCSD loki(a)nately.ucsd.edu PGP 2.6 key available by finger or server. Encrypted mail welcome. Home page http://nately.ucsd.edu/~loki/ Home of "chain" the remailer chaining script. For anon remailer info, mail remailer(a)nately.ucsd.edu Subject: remailer-help "Love is a snowmobile racing across the tundra. Suddenly it flips over, pinning you underneath. At night the ice weasels come." --Nietzsche -----BEGIN PGP SIGNATURE----- Version: 2.6 iQCVAwUBLs/ymFVkk3dax7hlAQFKqgP9Enq5xOZm2Dm1WudNeRjssV/VeJ7YLr0V 2n5ZaRnMaPqHe5efeMY3N7Ry1YoqGaQdYfD7Ar9koDUFPA0Lizh9QtDSLdeG8IVv RWcz7CxWjtt02yc1/PLY3TO9b3VRb0zSFzcwu0QBI17ZVK+rF6cT/SEuZFAjgW9D CJ5rWJH25Vk= =i4cN -----END PGP SIGNATURE-----

2 1