December 2003 - cypherpunks-legacy

Does Estonian RSA chip violate patents?
by rishab＠dxm.ernet.in 17 Dec '03

17 Dec '03

Jyri Poldre <jp(a)jep.pld.ttu.ee>: > Recently i became involved in project of designing semi-custom VLSI device > for endecryption. The device uses variable length RSA for key exchange and > IDEA for data encryption. For pipelinig IDEA block we have to use 6 > multipliers 16 bit ant that leaves us with 96 bit adder for RSA calculations. > ( The chip should be reasonably cheap ). Otherwise the RSA speed would not As this is in Estonia, I don't suppose you're bothered about the patents? As far as I know, RSA/PKP patents are for _algorithms_, not respected outside the US, though patents for RSA/PKP _hardware_ would be respected worldwide. I'm not sure how algorithm patents can be applied to hardware -- you may or may not be able to sell this chip in the US _without_ violating patents. (Though you can freely sell RSA hardware or software outside the US.) You may even be able to apply for a European patent for the hardware, which would then be respected everywhere, except in the US where it may be superceded by the algorithm patents. -------------------------------------------------------------------------- Rishab Aiyer Ghosh rishab(a)dxm.ernet.in Voicemail +91 11 3760335; Vox/Fax/Data 6853410 H-34C Saket New Delhi 110017 INDIA The National Fairness to Game Animals Association says: Support your right to arm bears! --------------------------------------------------------------------------

3 2

encrypted IP
by Jim Hart 17 Dec '03

17 Dec '03

Does anybody have an update on the crypto IP efforts? I've heard there are several commercial products, including weakened U.S. DES versions from Semaphore Technologies, Motorola, Hughes, and UUNET technologies. Also, some higher quality foreign versions. How many of these products interoperate across vendors? Are there any public domain versions available or in the works? Any emerging standards, so that if I wrote my own system it could interoperate with other crypto IP based clients and servers? thanks, Jim Hart hart(a)chaos.bsu.edu

2 1

Cypherpunks' Electronic Book
by Gary Jeffers 17 Dec '03

17 Dec '03

Please see my current post of the truncated subject title: The Cypherpunks' Electronic Bo Yours Truly, Gary Jeffers

1 0

Re: Does Estonian RSA chip violate patents?
by smb＠research.att.com 17 Dec '03

17 Dec '03

As this is in Estonia, I don't suppose you're bothered about the patents? As far as I know, RSA/PKP patents are for _algorithms_, not respected outside the US, though patents for RSA/PKP _hardware_ would be respected world wide. I'm not sure how algorithm patents can be applied to hardware -- you may or may not be able to sell this chip in the US _without_ violating patents. (Though you can freely sell RSA hardware or software outside the US.) You may even be able to apply for a European patent for the hardware, which would then be respected everywhere, except in the US where it may be superceded by the algorithm patents. There's a lot of confusion about what the RSA patent covers, and what's prohibited by it. Rivest, Shamir, and Adleman did not patent an algorithm. Rather, they patented a cryptographic communication system based on certain equations. That means that it doesn't matter if you build it using software or hardware -- if it's still a system using the mechanisms described by their patent, it would infringe the patent in the U.S. Both within and outside the U.S., RSA hardware is patentable to the extent that the circuitry used is new, useful, and non-obvious. But what you're patenting is a circuit to do RSA, not RSA itself, of course. (The circuit might actually be more general, i.e., a modular exponentiation chip or some such -- in which case you'd be well advised to patent the more general concept rather just its utility for RSA.) That doesn't mean you could use the circuit to do RSA in the U.S. without a license from PKP. A patent is *not* the right to do something; rather, it is the right to prevent others from doing it. But if the circuit did not do only RSA, there's no reason why you couldn't sell it within the U.S. without worrying about the RSA patent. Finally, many folks have claimed that non-U.S. law does not permit ``algorithm'' patents. That may very well be. However -- there have been a lot of patents like that that have been issued within Europe; IDEA and Schnorr's signature algorithm come to mind. Whether these have been issued due to some quirks of the Patent Co-operation Treaty, or whether they could be issued without that, or whether they'll stand up in a European court, I couldn't say -- but the patents *are* being issued. --Steve Bellovin

1 0

re: digital clearinghouse
by brookfld＠netcom.com 17 Dec '03

17 Dec '03

We are able to use ACH ourselves. Yes, a customer can pre-authorize us to take amounts out of their checking account using ACH. The amounts do not have to be periodic, they can be any time, any amount. Our bank, with whom we are setting up ACH, determines whether or not we are using adequate security and authorization procedures, and holds us responsible if we're not. BROOKFIELD ECONOMICS INSTITUTE (U.S.A.) Limited ----------------------------------------------------------- Do you want to subscribe to our newsletter? Send email to brookfld(a)netcom.com, with the words SUBSCRIBE BBA your_first_name your_last_name as the subject of the message. Do you have a business question? Send it to brookfld(a)netcom.com. Questions which Brookfield determines are of common interest will be answered in the newsletter. Submissions become property of Brookfield Econcomics Institute. Copyright (c) 1994 Brookfield Economics Institute (U.S.A.) Limited. Rights are granted for use or duplication of this information by subscribers and individuals, but all commercial rights and rights of resale are reserved. Other use or duplication is prohibited. Brookfield is not engaged in rendering professional advice. In business and legal matters the advice of an attorney or other competent professional should be sought.

1 0

IMP (was Re: ecash-info (fwd))
by rah＠shipwright.com 17 Dec '03

17 Dec '03

>Forwarded message: >> From info(a)DigiCash.nl Mon May 30 05:44:18 1994 [snip. . .] >> http://digicash.support.nl [snip. . .] This, like CommerceNet(tm), seems to be pretty much under construction. The store windows look nice, however... >> >>... >> David Chaum On another point, I still think I'm subscribed to imp-interest, the internet mercantile protocol list, though I haven't seen anything much come out of there lately. It got Detweiler-infested and flamed over pretty badly before it went moribund, but I think imp-interest died primarily because implicit in it was a sort of top-down-plan idea that was incongruous with the do-it-first ethic of the internet. Cypherpunks write code, or Chaum does, anyway ;-). At the risk of violating that canon, ( I couldn't code my way out of a paper bag, even though I've designed an application or two) I'd like to start a thread here. Could we talk about IMP here? Here's what I think: 1.) Chaum's e-cash coupled with WWW/Mosaic is a de facto internet mercantile protocol. 2.) It seems to me that that e-cash, contrary to the status quo's thinking, is *critical* to internet commerce. An anonymous cash market is most unrestricted and efficient market there is, because privacy/security (more than trust, I think) is the capstone of any serious transaction mechanism. The imp-interest people seemed to be afraid of e-cash because the Chaum-patent hairball reminded them too much of the RSA/PGP fight, and probably because they didn't want to be associated with any wild-eyed crypto-anarchists(tm). (As a dyed-in-the-wool yellow-dog congenital up-by-your-bootstraps crypto-fascist <gasp> republican, I haven't the slightest idea what they're talking about. . .) 3.) Since a big pile of the discussion on this group lately has been about our collective concerns about an RSA-approved version of PGP, I think there is a real parallel here in e-cash. Not that some enterprising cypherpunk should immediately code up "e-cash for the masses"; that would be way cool but probably not within the second-mortgages of the people here. However, some effort should be made to get Chaum et. al. to see to logic of distributing *both* the "cash-register" and the "wallet" of this e-cash system to anyone who wants it. It seems that, like Mr. Bill (Gates), his real market is the people who make e-cash ("banks", "currency exchanges", "mints"), not the people who use it. Just a second. My flame-suit is around here somewhere... OK. Flame on. 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

3 3

PRZ Endorses PGP 2.6
by edgar＠spectrx.sbay.org 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- I was a little surprised to receive the following as a response from a "vacation" program apparently prepared by PRZ to answer his e-mail during a temporary absence: In case you haven't heard, MIT is soon releasing PGP version 2.6, available from an FTP site at MIT, for US noncommercial users only. It is a nice version of PGP, with all the strength and integrity of PGP 2.3a, with some bug fixes and improvements. -Philip Zimmermann I suppose this means he thinks (knows?) that problems inter-operating with overseas & commercial (Viacrypt) users will be worked out. -----BEGIN PGP SIGNATURE----- Version: 2.3a iQCVAgUBLechXt4nNf3ah8DHAQHDCQP/YejwsDpt/Mtb9KvKKY4m7xlC7nudFFO3 s6Q8v9ExknOsnpQ9Xp+vEeosFVtYkceqI3Saa1uhErwF3HBR4xCczGEXGE9jk0PD 1OHoe5lbzjg6dsjw6wj89GGSLM/oEaJEj3+3kBXq2UJPunQHmXryx5KV4lW8RGtQ NW8ydMIwaZA= =GrzX -----END PGP SIGNATURE----- -- edgar(a)spectrx.sbay.org (Edgar W. Swank) SPECTROX SYSTEMS +1.408.252.1005 Cupertino, Ca

2 1

No Subject
by Gary Jeffers 17 Dec '03

17 Dec '03

who cypherpunks index cypherpunks

2 1

Re: (fwd) Re: NSA Helped Yeltsin Foil 1991 Coup
by peb＠netcom.com 17 Dec '03

17 Dec '03

The author's source did not reveal the nature of the intercept...it could have been through a direct bug. However, the article does give the impression that the coup leaders believed they were secure, so apparently they took some steps toward privacy. Paul E. Baclace peb(a)netcom.com

1 0

The Cypherpunks' Electronic Book
by Gary Jeffers 17 Dec '03

17 Dec '03

THE CYPHERPUNKS' ELECTRONIC BOOK (CEB) C'punks write in sand - the cure sssss aaa nnn n nn n n ddd d sss aaa aaa nnn nn nnn n n ddd d sss aaa aaa nnn nnn nnnn dddd sss aaaaaaaaaaa nnn nnn nnn n n dddd sss aaa aaa nnn nnn nnn n dddd sss aaa aaa nnn nn nn nn ddd dddd d d sss aaa aaa nnn nnn nn dd dddd aaa aaa nnn nnnn ddd dddd dd THE CURE Ok, its not quite as bad as that but its bad! As we all know the Cypherpunks' list is not archived, indexed, or hard back bound. Information that cannot be found is useless. Tim May has recently volunteered to make a list of privacy software. Congratulations for that! That is certainly a step in the right direction. I don't wish to be overly critical of the Cypherpunks' list as it is surely the best electronic privacy list & better than any corresponding newsgroup on the Internet. I am merely pointing out a solution to its greatest deficiencies & how to greatly improve it. I have an idea (CEB) that would get us a very workable knowledge base fast. First, it is not that practical to archive the list. Its too big, no one wants to do it, too much of it is junk, & files that are valuable today are time dependent & become tomorrow's junk. The only good reasons for archiving the whole list are for history & entertainment. My idea for a good Cypherpunk knowledge base is a "Cypherpunks' Electronic Book" ("CEB") that would have named chapters that are indexed, refereed, & continuously updated. Contributors would have their items signed. These chapters would consist of: 1. List of privacy software & locations. 2. State of the Art. 3. Current significant problems. 4. Capabilities & Dreams (things we can do, things we want to be able to do). 5. Reputations of people by name, their products & achievements. 6. PGP's state of affairs. All chapters would be refereed & all chapters of large size would be indexed. There would be a collective index for the whole CEB. LIST OF PRIVACY SOFTWARE & LOCATIONS In the software listing, in addition to listing where software can be found, we could also have reviews by Cypherpunks so we could know each package's quality. STATE OF THE ART In the State of the Art chapter, we would list only the best software of its kind. It would of course include reviews of each piece & its fitness for its job. Each piece would be indexed by name, category, & author. CURRENT SIGNIFICANT PROBLEMS In the Current significant problem's chapter, we would have a list of the particular current problems as well as general problems to solve & tactics for carrying out the Cypherpunks' mission. We could list who was working on these problems & how far they had gotten. We could also state a difficulty level to each problem. Many problems would be only partially solved or solved in a not entirely satisfactory way. For those hoping to make contributions to electronic privacy, this chapter would provide a list of targets. CAPABILITIES & DREAMS In the Capabilities & Dreams chapter, we would have a compilation of things that we are currently able to do as well as things that we hope to be able to do in the future. A good example is how far we are with anonymous digital money. Is anybody actually using it? Do we have useable money systems available but unused? Do we have users beating down our doors for a working digital money system not yet developed? Do we have anonymous digital barter & what is being bartered? REPUTATIONS OF PEOPLE BY NAME, THEIR PRODUCTS & ACHIEVEMENTS The reputations chapter is a much needed who's who of the electronic privacy world. We would know who had made heavy contributions to electronic privacy & who the proven capable are. Much needed recognition would be provided to the productive. This chapter would serve as a reputations grade lister for the more outstanding people. I would also suggest that their public keys, if any, be included. This chapter would provide some much needed justice. PGP'S STATE OF AFFAIRS PGP in its various versions is a topic that rates its own chapter in CEB. What versions are compatible? What versions are good? What versions are endorsed by Phil Zimmerman? For what versions do we have source code? What versions are legal & where? The PGP versions would require some thoughtful indexing. Then, there are the patches to PGP versions to make them compatible with other versions & for bug fixes & upgrades. THE CEB WOULD BE WRITTEN QUICKLY & WOULD GROW This Cypherpunks' Electronic Book could be written very quickly. It would be written in parallel with many Cypherpunks writing in different sections in different chapters. We would not have to start out big. The first edition could be a high quality booklet. New editions could be published weekly or even daily due to the fact that its medium is electronic. The booklet would have immediate value with its first edition as permanent continuously updated sources of electronic privacy knowledge are badly needed. I would suggest that Tim May could be one of the first writers with his software list. In order to get something published early, Tim could list only the best of the software in the first edition. It would be good if Tim could have a critique to go with each software piece. CEB - CURRENT, CONTINUOUSLY UPDATED, & REFEREED As far as I know, the Cypherpunks' Electronic Book would be the only current, continuously updated, refereed electronic privacy knowledge base on the Internet. As various Cypherpunk writers contributed to it it would grow in value. It would become THE electronic communications privacy knowledge base. MAJORDOMO IS THE TOOL We could use Majordomo as the book's distributor. With some small modifications, Majordomo could do a lot for us. I would suggest that Majordomo be modified so that it advertised CEB by name with each query. The CEB would be available from Majordomo as one of its files with the full instruction: get cypherpunks CEB . When the CEB became very large individual chapters could be offered. Each chapter would have its own index. There would be a collective index for the whole CEB. MAJORDOMO DISTRIBUTES AUTOMATICALLY Majordomo could also be programmed to send out a Majordomo file every week that explained how to use Majordomo & what it had to offer. This would keep newbies from asking a lot of questions. Our Majordomo would also develop a reputation as the distributor of the Internet's best knowledge base for crypt software locations, evaluations & electronic privacy concerns. Later, Majordomo could be programmed to automatically send out daily or weekly updated versions of the Cypherpunks' Electronic Book to related interest groups such as Sci.Crypt & Politics.Crypt. Note: From this point on in the text, I will use the term CEB to denote Cypherpunks' Electronic Book. CEB WOULD BE *THE* REFERENCE KNOWLEDGE BASE CEB would be THE reference for the statuses for all the Cypherpunks' concerns. Researchers would know immediately what the status was of their area of work. People who wanted to use electronic privacy products would know what the best products were, where to find them, & what their capabilities were. C'punks wanting to make a contribution to the tech- nology would find where the significant problems were & what needed to be done. People wanting to find out the reputation & products of a C'punk could do so quickly. The location of everything of current value to electronic privacy could quickly be found in CEB. CEB IS A BADLY NEEDED COUNTERPART TO THE CYPHERPUNKS' LIST CEB is a badly needed counterpart to the Cypherpunks' list. Our list is disorderly, huge, & things get lost in it. For instance, recent- ly, there was a post about PGS (pretty good PGP shell). It was stated that PGS was a very good product. But, if we are distracted by interest- ing threads & monthes pass, we might have a terrible time finding PGS. With a well indexed CEB, we would immediately find PGS. Another example is WNSTORM. This is a greatly needed piece of software. After some months pass, we may wonder "is WNSTORM any good?", "who wrote it?", "where can I find it?", "what was its name?", "has it solved the patter- ened lower order bits problem?", "has it been obsoleted by another steganography program?".With a good CEB, we could immediately know the answers to these questions. Another example is the Windows implemen- tation of PGP. I only found out about it because I made a post suggest- ing that a good Windows implementation of PGP could greatly popularize encryption. Julietta, then sent another post saying that that software had not been done well from a user friendly point of view. Is Julietta right? Is it user unfriendly or not? With a refereed CEB we would know. With a comprehensive CEB, I would have known of its existance. CEB WOULD BE "FINISHED" & PROFESSIONAL The CEB would constitute a "finished" product. It would look pro- fessional, refereeing would guarantee its quality, & it would have a feeling of completeness magnitudes beyond the list. It would also give experienced & skilled Cypherpunks their own medium without being swamp- ed out by the work of the less capable - a joy for the Elite & Elitists! CEB CAN START NOW All that it takes to start CEB is some cooperation from Eric Hughes in making some changes to Majordomo & in appointing referees. We've got the material to start typing immediately. CEB can start out as a high quality booklet. It will grow as C'punks add to it & we might very well wind up selling yearly editions of it to Loompanics & other quality pubs. Possibly, later, CEB could finance the Cypherpunks' mailing list. Many capable C'punks are tired of having their best work buried & would gladly contribute to CEB. Anybody got any ideas? Yours Truly, Gary Jeffers Cypherpunk PUSH EM BACK! PUSH EM BACK! WWWAAAYYY BBBAAACCCKK! BBBEEEAAATTTT STATE!

3 2

Estonian RSA chip
by jp＠jep.pld.ttu.ee 17 Dec '03

17 Dec '03

I think that i was a bit rushing and did mainly focus on my own problem, that was this division. I will enlighten this more clearly, so that you do not think about me being 'FSP hard/soft/whateverware stealer'. Yes, this chip is basically 'FAST integer calculator' with different levels of microprogamming. I think that user-accessible levels include A*B mod Z , where A,B,Z are 510- local_register_ram_limit nr of bits. The only main difference about commercially available circuits would be relative cheapness- meaning that modular exponents are optimized in algorithm level, not via HUGE adder, and main force lies in 16 BIT calculations , needed for fast encryption algorithms. (EStimated speed using IDEA will be not less than 2 Mbit/sec, RSA key exch will be less than 0.4 sec. ), But still it will not contain IDEA or RSA to start with. ( though using primitives like A*B mod Z this is 10~20 lines of code. ) Now i do explain in a few words, why i do not like the idea of user tinkering with that. Every known cryptosystem using one-way functions contains trapdoor. While there will be no reason in users snooping around with things that run IDEA or DES just because you might lose the ability to have one-to-one mapping of data, there is nothing wrong in just changing a bit of RSA. Everything would possibly 'LOOK' the same with one guy opening trap^2 door occasionally. That would zero the whole meaning of the chip, what would otherwise work like that: (just for example i am using RSA and IDEA. ) CHIP would look like it ------------------------- RSA, D1, D2, E1, E2 I IDEA K1, K2 I <---> RAM RND generator I <---> interface to communication systems I ------------------------- IN RAM we will keep PUBLIC components and id-s of those we want to keep secure chat with. FOR RAM we will have D2,E2 the chips ID will be pair E1,D1 they will be generated inside chip and !!! Both of them not known to users!!!. when you want to initiate communication you bind 2 chips together and they will exchange public components through trusted channel - meaning you should avoid the write access to that channel- nothing is wrong with read access. It can be achieved rather easyly with 2 chip modules. ( 3 special lines and single sided PCB board- you 'see' the lines and it would rather hard to write into them ) after initialisation chips will store their partners Public components and real names in RAM using D2. Now the rest is obvious. After chip A receives talk request from Chip B it looks up public components in RAM and if it matches then uses these do decrypt and get IDEA key from X. If everything is Ok you will get data and the name of CHIP B. Now i cannot guarantee what happens between chip and terminal, but that is not my problem. For this chip-to-chip construct i could give money-back guarantee on some reasonable sums ( dependidng on the length of key change moduli and while-it-is-safe-to use IDEA or DES or whatever for one session.) Now let us look at it from the different viewpoint. Just imagine the possibility of firmware being left to user. I am not even thinking about stupid things like i-will-keep-the-code-secret. This simply won't work. Imagine you being able to reprogam this chip. I know that this would be hard, but it would be NPboring instead of NP-difficult task of factorizing large primes. For me as a constructor it makes no differnce to let or to let not user cahnge microcode technically, but i am still fond of my life and would tell the codes for firmware to publicity at once. Therefore my idea has been from the start open design while in devolopment and no user interaction when in production. ARGUE with me. - that is the main idea I am anyhow using VHDL firmware devolopment and have my own assembly language for this chip. So far I have decided no interaction in algorithms for user, due to licences it will possibly turn out the other way. Jyri Poldre from Tallinn Technical University PHONE/fax 372-6-392062 If it was not for the MIPS being so good at building CHIPS the yards would still be open for the lines remix, >From Pfloyd, The final Cut

1 0

Magic Money 1.1/AutoClient
by catalyst-remailer＠netcom.com 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- Magic Money V1.1 with AutoClient and MultiServer Capability Uploaded to csn.org, should be available soon. Read README.MPJ in /mpj This is the automatic client I described a couple of weeks ago. This is a new version of Magic Money. It is compatible with V1.0 in both directions. The major improvements are: * Automatic Client allows software-automated services to accept and pay out Magic Money. * Coin files contain the keyid of the server that created the coins. This allows the Automatic Client to accept money from multiple servers. * New fifo.c fixes a memory-freeing bug in fifo_destroy. This fix was previously posted on csn.org as pgptlupd.zip The keyid is appended to the end of the coin file with a new packet type number preceding it. These coin files will be accepted by the V1.0 client. V1.0 coin files will also be accepted by the V1.1 clients. See the README10.DOC file for more general instructions about how to use Magic Money. This file concentrates on the changes. The Automatic Client performs the same functions as the manual client, except that it has no user interface. It is designed to be controlled by software (PERL scripts or C programs). The program is controlled by command-line arguments and information piped into stdin. All output is written to files or sent to stdout. Compiling AC.C with MM.C and the appropriate PGPTools files produces the Automatic Client. If you are using a PC, it is worthwhile to get the 8086.ASM file from PGP2.3a and use it. Define MSDOS, SMALL_MEM, DYN_ALLOC, and UPTON for the MS/DOS version with 8086.ASM. These defines work for both the normal and automatic clients. Automatic Client Commands The automatic client accepts one option, and zero, one, or two filenames. If run with no options or filenames, it will print a help screen. ac -[option] [inputfile] [outputfile] - -k display bank's keyid and client's keyid This prints the keyid of the bank on the first line, and the keyid of the client on the second line, as 8-byte hex strings. - -k [inputfile] display keyid of bank which made this coins.dat file, or the keyid needed to decrypt an ascii-armored pgp message. If the file is a coins.dat-type file produced by a client, this will produce the keyid of the bank that created it. If it is a PGP message, such as a reply from a server, it will produce the keyid the message is encrypted with. In either case, it returns an 8-byte hex string. If the file is from a 1.0 client, there is no keyid so you will get a NO_DATA error. There is a 1/256 chance that the byte at offset 9 from the end of file will match the identifier byte. In this case, you may get a no-good server id. If you get a server id but do not recognize it, assume this has happened. - -d list coin denominations Prints the available denominations of coins from the elist file, one denomination per line. These are all the possible denominations, and their presence here does not mean you have any coins of that denomination. - -i [outputfile] initialize client (key length, key name from stdin) This initializes the client, producing the initialization message (which must be sent to the server) in the specified file. The bank.asc file must be present before running this. It creates a key to communicate with the server. The key length in bits, and the name for the key, are read from stdin. They should be on separate lines. - -l list all coins in allcoins.dat Lists all available coins as a stream of numbers, one coin per line. - -l [inputfile] print total value of a coins.dat (client output) file. Checks signatures and rejects if signature bad Prints one number, the total value of the coins.dat file specified. If any signatures are bad, or coins have unknown exponents, the program terminates with a BADSIG or BADEXP error. - -p [inputfile,outputfile] process a coins.dat file for exchange with the server. Reads from stdin a list of coin denominations to create, terminated by 0. Writes to stdout a 128-bit transaction identifier. Before running this, you must have used the -l above and decided what denominations to create. Then run this to process the coins and prepare a message for the server. Feed the denominations you want into stdin, one number per line, terminated by a zero. There is no checking here. If you specify less value than you are turning in, you will lose value. If you specify more, the server will throw out the transaction and you will lose all the coins you are depositing. This function writes out one value to stdout: a 128-bit hex identifier. This is an xor of the coinids of all of the new protocoins created. This allows your script to identify this transaction when it comes back from the server. - -r [outputfile] Reinitialize (generate init packet) This generates a new client initialization packet. If your system is inactive for a while, do this, send it in, and run -s on it. This will check for a coin expiration and update your elist if necessary. - -s [inputfile] Process a response from the server. Outputs the 128-bit transaction identifier, followed by total value, followed by any message from the server. This takes a reply from the server (ascii-armored) and processes it, adding new coins to your allcoins.dat file and removing the corresponding protocoins. The output is: on the first line, the same 128-bit identifier generated by -p when this transaction was prepared. On the second line, the total value added to your coin file (same as the value of the coins you created in the -p). Following that, any message from the server, if there is one. If -s is run on a response to a -i or -r initialization, it will return 00..00 for the identifier and 0 for the value, because no coins were processed. - -w [outputfile] Withdraws coins for payment. Accepts a list of coin values from stdin, terminated by a zero. Extracts coins from your allcoins.dat file and writes them to the output file. Send to stdin a list of values to create, followed by a zero to terminate. The output file can then be processed by another client. - -x Returns the total value of any old coins (in danger of expiration) Checks for old coins that are in danger of expiring. Outputs the total value of all old coins, or zero if there aren't any. - -x [outputfile] Exchanges old coins. Accepts a list of denominations and generates an identifier like -p This is like -p for old coins. Run -x above first, decide what denomin- ations you want to create, and run this. Feed in the denominations, term- inated by a zero, and send the output file to the server to exchange your old coins for new ones. If you have expired coins (you didn't exchange them in time) this will throw them out. Error codes (from MM.H) These are returned by exit(code) when the program ends. A 0 is good, anything else is bad. The only errors that are not included here are out-of-memory and missing rand.dat file. These will still print English messages, however, if the system is correctly set up, they should not happen. #define MMAC_OK 0 /* Normal exit */ #define MMACERROR_BADCOMMAND 1 /* Bad command */ #define MMACERROR_NOFILE 2 /* File not found or inaccessible */ #define MMACERROR_NODATA 3 /* Data such as a key not found */ #define MMACERROR_BADSIG 4 /* Coin/file has bad signature */ #define MMACERROR_BADEXP 5 /* Coin has unknown exponent */ #define MMACERROR_NOCOIN 6 /* Tried to use nonexistent coin */ #define MMACERROR_NOPROTO 7 /* No protocoin in file */ Using the Automatic Client Ok, that's great, but how do I use it? For an automatic service, you want to receive coins, process them, get the response back from the server, and then perform some service. You may optionally want to send some coins back to the person. So first, when a message comes in, you have to decrypt it or dearmor it or uudecode it, or whatever is necessary to get a binary coins.dat file. Then run -l [file] to check its value. If you get a value and not an error, figure out what denominations you want. -d will list all possible denominations. Now run -p [file] [output file] and send it your list of denominations. Record the transaction id output from the client, along with whatever information you need to keep about the service the customer wants. Mail the output file off to the server, and go on to the next problem. When the message comes back from the server (-k [file] and compare with -k to verify it is encrypted for your client) run -s [file] on it to deposit the coins in your allcoins.dat file. The output from the client gives you the transaction id, value, and any message. Use the transaction id to look up the information you recorded earlier, and deliver the service to the customer. The value can be verified if you want, and the message should probably be saved in a file for later reading. You can check each new message against the last one and only save it if it has changed. Occasionally run a -x to see if you have any old coins. If so, figure out what denominations you want to trade them for, and run -x [file] to exchange them. You can probably do this part by hand, since coin expirations are pretty rare. To pay out money, do a -l to find the denominations to extract, then do a -w to withdraw them into a coins.dat file. Handling Multiple Servers You can run a service that accepts coins from multiple servers. To do this, you have to keep a separate client directory for each server. When a coin file comes in, run -k [file] to determine which server it is for. Using the server id as the directory name would make life much simpler. Then CD into that directory and process the coins from there. If you get coins from a 1.0 client (which has no server id), you will have to go into each directory in turn and try a -l [file] on the coins. You will get an error return on each one until you find the right directory. If messages are coming back from multiple servers, using -k [file] on the incoming message will tell you which client's key it is encrypted with. Running -k will tell you the key of that client (on the second line). - From this, you can determine which client should process that server's reply. This is probably easier than using the from line in the email. Ideas for Automated Magic Money Applications Currency Exchange - Accept one currency and return another, skimming off a profit. Find the correct exchange rates where the same amount of each currency is coming in and going out. Pay-For-Use System - Accept Magic Money to pay for remote access to a machine, use of a MUD, remailer, news posting service, etc. Gambling - Accept bets on sports, the stock market, horses, etc. This is the MGMNY11A release. That means it might have bugs. If you find any, please post them on Cypherpunks(a)toad.com or alt.security.pgp. These are also good places to announce your service, or to contact me. Pr0duct Cypher "One line of code is worth a thousand rants." -----BEGIN PGP SIGNATURE----- Version: 2.3a iQCVAgUBLerF1MGoFIWXVYodAQFtVAQAn7HOBDX4bg6MZv6uAgr3KhDfpTsAF1Te i8C9WjWGgPlqv6wJz+uACBo9dKnT5oP3u7foz3rB7GRp8UHHGBs2u8TjvTeedrQ4 wUit6Bb3LcmwRPjQ8MfLK3cam8EeNsy9Hn9hqw9fm7xs4jwgaqsZU8dslthSEdh4 lab6JYE0vWM= =7QpT -----END PGP SIGNATURE-----

1 0

100 consecutive composite numbers (fwd)
by Jim choate 17 Dec '03

17 Dec '03

Forwarded message:

1 0

Re: IMP (was Re: ecash-info (fwd))
by Hal 17 Dec '03

17 Dec '03

> From: rah(a)shipwright.com (Robert Hettinga) > >> http://digicash.support.nl > This, like CommerceNet(tm), seems to be pretty much under construction. > The store windows look nice, however... I agree with this, which is why I don't understand why you said: > 1.) Chaum's e-cash coupled with WWW/Mosaic is a de facto internet > mercantile protocol. You're jumping the gun here a little, aren't you? There is no evidence yet that Chaum's current proposals are going to catch on. The CommerceNet idea seemed to have more backing judging from the press releases. And it did not appear to support anonymous transactions. > 2.) It seems to me that that e-cash, contrary to the status quo's thinking, > is *critical* to internet commerce. An anonymous cash market is most > unrestricted and efficient market there is, because privacy/security (more > than trust, I think) is the capstone of any serious transaction mechanism. I don't follow this argument. You are suggesting that an anonymous cash market would be more efficient than one based on checks and credit cards? It would have lower transaction costs, so things would be available for lower prices? Why is this? The hypothetical discussions we've had here on "if I ran an anonymous bank" often talked about service charges. Your use of the term "capstone" is unclear in this context. Are you suggesting that retaining privacy is more important for most people than trusting a seller in most transactions? Most people would rather buy from FlyByNight Corp if they could stay anonymous than from Sears using their credit card? I don't think so. For some people, the kind who won't use checks today and get by with cash and money orders, this might be true. But I don't see it as being the rule. > The imp-interest people seemed to be afraid of e-cash because the > Chaum-patent hairball reminded them too much of the RSA/PGP fight, and > probably because they didn't want to be associated with any wild-eyed > crypto-anarchists(tm). (As a dyed-in-the-wool yellow-dog congenital > up-by-your-bootstraps crypto-fascist <gasp> republican, I haven't the > slightest idea what they're talking about. . .) It seemed to me that the IMP list discussions degenerated into flame wars between Detweiler and cypherpunks. Those in the middle, which included most subscribers, were shocked and disgusted by Detweiler's crude flaming and this made everyone uncomfortable about bringing up the topic of anon- ymity and cash. With Detweiler on the list it was impossible to have a serious discussion of the matter. > 3.) Since a big pile of the discussion on this group lately has been about > our collective concerns about an RSA-approved version of PGP, I think there > is a real parallel here in e-cash. Not that some enterprising cypherpunk > should immediately code up "e-cash for the masses"; that would be way cool > but probably not within the second-mortgages of the people here. However, > some effort should be made to get Chaum et. al. to see to logic of > distributing *both* the "cash-register" and the "wallet" of this e-cash > system to anyone who wants it. It seems that, like Mr. Bill (Gates), his > real market is the people who make e-cash ("banks", "currency exchanges", > "mints"), not the people who use it. Chaum is trying to make money off his ideas. In doing so, he is being guided by the invisible hand of the market to try to find those niches where his technologies can be most profitable. Maybe going after the bankers is the wrong idea, but it is understandably tempting to prefer trying to get millions of dollars from a few people than a few dollars from millions of people. It does sound, though, like he is trying to branch out now and spread his technology around. Perhaps he will follow the lead of RSA and make a "ChaumREF" free implementation of his cash technology. The Commerce- Net model had RSA supplying free client software while charging the vendors licensing fees, I believe. Chaum may be planning a similar approach. It would be nice to see more details about what Chaum has in mind. My WWW access is very weak. Could someone summarize what is available at the page listed above? Hal

5 8

Re: IMP (was Re: ecash-info (fwd))
by rah＠shipwright.com 17 Dec '03

17 Dec '03

Oh boy. Now I'm in for it... I *really* didn't mean to put the ball through the window, mister, I was just trying to play.... Tim May said, > >David Chaum's work is of course central to Cypherpunks... [Agree to all up to this point \|/] >IMP-interest folks had an especially naive view, for the most part >(based on posts I saw and things I heard from participants). I wished >them well, but it seemed unlikely that a group of such hobbyists could >build a real digicash system while avoiding Chaum's work! > >> implicit in it was a sort of top-down-plan idea that was incongruous with >> the do-it-first ethic of the internet. Cypherpunks write code, or Chaum >> does, anyway ;-). > >Even with the smiley, are you implying Cypherpunks don't actually >write code? [I think the ball goes through the window about here...] I *really* didn't mean that at all. I did not *even* mean to "cast asparagus" on your collective efforts. *Really*. What I meant is that Chaum seemed to be making the implicit claim that he had gone out and done something a whole lot of people around here seem to have been hoping for for a long time: an Internet Mercantile Protocol. *Not* a Kerberos-based Billing Server, *Not* anonymous credit cards, *Not* a coffee-klatch at a BOF session somewhere, but a real way for people to do cash transactions on the internet. I think of Chaum as the 900 lb gorilla in all of this. Chaum is really (because he owns the patents, after all) the only guy who could do something here. I am _happy_ that he and his folks have kicked the snowball down the hill. In my enthusiasm, I was applauding Chaum for doing something whose time has come; I was *not* saying anything about the efforts of the people on this list. If I gave that impression I *really* apologize. Now the other stuff... >> Could we talk about IMP here? > >Digital cash is discussed here often. And every one of the various >"digital money" schemes announced by folks has--I think--been forwared >here and discussed. In my view, Cypherpunks have talked a lot more >about Internet Mercantile Protocols than the IMP-interest list has >talked about crypto (an absolutely core technology, of course). Having read the roasted-over imp-archives on thumper at belcore, I agree. I was making the request in light of the fact that you folks have worked over this ground before. I was asking your indulgence more than anything else... > >> 1.) Chaum's e-cash coupled with WWW/Mosaic is a de facto internet >> mercantile protocol. > >Hardly. Maybe it will be in the future, but enough infrastructure >pieces are lacking that it can hardly be called a "de facto internet >mercantile protocol." [snip] > >(Cf. the soda archives for a "Glossary" and various articles on >Chaumian things.) [will do] This is the main point of my posting, I believe. It seems to me that more than that is being claimed by Chaum and Co. [snip] >Of course crypto and true digital cash is central....this is our whole >message, nearly. Violent agreement here... >You may be new to the list, but Magic Money/Tacky have been discussed >as recently as last week. And ftp sites have been listed. Also, within >the last week there were several discussions of making the schemes >more "usable by the masses." (Having said this, MM is _not_ an easily >usable, readily-convertible currency or even a payment xfer system for >real currency...again, see the many posts on this.) I agree. I just started learning about all this stuff in the last three months or so. But, I've been lurking here since. I have been paying attention. Honest. I've been trying to do my homework. I've pulled everything down out of Nexis/Lexis that I could find on Internet Commerce and Digital Cash, Chaum, Eric, the Cypherpunks group (not you in particular, I'm afraid ;-)). Hell, I've even read Schneier, though for the life of me I couldn't discuss 10% of the technical stuff and keep a straight face (for pretending like I knew what I was talking about, in other words). > >> Just a second. My flame-suit is around here somewhere... OK. Flame on. Putting this thing on has drawn more fire than it kept off of me. I better keep it off. > >I don't think of my comments as flamish, but the comments here seem to >bespeak no awareness of the heavy focus Cypherpunks has had on digital >cash for a long time. Here's where I wish eudora had a "say what I mean" feature... Again my apologies... >That we have not "deployed" digital cash is >related to many factors, including patents, lack of financial >incentive (Chaum's folks have spent perhaps 10-20 man-years and >several million dollars, and Chaum holds key patents...it is hard to >imagine any of us competing head on...and make no mistake about it: a >"Pretty Good Digital Cash" scheme would, on the whole, be a much >larger project than PGP was), etc. I suppose my point was that Chaum seems to be seeing what is happening out there, (CommerceNet) and has decided he can make things happen by opening up things a little bit. I applaud this. I was egging him on. I was *not* trying to get my tail-feathers fried. My analysis may be simplistic, but when Digicash Inc. says this: > >Payment from any personal computer to any other workstation, over >email or Internet, has been demonstrated for the first time, using >electronic cash technology. I figure that somebody acted. Somebody wrote code. Is it shipping? I have a product I'm dying to sell this way right now. Maybe I should wait a day before I post when I get excited about something... As it is, I feel like Garth and/or Wayne. "I'm not worthy!, I'm not worthy!" I really didn't want get into it with Tim May of all people... How many lawns do I have to mow to pay for the window, mister? ;-). ----------------- 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

3 2

Sun looking for applicants for secure networks
by Marianne.Mueller＠Eng.Sun.COM 17 Dec '03

17 Dec '03

Begging your pardon for this use of the mailing list, but, if you're looking for a job developing network security software, Sun's hiring. Please send resumes or inquiries to nick.johnson(a)sun.com. --Marianne Subject: Re: SPARCstorage array and striping Date: 23 May 1994 18:36:55 GMT Organization: Sun Microsystems Inc. Summary: Wanted: Network/UNIX Security Engineers Looking for candidates. Responsibilities: Working has part of the Corporate IR group these positions (2 currently open) are responsible for the internal security of Sun's Network. Individuals will develop and maintain security policies, perform audits on existing network and system implementations, develop tools for the performance of remote audits and intrusion detection, work with other internal Sun groups to identify secure methods to inter-connect business partners, evaluate new security products, drive encryption usage inside corporation, perform customer presentations, work with enginering groups to test new OS releases and influence product strategy. Individuals should have at least 3 IP networking and 5 years UNIX security work experience. Prefer individuals that have at least a BS in computer science or directly related field with some software development background. Interested parties should forward their resume to: angie.alfred(a)Sun.Com with a copy to nick.johnson(a)Sun.Com.

1 0

to The Atlantic
by peb＠netcom.com 17 Dec '03

17 Dec '03

Here is my final draft to the editor of The Atlantic in response to the June '94 article by James Fallows entitled "Open Secrets". ---------------------------------------------------- Editor The Atlantic 745 Boylston St. Boston, MA 02116 May 20, 1994 In James Fallows' article "Open Secrets" (June 1994), the Clipper chip and Digital Telephony bill are discussed with admirable clarity. The presentation of public key cryptography is the best I have seen for a lay audience. However, some incorrect implications from the article might be assumed unless several additional facts are pointed out. Government use of the Clipper chip is approved by the NSA for the transmission of non-secret information. The article gives the impression that Clipper is so strong that military and intelligence services would use it, but this is not so. Given this, concern is warranted about Clipper's actual degree of security or about possible secret back-doors. The 50,000 people who supported an Internet petition against Clipper were concerned about the classified nature of the algorithm. The Open Secrets article brushes this aside as an apparent distrust of bureaucracy. In actuality, cryptographers have always maintained that no cryptosystem can be trusted unless it is openly developed and tested. This is based on mathematical and programmatic aspects of cryptography that are ubiquitously used in mathematical proofs and software testing. In the absence of this open development, the only thing citizens can do is trust the NSA, an organization that is not directly accountable to citizens. However, the NSA has major incentives to support cryptosystems which are breakable only by their organization without using the escrow keys. A back door is difficult to recognize even in a non-secret algorithm, but in a secret algorithm it is essentially impossible to determine. (Historically, the NSA has backed encryption technology that it can break; the DES algorithm it approved for commercial usage is breakable by the NSA.) The FBI has never released statistics about how they are thwarted by encryption technology or by digital telephony. How can a citizen judge the need for Clipper and the Digital Telephony bill without such information? The Digital Telephony bill broadly defines telephone technology and even imposes exorbitant fines on private telephone systems that do not implement remote wiretapping capabilities. Since any multimedia computer today can be turned into a telephone by simply adding software, will this law have an unintended effect on individuals? The Digital Telephony bill will make wiretaps cheaper to implement because the consumer pays for the implementation. Since spying is limited by economics, this bill could increase the extent to which wiretapping is abused. And finally, it should be mentioned that the first NIST press release on the Clipper chip said that citizens do not have a right to unbreakable encryption. Thus, the administration started off with the goal of restricting encryption and only after opposition did they start saying Clipper was voluntary. Given their original intentions, which challenge the First Amendment, there is reason to be concerned.

1 0

PGP 2.6/Turbo C
by mike＠EGFABT.ORG 17 Dec '03

17 Dec '03

I'm running Turbo C++ 3.0 and get "Invalid configuration file" when trying to load pgp.prj to compile pgp 2.6. Anyone else try this type of setup to compile 2.6? I've been able to reproduce this result on multiple machines starting with the signed .zip file. Anyone that can offer any suggestions? thanks -Mike -- Mike Sherwood internet: mike(a)EGFABT.ORG uucp: ...!sgiblab!egfabt!mike

1 0

Seattle Times cpunks article, 5/27/94
by Matt Thomlinson 17 Dec '03

17 Dec '03

Paul finally polished this one up and put 'er in print. It talks about the NSA document, cypherpunks, and clipper. Pretty good, I thought. (c) 1994 Seattle Times, I'm sure.. ;) Is government chipping away at freedom, privacy on new information highway? --------------------------------------------------------------------------- -Another in a periodic series looking at the impact of technology on contemporary society- By Paul Andrews, Seattle Times staff reporter Long dormant, '60s-style civil disobedience may soon make its reappearance -- not at college campuses or draft inductions but on the information superhighway. The issue this time around: electronic privacy. An underground computer group, known as cypherpunks, is among a variety of groups fighting the Clinton administration's attempt to monitor electronic communications, saying it smacks of Big Brother and thought control. And they're intent on using the electronic equivalents of protest marches, sit-ins and card burnings to make their point. The dress rehearsal came last month when cypherpunks distributed the employee manual of the National Security Agency over the Internet in an attempt to embarrass the administration. The incident was generally viewed as a teenage prank. Although an intriguing glimpse into the psychology of one of the government's most secret bureaus, the manual is not a "Top Secret" document. The agency contacted and questioned at least one cypherpunk, but took no formal action. "There was no information in the document that would be considered damaging to national security," said Judi Emmel, public-relations officer for the NSA. But observers say the episode presaged the inevitable: digital enactments of civil disobedience not seen since publication of the Pentagon Papers in 1971. In that case, a one-time Pentagon consultant named Daniel Ellsberg leaked documents to The New York Times and Washington Post, detailing decades of official deceit, ineptitude and ignorance over Vietnam foreign policy. The Justice Department attempted--unsuccessfully--to bar newspapers from printing the papers, arguing that publication threatened U.S. soldiers and wartime strategy. Ellsberg, whose action contributed to President Nixon's eventual disgrace and resignation, was charged with 12 counts of espionage, conspiracy and theft. The case ended in a mistrial. Inevitably, Net observers say, an Ellsberg-style cyber protester will post classified documents on the Internet--not as a prank, but to embarrass, disrupt or otherwise bait the government. Digital protests could take other forms as well -- everything from mail "bombs" -- long files meant to slow a system's functions or operations -- to viruses or "hacking" (entering and damaging files in) federal computers. If such actions happen, the government's response may move legal principals behind the First Amendment and Bill of Rights to a new and untested electronic arena. "It's absolutely going to occur," said Winn Schwartau, author of the recently published "Information Warfare." As government documents leak and people get hold of them, whether for personal or political reasons they're going to be on the Net." Like Ellsberg, cypherpunks say their aim is to expose government mendacity and incompetence as a defense of the public's right to know in a democracy. Their target: the Clipper chip, a device placed in computers that would enable security agencies to eavesdrop on, store and search all electronic communications. Last month's episode began when a 25-year-old Austin, Texas, computer engineer, Chris Goggans, posted an electronic version of the NSA manual in Phrack, an on-line magazine he publishes. It was then copied and redistributed to Electronic Frontier Foundation (an activist organization) and cypherpunk news groups on the Internet. Goggans, who uses the on-line alias "Erik Bloodaxe," reported that he received the manual in a white envelope with a Silicon Valley-area postmark and no return address. It's impossible to determine how many of the Internet's estimated 15 million to 20 million users saw the posting. Among the Net's community of users concerned about electronic privacy, it received wide distribution. Traditionally the NSA, whose specialty is decoding encrypted information, has been steeped in secrecy. During the Cold War era, its existence was routinely denied, but it has become more open since President Clinton office. The NSA manual urges employees to be vague about their job without drawing "attention to themselves nor to their association with this agency." Intelligence employees with specific job classifications are directed to "generalize" their titles to "research analyst." The manual states that it is "FOR OFFICIAL USE ONLY," encompassing "information or material which, although unclassified, ... should not be given general circulation." If the manual is disclosed, "appropriate administrative action will be taken to determine responsibility and to apply corrective and/or disciplinary measures," it states. Emmel indicated that the agency, although "not particularly pleased" with the cypherpunk posting, did not consider it illegal. "A Freedom of Information request could do the same thing," she said. Cypherpunks say the symbolism is more meaningful than the action itself. The manual was posted "to embarrass the NSA at a point where they are pushing the Clipper chip," wrote Grady Ward, an Evergreen State College graduate living in northern California, in response to an electronic inquiry. "If the NSA can't keep its own security manual from the hands of the public, what guarantees they can keep the Clipper keys" from falling into the wrong hands, he said. Ward was contacted afterward by an NSA security officer, whom he gave instructions on how to subscribe to Phrack. A Seattle cypherpunk, Matt Thomlinson, who goes by "Phantom," said he would have published the NSA manual even if it had been classified. A Univeristy of Washington senior from Auburn who had never heard of the Pentagon Papers episode, Thomlinson said he would publish classified documents to make a point only if doing so would neither harm national security, nor put someone in physical jeopardy. "It really depends on the situation," he said. The Clipper chip is designed to encrypt data transmissions over telephone lines so they cannot be read without a decoding key. Under the administration's plan, one half of the key would be held in escrow by the Treasury Department and the other by the National Institute of Standards and Technology within the Commerce Department. Government security agencies would have to get permission from the escrow agencies to use the key to decode suspect communications. Cypherpunks, a largely anonymous group of programmers whose name combines the terms cyberpunk and cipher(using the British spelling), support encryption, but say only senders and recipients should hold the keys. They argue that the Clipper keys would fall into the hands of terrorists, criminals or spies. "The idea that nobody will do this is ludicrous," said Scott Northrop, a Seattle cypherpunk who uses the pseudonym "Skyhawk." "The incentives are enormous." The Clipper chip would be replicated, they say, or obtained by a double agent such as Aldrich Ames, who has been in the news latedly for selling classified material to the Russian government. "They (cypherpunks) didn't have to go to the trouble of printing the NSA manual to make their point," said Jim Warren, a Silicon Valley computer-industry pioneer who founded an annual conference on Computers, Freedom and Privacy. "Aldrich Ames is evidence enough." Warren thinks foreign corporations after trade secrets would eagerly pursue Clipper technology -- "and they have a considerably more suspicious profile than foreign governments." The administration counters that without the Clipper "trap door" capability for monitoring communications, encryption will be used to conceal covert or illegal activities from enforcement authorities. Administration officials have suggested that without Clipper capability, encryption may have to be banned altogether. An attempted ban would be a folly, said Schwartau: "From a political, social, technological and pragmatic standpoint, it ain't gonna happen." A popular slogan on the Internet sums up opposition to a ban: "If encryption is outlawed, only outlaws will have encryption." Unswayed, the administration is moving to put Clipper encryption in government interagency communications. So far it has indicated that compliance by private industry and citizens should be voluntary. If classified documents were posted on the Internet, it's unclear what government response would be. Emmel said such a step would be met with "appropriate action," but she declined to elaborate. ----- Matt Thomlinson University of Washington, Seattle, Washington. phone: (206) 548-9804 Check my home page -- ftp://ftp.u.washington.edu/public/phantom/home.html Get PGP 2.2 or 2.5 key via email or finger phantom(a)hardy.u.washington.edu

1 0

Diff utility available from SIMTEL
by edgar＠spectrx.sbay.org 17 Dec '03

17 Dec '03

To: rel(a)lipo.st.co.at (Roland E. Lipovits) CC: Cypherpunks <cypherpunks(a)toad.com> Roland, Thanks for posting the additional changes needed for Alan Barrett's formatting of 8-character Key ID's. It was very helpful. You also said, (Sorry for the format, I have no diff-utility therfore it's made by hand.) You can get a free diff utility from SIMTEL. dif115ax.zip 73327 02-04-93 <gnuish> B GNU Text file differences finder, v1.15, EXE You can get via FTP from Repository primary mirror site OAK.Oakland.Edu (141.210.10.117) and its mirrors wuarchive.wustl.edu (128.252.135.4), archive.orst.edu (128.193.2.13), ftp.uu.net (192.48.96.9), ftp.funet.fi (128.214.6.100), src.doc.ic.ac.uk (146.169.2.1), ftp.switch.ch (130.59.1.40), archie.au (139.130.4.6) or NCTUCCCA.edu.tw (140.111.1.10), ftp.technion.ac.il (132.68.1.10), or by e-mail through the BITNET/EARN file servers. If you don't have FTP you can order it via an E-mail server. To: LISTSERV(a)VM1.NODAK.EDU (ND State Univ - SIMTEL) Subject: any Body: /PDGET MAIL /pub/msdos/gnuish/dif115ax.zip -- edgar(a)spectrx.sbay.org (Edgar W. Swank) SPECTROX SYSTEMS +1.408.252.1005 Cupertino, Ca

2 1

sorry, serios error in previoos text
by jp＠jep.pld.ttu.ee 17 Dec '03

17 Dec '03

It is rather hard to factorize even small primes :-) it should of cource read like fact. large numbers. JP from TTU.

1 0

Re: New MacPGP
by catalyst-remailer＠netcom.com 17 Dec '03

17 Dec '03

>Why don't you ask Eric? 99% of the people on the list have no >administrative access to this or any other FTP site. (You could also >contact Mike Johnson, who runs a pretty good crypto archive.) Mike at mpj(a)netcom.com put it up within a day. That was a week after I sent it to both Erics, Tim May, and a few other people who were on this list who seemed interested in it. I *did* come to you guys first :-). What y'all been up to? Nice soda remailer, though it looks too hard to use ;-). - Nik

2 1

Re: New MacPGP2.3a has arrived.
by Nikolaos Daniel Willmore 17 Dec '03

17 Dec '03

:: Request-Remailing-To: cypherpunks(a)toad.com Nice four posts of noise toady PM. Drop everthing? How 'bout stick it on your ftp site and shut up about it? Dork.

1 0

No Subject
by Anonymous 17 Dec '03

17 Dec '03

> From owner-cypherpunks(a)toad.com Tue May 31 09:34:37 1994 > Date: Tue, 31 May 1994 09:31:57 -0400 > From: Nikolaos Daniel Willmore <ndw1(a)columbia.edu> > To: cypherpunks(a)toad.com > Subject: Re: New MacPGP2.3a has arrived. > Sender: owner-cypherpunks(a)toad.com > > :: > Request-Remailing-To: cypherpunks(a)toad.com > > Nice four posts of noise toady PM. Drop everthing? How 'bout stick it > on your ftp site and shut up about it? Dork. > Heh heh. Suggestion: Read the "How To" document for the remailers before trying something like this next time, Nikolaos Daniel Willmore.

1 0

Re: New MacPGP2.3a has arrived.
by snyderra＠dunx1.ocs.drexel.edu 17 Dec '03

17 Dec '03

At 7:55 AM 5/31/94 -0400, Perry E. Metzger wrote: Is my lack of action on this topic going to be of real impact to me? >Will I be thrown in jail for not knowing what AE is, or why MacPGP >might want to be aware of it? Will my inactivity result in the deaths >of millions of sea otters? AE means Apple Event. If the new MacPGP supports Apple Events, that makes it scriptable, which is a wonderful thing. It means that I can (as I can do with RIPEM Mac today) pull down a menu in my mail reader, Eudora, and have a message encrypted or signed automatically. However, it appears to still be the infringing 2.3 code, which I won't run, given that I do live in the US. Let me know when a Mac version of 2.5/2.6 is out. Bob -- Bob Snyder N2KGO MIME, RIPEM mail accepted snyderra(a)dunx1.ocs.drexel.edu finger for RIPEM public key When cryptography is outlawed, bayl bhgynjf jvyy unir cevinpl.

1 0