- cypherpunks-legacy - lists.cpunks.org

Factoring Broken, news at 11
by rjc＠gnu.ai.mit.edu 17 Dec '03

17 Dec '03

A friend of mine told me that a friend of his (who I know), has a professor who knows someone at Bellcore who has just succeeded in a factoring breakthough. Supposedly it relies on quantum complexity theory or something else I've never heard of. Of course, I think it's total bullsh*t and probably a misinterpreted April Fools joke, but there's always the possibility.... Just thought I'd relay this semihumorous tidbit. (and possibly start another nasty net.rumor ;-) ) -Ray -- Ray Cromwell | Engineering is the implementation of science; -- -- rjc(a)gnu.ai.mit.edu | politics is the implementation of faith. --

1 0

Laundering money through commodity futures
by gnu 17 Dec '03

17 Dec '03

I wonder if anonymous digital cash will really consist of shares in frozen orange juice futures... John Date: Fri, 15 Apr 1994 06:55:58 -0400 From: farber(a)central.cis.upenn.edu (David Farber) Subject: The Soft Pork Underbelly of Efficient Markets [I knew electronic markets were good for something .. djf] To: interesting-people(a)eff.org (interesting-people mailing list) Date: Thu, 31 Mar 1994 23:30:20 -0500 From: Peter Wayner <pcw(a)access.digex.net> Subject: The Soft Pork Underbelly of Efficient Markets The Under Pork Belly of Efficient Markets, or How to Launder Money Using Cattle Futures The great promise of electronic networks and virtual communities is a collection of very efficient markets. In the future, information will be moved, products will be sold and trades will be executed in a blink of an eye. This efficiency is usually considered to be a pretty good thing by everyone in business, in economics or in line at the video store. The underside of this efficiency, though, is a blurring of the line between legitimate and illegitimate business. A good way to understand this effect is to study the case of how to launder money using the futures markets. Laundering money is an age old problem for people who want to move funds from person A to person B without leaving a suspicious trail. Cash is the nieve approach and it has plenty of problems: it is bulky, it can be lost or stolen, and most importantly it often leaves people asking "Hey, where did that come from?" The futures markets, though, make it simple to move funds in a way that is indistinguishable from ordinary commerce. If it is done correctly, the recipiant, person A, looks like a lucky stiff or a market savvy investor. Person B is usually out of the picture or out of luck. The same games can be played with almost any other market, but futures markets are so efficient that the process is actually feasible and easy to do. The basic transaction in futures is to buy or sell a contract for the delivery of x pounds/barrels/tons/feet of some commodity at y dollars/yen/marks etc. If you buy a contract, then you're obligated to actually cough up y dollars when the contract comes due. Most people don't hold on to the contracts long enough for them to actually take delivery. They sell another contract and the futures market maintains a clearing house that is responsible for matching up the contracts and cancelling them out. It's a great system. Very efficient and very useful for farmers, manufacturers and others who actually produce and consume commodities. Futures markets are great for laundering money, though, because they can generate big losses or big gains in a short amount of time. It is quite possible for $100 to turn into a $5000 gain overnight. The downside is that it can often turn into a $5000 loss in the same amount of time. In fact, the market is a zero sum game. If you make n dollars, then there is someone out there who just lost n dollars. The sum total of the losses and the winnings equals zero. This zero sum nature is the key to laundering the money. Person A and Person B get together and guess that the price for a commodity is going to go up. That means that who ever buys a contract will make money. So Person A, the intended recipient buys a contract and Person B sells a contract. If they're right, then Person A gets the money and Person B loses the same amount. Bingo. The money moved from B to A and no one can trace how it got there. Person A looks smart or lucky and Person B looks out of luck. There was no direct connection between the two. There are thousands of other people out there winning and losing money at the same time. The marketplace's central clearing house arranges it so each wins and loses their rightful share. You may wonder why B bothered to sell a contract and lose money. This is the safeguard against guessing wrong. No one is correct all of the time. Even the people who try and rig the markets and corner them get burned as often as they succeed. The best investors in the futures markets, the ones who make money time after time, are the arbitrageurs. They spot inefficient pockets and try and remain neutral to the overall shifts in the market. Person B sells the contract so that if the market goes down, i.e., the wrong way, then A and B together have lost no money. It's a zero sum. Now they just have to play the game a bit longer or for stakes that are twice as high. You can think of the process as flipping a coin until you have encounter a heads. Ideally, you play this game with two players with relatively deep pockets. This means that A can cover the short term loses. This is a bit of a disadvantage because many money laundering operations must move cash from the rich to the poor. You can cover up this problem by using the same broker for A and B. The broker executes the trades and then assigns the winning trade to A and the losing trade to B. They fill in the order books after the fact. Using the same broker for A and B can be problematic because it may look too suspicious if the mirrored trades appear on the same ledger. The beauty of this system is that it can look quite indistinguishable from normal business practices. Many companies actively enter the futures markets to hedge themselves against foreign currency movements. Others actively enter the futures markets to guarantee themselves a good supply of their raw materials. The essential point of this lesson is that fast, efficient markets make it possible to move money easily. The futures markets were designed so that is no real other half to every trade. It's literally you against the world with every trade. The RISKS, of course, is that accountability can vanish as the size of the crowd grows to be as big as the world. There is no way to catch up with this. The futures market are so great because there is no need to deal one on one. The effects of speed are not only apparent in big financial markets. Credit cards and overnight delivery are a dangerous combination. You could steal cards, order a fortune of stuff, arrange for it all to be delivered overnight and then jump town quickly before people notice the card was gone. Suddenly, merchants must deal with the fact that something that used to be complete legitimate (exchanging cash for goods) is now a potential theft. Of course, there are other crimes that lose their edge. It is much harder to escape the law by heading to a new town. Computerized fingerprint files are very, very efficient. I think everyone felt that perfect, computerized markets would bring about the right mixture of accountability and efficiency. It would be a perfect mixture of Big Brotherly scrutiny would take care of everything. Every trade, after all, is recorded in the futures market. Yet, the best mechanism for anonymous fund transfer yet discovered exists here in the midsts of all of this record keeping, legal scrutiny and oversight. ------- End of Forwarded Message

3 2

PGP Enhanced Messaging (PEM)
by Rick Busdiecker 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- I've made my PGP Enhanced Messaging (PEM) available via anonymous FTP on H.GP.CS.CMU.EDU in /usr/rfb/pem/. This is free software available under the terms GNU Public License. I'm enclosing some information from the +Read.Me+ file for the distribution archive (ftp://h.gp.cs.cmu.edu/usr/rfb/pem/) as well as the one for the the software itself. Changes since the most recent distributed version include: - New keybindings that meet RMS specifications. - Some fine tuning related to generating and verifying `header signatures' for messages that include lines starting with either "From " or ">From ". If you pick this up, please send mail to me <rfb(a)cmu.edu> to let me know. Rick ====================================================================== This is a distribution archive for PGP Enhanced Messaging (PEM). The files contained here are: +Read.Me+ This file pem.tar.gz compressed (with gzip) archive pem.tar.gz.asc PGP signed and armored compressed archive pem.tar.gz.sig detached signature for pem.tar.gz rfb(a)cmu.edu my public key block Notes: - There is no uuencoded file. pem.tar.gz.asc can be mailed safely. - If you're concerned about tampering at this archive site, you should fetch my public key block from elsewhere. The public key server at pgp-public-keys(a)pgp.mit.edu is a good place to get it. ====================================================================== PGP Enhanced Messaging (PEM) should not be confused with the Privacy Enhanced Mail standard (PEM). Information on integrating PEM into your GNU Emacs environment is included at the end of this file. The idea behind PEM is to provide a set of Emacs Lisp functions to augment common mailers and newsreaders with PGP related operations. PEM is implemented in layers. There are customization variables defined at each level. They are described later in this document. At the highest level, each supported messaging package has a file that implements the functions that are specific to that package. Currently there are: pem-mhe.el For use with mh-e.el, and Emacs interface to the MH mailer. pem-gnus.el For use with the GNUS newsreader. Appropriate hook functions are defined which add standard function bindings to the various modal key maps. Typically, the following bindings will be in place in any message related buffer: C-c C-d Decrypt next PGP block in current message C-c C-e Encrypt current message C-c C-i Insert a public key into a message C-c C-n sign aNd encrypt current message C-c C-s Sign current message C-c C-v Verify next PGP signed block in current message C-c C-x Extract next public key from message [ Note: This is a change from previous versions where, for example, C-c d and C-c D would be defined. RMS says to do bindings this way and leave those other bindings for users ] Where possible, in buffers which are for composing messages, the standard mechanism for committing (sending or posting) a message will be augmented to support signing and/or encrypting. In buffers which are not for composing messages, the upper case versions are also defined without the C-c prefix, e. g. "D" will decrypt the current message. A notable exception to this is the GNUS *Summary* buffer which has the following default bindings: D gnus-summary-mark-as-read-backward N gnus-summary-next-article V gnus-version X gnus-summary-delete-marked-with Note that in some contexts, some of these bindings don't make sense. They are still bound, however, the function to which they are bound signals an error indicating the operation is inappropriate. For example, it does not make sense to insert your public key into the body of a news article that you are reading. However, some `obvious' restrictions are relaxed when dealing with mail. When you attempt to encrypt a mail message which you are reading, it may be `self encrypted', that is, the message body will be encrypted such that only you can decrypt it. Each of the package specific files are built on functions defined in pem.el. It contains generic message operations and deals with issues like parsing headers and addresses, and identifying PGP armored regions. At the core is npgp.el -- New pgp.el -- so named as to avoid conflicts with the pgp.el, maintained by Gray Watson <gray(a)antaire.com> and Jack Repenning <jackr(a)wpd.sgi.com>, which is available through various elisp archives. This runs PGP asynchronously and is able to deal with the erratic prompting that PGP sometimes does. For example, the first time that you use an untrusted key, PGP will prompt asking if you're sure that you want to use it. npgp.el passes the question on to you, using standard Emacs prompting to get the answer from you. PEM also uses passwd.el by Jamie Zawinski <jwz(a)mcom.com> to read passphrases. -----BEGIN PGP SIGNATURE----- Version: 2.6 iQCVAgUBLttV6JNR+/jb2ZlNAQF26AP/fyq+fxLEeqlpaP7bu5oBakgDhkm4pTlf ejo6kmlm052y+g+ax/5LF3ZsHZw0GFKyg4ltL2C8rDcgPo8dPOqv49GfHeeuS1lE HsL/wWBmhwWqijw1bOu0KAogL1I0mumSx+oeYP0Rlea9rRb2cyYYta7X5r0dGFuDWwGoXOIb9yc= =7/tF -----END PGP SIGNATURE----- -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.6 mQCNAi3iH2wAAAEEAMjRQMS6OEvdPUFX0HwxA0kYGAXUOde0Kklbdj/Gsf6QCgrA vfrLlW2jIv6Gqn345NZXQ5S45z+m4YlEZV78Ln3G1alxd22lXlo8RChs8QVdxgCX dkfVKJlcpJQfNWfrNHLMtaAB9+22p8nhGjBmTnuX5K0BQgMLCZNR+/jb2ZlNAAUR tB1SaWNrIEJ1c2RpZWNrZXIgPHJmYkBjbXUuZWR1PokAVQIFEC3iIcaIwD3rAd2b uQEBF4UB/iCxzTUBT+eAJCINmk9qkZYNWFhtt12zfyPSK9Ub2ruK6PGkjqE5HQ/b a7Fz49FX9Z70LOpJz11P9pPEmQ8CW3aJAJUCBRAt4iD6Fpk0o882PjUBATWEA/wP +WGx6GKaSHmEdtfNfGQPF70FPFRYKpugAwI/wZBHjtvNnsgTcI92Oby+b9QQDzgJ oXlerHeeoqeGpi8ZiKwIXproR5JBkB/4UuVkmIS1pP5T1D6BIUH27K6k87Yvz8JW GAqHfinoN3YOW4Fx9qZdo46aoRCGcYhTzTuXwyKxTIkAlQIFEC3iIIaTUfv429mZ TQEBmo8EAIHrwdeJ9sFb6Ro4iWxlED1OEMD+KYxfB2vu39uKGXEP1SB488uR1N7z jxcFHqZPliZ0tc2DhrUPpBY85JmI1IjtXXhS8Fbqc5Dp1Pnua+XjndaRpSSD29VH CgNvkf1S35w33GBAh8bVSgjvl8kZKOoDBV4v9ZbqG39+raZ+imAVtCBSaWNrIEJ1 c2RpZWNrZXIgPHJmYkBsZWhtYW4uY29tPokAlQIFEC48n6yTUfv429mZTQEBVwwD /iXo9pv/wFISdSwNKniNcHqogQLHjnZryzvjXNkDTvi0miBlzayozl/Q21a2nMEc 1MI8K3gNv/mP98Qw7xw5FD8F5zuY3XiFYr0GK4m0bqwixUfxkjBacb67mflCvaFS h8+K2k7Db6V0/MpV9t/VOzqjF4h5CFkoWAd+1Cr21OuQ =ruN3 -----END PGP PUBLIC KEY BLOCK-----

3 2

anti-clipper autobomber
by rarachel＠prism.poly.edu 17 Dec '03

17 Dec '03

I found this on comp-privacy. Maybe we can use a scheme like this one to send anti-clipper information over the net... Does toad.com have a usenet news feed? If so, maybe we can have a program written that scans for keywords and mails the author of the message some info about cypherpunks and clipper and digital telespying 2. I do however strongly suggest that the automail bomber keep records of who it sent a particular anti-clipper message to. We don't want to actually mailbomb people with 500 copies of the same message. Just one article would do. We could also have this program autobomb different articles based on different keywords. It would be a good idea to also keep a list of names of those who complained so we don't send'em anything again, and separate "already-sent-to" lists for different articles with a central universal "no-send" list. I would guess that this could be done with a daemon and a couple of scripts, or perhaps some atrun'ed program. The 1st program would scan all the articles for the keywords and useraddresses. It would then append any usernames it finds that have sent messages with keywords that may indicate a favorable response to the article to the article's mail list. The second program would then take the mail list for each article and remove any names found in the universal "send-no-mail-to-me" list, and in the "already-sent-to" list. The resulting list could be fed to perhaps majordomo(?) or just passed to a mailer along with the text of each article. The name would then be thrown in the "already-sent-to" list after the message completed. Perhaps at the bottom of the mailed article we can have some instructions on subscribing to cypherpunks, or telling this autobomber to put the name into the "no-send" list. Perhaps a message to majordomo with "remove autobomber" or something... I'd imagine that this would create quite a lot of traffic for toad.com, not to mention the requirements of huge names lists... Maybe if the articles are periodic and are no longer sent after a month, it can help keep the storage and traffic in check??? Anyway, here's the article: Article 1117 of comp.society.privacy: Path: prism.poly.edu!cmcl2!yale.edu!yale!gumby!newsxfer.itd.umich.edu!gatech!howland.reston.ans.net!vixen.cso.uiuc.edu!uwm.edu!computer-privacy-request From: "Paul W. Robinson" <PAULW(a)TDR.COM> Newsgroups: comp.society.privacy Subject: Every Move You Make...I'll Be Watching You Date: 14 Apr 1994 23:41:27 GMT Organization: Computer Privacy Digest Lines: 39 Sender: comp-privacy(a)uwm.edu Approved: comp-privacy(a)uwm.edu Message-ID: <comp-privacy4.52.5(a)cs.uwm.edu> NNTP-Posting-Host: 129.89.2.6 X-Original-Submission-Date: 14 Apr 1994 02:43:17 -0400 (EDT) X-Submissions-To: comp-privacy(a)uwm.edu X-Administrivia-To: comp-privacy-request(a)uwm.edu X-Computer-Privacy-Digest: Volume 4, Issue 052, Message 5 of 19 Originator: levine(a)blatz.cs.uwm.edu "Paul W. Robinson" <PAULW(a)TDR.COM> stated: Here's something which might be of interest to you. A large Educational Instuitution's computer is watching everything sent in newsgroups and possibly in some mailing lists. I am using a modified address of PAULW(a)TDR.COM instead of PAUL because that computer has already sent me a message to PAUL(a)TDR.COM. I want to try to see what it does this time. In one list I mentioned that the Massachusetts Institute of Technology (you know what the 3 letter abbreviation is) has a system that collects E-Mail addresses of people who post to newsgroups. That site used to be called "pit-manager". I am writing this message in this way to see what happens. Apparently, any time one of the Institute's computers sees a reference to "pit-manager" it mails a message to the sender telling them that the site was changed to the address "rtfm". I am not referencing the internet address that ends in .EDU here for that educational Institution because I want to see if the Massachusetts Institute of Technology's computer is checking based upon someone using the name "pit-manager" or is it because of reference to the Institute's domain name with that term used within the message? I don't know if a program that is sending out messages based on it scanning the contents of messages that it saw is a good idea. Consider a program that checked for spelling errors and criticized people who misspelled words by telling them of all the words they misspelled. (Considering how bad some people's writing is, that might not be a bad idea.) This sort of practice could be prostituted into to all sorts of interesting political correctness tactics by having automated programs that watch for comments someone doesn't like and mailing the writer complaints. --- Paul Robinson - Paul(a)TDR.COM

2 1

Blind signature cash patents
by hfinney＠shell.portal.com 17 Dec '03

17 Dec '03

A little while ago someone posted about a new company that would do patent searches via email requests. For another week they are doing free searches as an introductory offer. I did a search on blind-signature based cash systems, and these are the patents it found. This might be useful for those considering implementing electronic cash. Full text of patents are available for $4.95. The kind of search I did for free will cost $149 after another week. People are allowed 3 searches per day for free until then. For more info send a message with just "help" in the body to spo_patent(a)spo.eds.com. Hal 2 04977595 19901211 380/24 Method and apparatus for implementing ++electronic++ ++cash++ Inventor: Ohta; Kazuo Assignee: Nippon Telegraph and Telephone Corporation Abstract: In an ++electronic++ ++cash++ implementing method, a user makes a ++bank++ apply a ++blind++ signature to user information Vi produced, by a one-way function, from secret information Si containing identification information, thereby obtaining signed user information. Further, the user makes the ++bank++ apply a ++blind++ signature to information containing authentication information Xi produced, by a one-way function, from random information Ri, thereby obtaining signed authentication information. The user uses an information group containing the signed user information, the signed authentication information, the user information and the authentication information, as ++electronic++ ++cash++ for payment to a ++shop++. The ++shop++ verifies the validity of the signed user information and the signed authentication information, and produces and sends to the user an inquiry. In response to the inquiry the user produces a response Yi by using secret information and random information and sends it to the ++shop++. Having verified the validity of the response the ++shop++ accepts the ++electronic++ ++cash++. 3 05224162 19930629 380/24 ++Electronic++ ++cash++ system Inventor: Okamoto; Tatsuaki Assignee: Nippon Telegraph and Telephone Corporation Abstract: In an ++electronic++ ++cash++ system, K sets of ++blind++ signature information are derived from secret information containing identification information of a user, K/2 sets of them are opened and a ++bank++ attaches a ++blind++ signature to the remaining K/2 sets of information. The user obtains a signed license from the ++blind++ signature. The user generates ++blind++ signature information from the license and a desired amount of money and gets a ++blind++ signature of the ++bank++ to the ++blind++ signature information and obtains ++electronic++ ++cash++ signed by the ++bank++ from the ++blind++ signature. The user presents to a ++shop++ a residue power root of a node in a money hierarchial structure and the ++electronic++ ++cash++, corresponding to the amount of money to be used, and the ++shop++ verifies their validity and, if they are valid, offers inquiry information to the user. The user offers, as response information, a residue power root of the node corresponding to the amount of money to be used to the ++shop++. The ++shop++ verifies the validity of the response information and, if it is valid, acknowledges the payment with ++electronic++ ++cash++ of the amount of money to be used. 4 04759063 19880719 380/30 ++Blind++ signature systems Inventor: Chaum; David L. Abstract: A cryptographic system allows, in one exemplary use, a supplier to cryptographically transform a plurality of messages responsive to secret keys; the transformed messages to be digitally signed by a signer; and the signed transformed messages returned to the supplier to be transformed by the supplier, responsive to the same secret keys, in such a way that a ++digital++ signature related to each original message is developed by the supplier. One important property of these systems is that the signer cannot determine which transformed message received for signing corresponds with which ++digital++ signature-even though the signer knows that such a correspondence must exist. 6 04914698 19900403 380/30 One-show ++blind++ signature systems Inventor: Chaum; David Abstract: Numbers standing for ++cash++ money can be ++spent++ only one time each, otherwise the --account-- from which they were ++withdrawn++ would be revealed. More generally, a technique for issuing and showing ++blind++ ++digital++ signatures ensures that if they are shown responsive to different challanges, then certain information their signer ensures they contain will be revealed and can be recovered efficiently. Some embodiments allow the signatures to be unconditionally untraceable if shown no more than once. Extensions allow values to be encoded in the signatures when they are shown, and for change on unshown value to be obtained in a form that is aggregated and untraceable. 11 04949380 19900814 380/30 Returned-value ++blind++ signature systems Inventor: Chaum; David Abstract: A payer party obtains from a signer party by a ++blind++ signature system a first public key ++digital++ signature having a first value in a withdrawal transaction; the payer reduces the value of the first signature obtained from the first value to a second value and provides this reduced-value form of the signature to the signer in a payment transaction; the signer returns a second ++digital++ signature to the payer by a ++blind++ signature system in online consummation of the payment transaction; the --paper-- derives from the first and the second signature a third signature having a value increased corresponding to the magnitude of the difference between the first and the second values. Furthermore, the following additional features are provided: payments are unlinkable to withdrawals; a ++shop++ between the payer and signer can be kept from obtaining more value than desired by the payer; the first value need not be revealed to the signer or intermediary in the payment transaction; the returned difference can be accumulated across multiple payment transactions; and the returned difference can be divided between a plurality of payment transactions. 19 04759064 19880719 380/30 ++Blind++ unanticipated signature systems Inventor: Chaum; David L. Abstract: An improved ++blind++ signature system not requiring computation during ++blinding++ for anticipating which of a plurality of possible signatures will be made during signing, while still allowing the ++blinding++ party to unblind and recover the unanticipated kind of signature on what was ++blinded++. An exemplary embodiment ++blinds++ by forming a product including a plurality of generators raised to powers normally secret from the signing party, and unblinds by forming a product with the multiplicative inverse of a signed form of the generators raised to the original powers. Re-blinding allows a signature on a value to be transformed into a signature on a particular ++blinded++ form of the value. 23 04206315 19800603 380/23 ++Digital++ signature system and apparatus Inventor: Matyas; Stephen M. Assignee: International Business Machines Corporation Abstract: A ++digital++ signature machine provides a simplified method of forming and verifying a signature that is appended to a ++digital++ message. A sender transmits a signature with the usual signature keys and with validation table entries that correspond to the unsent keys and with the compressed encoding of the next validation table. The receiver uses the compressed encoding of the next validation table to form validation table entries from the signature keys so that the receiver has a full validation table. This validation table is compressed and compared with the compressed encoding which was received from the sender in a preceding message.

1 0

Media Mass Mailers
by Jeff Davis 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- From: Llywelyn <samman(a)CS.YALE.EDU> Subject: Re: anti-clipper autobomber On Sat, 16 Apr 1994, Arsen Ray Arachelian wrote: > I do however strongly suggest that the automail bomber keep records of who > it sent a particular anti-clipper message to. We don't want to actually > mailbomb people with 500 copies of the same message. Just one article ::Sounds a bit like Serdar's scheme. ::Ben. Having had some experimental success with mass mailing the media, I've already considered the concept. Pertinent adresses would include major newspaper, TV and periodicals. Items would have to be newsworthy, not just informational. Personal attention would be paramount. A live person would have to monitor the responses, personally appologizing for the inconvienience to those requesting deletion, with assurances that the matter will taken care of to their satisfaction immediately. Out of the God knows how many media adresses Adam Gaffin provided me, I had two deletion requests. One from an IL local, and the other from the Pheonix Gazzette. Notable persons requesting to be kept informed of newsworthy developments on the electronic frontier include Adam Kaul of NBC News. IMHO, we need to use our technological resources to their greatest tactical and operational advantage. Albeit, ladies and gentlemen, we must consider it of paramount importance to preserve a strategy of befriending the media, avoiding at ALL COST a technological alienation of them. Serdar's roboposts are the classic example of what not to do. I'm sure if this ever gets out of the intellectual stage and into the operational, sufficient safeguards for our integrity will have been established. -----BEGIN PGP SIGNATURE----- Version: 2.3a iQCVAgUBLbBfmV/ScHuGXWgVAQHxpAQAtDl2gXZbKD621n+UNvzTtylxifqpx6ry wk4o/ZdGaA+jfJbeVnTdd/+Borq1VdgIGAyJEwBCoDft/qbuMoKrhhNAHzWcLy9T 96mNmgFzGZw0OKgniDbVkBLcL3g9uCtvce1E+XFFZeHUeXwHL3NWqOH2oiG3ti+d uk04h1SLUBI= =oPEx -----END PGP SIGNATURE----- -- PGP PUBLIC KEY via finger! JAFEFFM Speaking & Thinking For Myself! * eagle(a)deeptht.armory.com email info(a)eff.org * *** O U T L A W S On The E L E C T R O N I C F R O N T I E R **** ***** Committed to Free Public Internet Access for World Peace *****

1 0

Sgt Russell
by Wayne Q Jones 17 Dec '03

17 Dec '03

Sorry for pounding this to the list but I cant get through to the Sgt Russel on my system. Q: I did not know sea06 funded the USMC . Is this some special unit or just the way it is? Q: SInce when did the Fallbrook Weapons Station need to use PGP for its security? Sounds a little black to me especially when you can get RSA for free. Wayne **************************************************************************** Qjones(a)infi.net She kissed me- I felt the hot blush * * Qjones(a)larry.wyvern.com Of raging passion incinerate my heart * ****************************************************************************

1 0

Table of Key Lengths and Brute Force Cracking Times
by tcmay＠netcom.com 17 Dec '03

17 Dec '03

Here are some numbers from Bruce Schneier's article in the April 1994 "Dr. Dobb's." The article is a review of the "Cambridge Algorithms Workshop," where Bruce also presented a paper on Blowfish. These estimates are in a slightly different form than what "Applied Cryptography" has (on pp. 130-135), and incorporate (apparently) the Michael Wiener DES-busting estimates from last summer. First, some typical key lengths for block ciphers, as reported by Schneier: Algorithm Key Block Problems/Comments DES 56 64 key too small Triple DES (3DES) 112 64 slow Khufu (Merkle/Xerox) 64 64 patented, key too small FEAL 32 64 64 patented, key too small LOKI-91 64 64 weaknesses, key too small REDOC II 160 80 patented REDOC III variab. 64 patented IDEA (Europe) 128 64 patented RC2 (RSADSI) variab. 64 proprietary Skipjack (NIST/NSA) 80 64 secret algorithm GOST (FSU, Russia) 256 64 not completely specified MMB 128 128 insecure The "problems" reported are exactly as reported by Schneier. No mention of RC4, which may in "exportable" versions may be as short as 40-45 bits. Second, some estimates of brute-force cracking time: Key Length Time for a $1M Time for a $1B ($1000M) Machine to Break Machine to Break 40 0.2 second 0.0002 sec 56 3.5 hours (Wiener) 13 sec 64 37 days 54 minutes 80 2000 years 6.7 years (2 years?) 100 7 billion years 7 million years 128 10^18 10^15 years 192 10^37 years 10^34 years 256 10^56 years 10^53 years Note that a billion dollar cipher-busting machine is not out of the question. Norm Hardy once described to us the $100M "Harvest" machine (also described by Bamford). NSA has its won on-site wafer fab facility (built by National Semiconductor several years back). A single Space Shuttle launch costs around a billion dollars (NASA says $0.6B, GAO says $1.5B), and many of the launches are just put up reconnaisance and SIGINT satellites, so spending $500M to $1B on special computers to crunch the data seems plausible. (However, it's hard for NSA to make plans for what key length they'll have to target. It's also not clear that enough non-financial users have been using DES to make it "necessary" for such large expenditures....a single machine that can crack a DES-encrypted message in, say, 1-10 hours may be enough for their current needs. All of this is just speculation.) For logistical and other reasons, I would expect they may have _several_ smaller machines. Just as effective, of course, cumulatively. Obviously a billion dollars worth of hardware will not be dedicated for a couple of years to crack a single 80-bit cipher. Anyway, you all can fool with these numbers and draw your own conclusions. Ron Rivest did some similar calculations for RSA modulus sizes and came to similar conclusions (e.g., 1200-bit modulus will withstand even attacks by billion-dollar machines for several more decades). --Tim May -- .......................................................................... Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay(a)netcom.com | anonymous networks, digital pseudonyms, zero 408-688-5409 | knowledge, reputations, information markets, W.A.S.T.E.: Aptos, CA | black markets, collapse of governments. Higher Power: 2^859433 | Public Key: PGP and MailSafe available. "National borders are just speed bumps on the information superhighway."

2 1

remailers
by Black Unicorn 17 Dec '03

17 Dec '03

For some reason I have not been able to get any of the remailers to work with PGP encryption. In addition, the ping figures at the end of the soda finger file don't seem to have changed since I first looked at them some days ago.... is this just me? Is anyone out there chaining with PGP supporting remailers? Could ya drop me a line, preferably with some reply option, and give me a few hints? [sigh]

2 1

New Remailer
by Istvan Oszaraz von Keszi 17 Dec '03

17 Dec '03

Could someone give me some quick direction on installing and running a new remailer. Due to system constraints, I've had to rewrite some of the mailer software, I've tested it, and it seems to operate fine. My question is what is necessary, to create an address for the remailer? I'd like it addressed as something other than my personal account. Do I contact my sysadmins for a new address, or is this something which is user configurable. Thanks BTW: Do I open up the remailer to the public or do I ask some of the users of remailers to help me test it prior to a world release.

4 3