December 2003 - cypherpunks-legacy

Re: encryption laws (fwd)
by Jim Choate 17 Dec '03

17 Dec '03

Forwarded message: > From: frissell(a)panix.com > Date: Wed, 21 May 1997 07:45:35 -0400 > >If they had reasonable cause to believe you had knowledge of the key and > >were refusing to divulge it under direct order of the court you would be > >held in contempt until you were very old and gray. > Two years max. A lot less time if you followed my strategy of spamming the > court with daily (hourly?) screeds in which you assert in your finest Usenet > flame language the fact that you will never follow the judge's order. Your contention is that the longest a judge can hold you on contempt charges is two years? I would love to see a reference on this one. Jim Choate CyberTects ravage(a)ssz.com

1 0

Free Wall Street Journal Interactive Edition on PointCast
by WSJ Interactive Edition Editors 17 Dec '03

17 Dec '03

In the past, you tried The Wall Street Journal Interactive Edition through a special offer. We now invite you to get selected content from The Interactive Journal in a whole new way with PointCast! With free PointCast Network software and The Wall Street Journal Interactive Edition channel, you get top business news summaries from around the globe as well as several feature articles and columns in Editor's Picks. And PointCast broadcasts it all straight to your computer, along with personalized world news, stock updates, weather, sports, local news and much more. And when you subscribe to the Interactive Journal, you get the full story behind the summaries and comprehensive global coverage of the day's business news. For more information on how to subscribe to the Interactive Journal go to <http://wsj.com> Get The Wall Street Journal Interactive Edition channel now! Download the free PointCast software at <http://wsj.com/offers/pointcast.htm> Best regards, Jim White Marketing Manager maillist(a)wsj.dowjones.com _______________________________________________________________ Check out Small Business Suite, a new Interactive Edition feature covering issues that matter most to small business owners, entrepreneurs, and anyone who markets products or services to small businesses. http://wsj.com/edition/current/summaries/small.htm ________________________________________________________________ This is the New Features Alert e-mail list. If you do not wish to continue to subscribe to this list, sign on to The Wall Street Journal Interactive Edition and go to the following URL: http://wsj.com/user-cgi-bin/userMenu.html to change your account preferences. Or you can just send email to: stopmkt(a)lists.wsj.com Cancelling your subscription to The Wall Street Journal Interactive Edition will automatically un-subscribe you from any e-mail lists you might be subscribed to through our service. For further questions, please call our customer service department at 1-800-369-2834. __________________________________________________________________

1 0

Re: encryption laws (fwd)
by Jim Choate 17 Dec '03

17 Dec '03

Forwarded message: > Subject: Re: encryption laws (fwd) > From: dlv(a)bwalk.dm.com (Dr.Dimitri Vulis KOTM) > > If they had reasonable cause to believe you had knowledge of the key and > > were refusing to divulge it under direct order of the court you would be > > held in contempt until you were very old and gray. > > Yes - the 5th Amendment is useless like all the other consitutional "rights". The 5th is meant to apply ONLY to persons being accussed of a crime, it is not nor was it ever meant to protect non-accussed persons from turning over evidence of criminal acts. Jim Choate CyberTects ravage(a)ssz.com

2 1

Compelling a key (fwd)
by Jim Choate 17 Dec '03

17 Dec '03

Hi Tim, And here I was believing your speal about being in your kill file, oh well. It must be true that nothing is sacred. Forwarded message: > Date: Tue, 20 May 1997 22:33:35 -0800 > From: Tim May <tcmay(a)got.net> > Subject: Compelling a key > >> Would it be possible for a court to subpeona a encrypted file or key, > >> > >> and order you to tell them the key ? > >> If you didn't would you be held in 'contempt of court' ? > > > >If they had reasonable cause to believe you had knowledge of the key and > >were refusing to divulge it under direct order of the court you would be > >held in contempt until you were very old and gray. > > Not necessarily. Mike Godwin, and others, have written about the > "compelling of keys." It is by no means clear that a key can be compelled. > Citing the Fifth is one approach, saying one "forgot" is another. Citing the 5th ONLY works if no immunity from prosecution for the results is offered. If the judge offers and you refuse, don't worry about buying toothpaste for many years. Saying you 'forgot' will not keep you out of jail on contempt. It might buy you sympathy from the jury but then again, they have nothing to say about contempt charges. > As to being held indefinitely, imprisonment as an inducement to cooperation > has limits. (I just saw a spiel by Alan Dershowitz and others on this > tonight, vis-a-vis how long Susan McDougal can be imprisoned for contempt > in the Whitewater investigation.) > > Basically, only until there is no reasonable expectation that the contempt > will be satisfied (or whatever the exact term is). > > In practice, I think the Washington, D.C. doctor, Elizabeth X, the woman > who refused to say where her children were, was held for about 2 years, and > that this was the all-time record for a contempt case. She was ultimately > released when the court concluded she had no intention of cooperating. Exactly! It is ENTIRELY up to the individual judge who issued the contempt citation. If they are pissed enough 2 years will be nothing. As far as I have been able to find there are NO statutes, other than that of a statute of limitation for a particular type of crime, that limit how long you can sit in jail on contempt. The only way you would get out in that case would be to file with the appropriate courts for a writ of habeas corpus. Jim Choate CyberTects ravage(a)ssz.com

3 2

Swiss Consortium Chooses RPK Fast Public Key Cryptosystem for Next Generation Wireless Electronic Transactions (fwd)
by cpunks＠algebra.com 17 Dec '03

17 Dec '03

----- Forwarded message from Jack Oswald ----- >From cpunks(a)manifold.algebra.com Wed May 21 01:48:18 1997 Message-ID: <01BC6572.43D8F3A0(a)1Cust125.Max9.San-Francisco2.CA.MS.UU.NET> From: Jack Oswald <joswald(a)rpkusa.com> To: "'joswald(a)rpkusa.com'" <joswald(a)rpkusa.com>, "'maujacca(a)iprolink.ch'" <maujacca(a)iprolink.ch> Subject: Swiss Consortium Chooses RPK Fast Public Key Cryptosystem for Next Generation Wireless Electronic Transactions Date: Tue, 20 May 1997 18:41:20 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Sender: owner-cypherpunks(a)toad.com Precedence: bulk Also see recent press coverage in Infoworld: RPK announces deal for fast crypto with Swiss consortium http://www.infoworld.com/cgi-bin/displayStory.pl?97059.wrpk.htm=20 SET 2.0 on the way http://www.infoworld.com/cgi-bin/displayArchive.pl?/97/16/t04-16.1.htm=20 PRESS RELEASE For Release May 19, 1997 RPK, Inc.: Jack Oswald, +1 408.479.7874, joswald(a)rpkusa.com, = http://www.rpk.co.nz=20 ADESA, Inc.: Maurice Jaccard,+41 22.910.29.14, maujacca(a)iprolink.ch Swiss Consortium Chooses RPK Fast Public Key Cryptosystem for Next = Generation Wireless Electronic Transactions Swiss Federal Institute of Technology (EPFL) and ADESA, Inc. introduce = HAWK VLSI cryptography-enhanced processor San Francisco, CA - RPK, Inc. announced today that a consortium of the = Swiss Federal Institute of Technology (EPFL) and ADESA, Inc., a Swiss = application specific integrated circuit (ASIC) design firm have chosen = the RPK Fast Public Key Cryptosystem to provide strong cryptographic = security in a next generation wireless electronic transactions = application. At the same time, EPFL and ADESA unveiled HAWK a new = generation cryptography-enhanced microprocessor specifically designed = for use in high speed/low power embedded applications. "The RPK encryption technology won the design review after an extensive = evaluation of all existing cryptosystems based on well known and = understood cryptographic techniques," said Maurice Jaccard, Managing = Director of ADESA, Inc. "With RPK there are no compromises. We get = uncompromised security, high speed and low cost of implementation." "RPK is a strong encryption technology based on well know and trusted = cryptographic techniques," said Jack Oswald, President and CEO of RPK = Inc. "Having RPK chosen by the Swiss for this breakthrough = electronic-commerce application is the strongest endorsement we could = possibly achieve for the RPK technology." Wireless Electronic Transactions Application The collaboration of RPK, EPFL and ADESA has resulted in a prototype = application that promises to become the "wallet of the future". This = new wireless electronic transaction application may take the form of a = credit card, a watch or a key chain and will sport features analogous to = the leather wallets used today by billions of people worldwide. Early = designs of the system allow the user to withdraw and hold cash in = multiple currencies, as well as, purchase and hold vouchers for hotels, = planes and car rentals all through the use of wireless communications = technology. Officials in charge of the project envision that such = devices could also become a personal key chain for gaining access to = motor vehicles, offices and dwellings, in addition to traditional credit = card uses. ADESA concluded that performance of the RPK implementation in the = prototype far exceeded existing smart card implementations based on the = RSA and other algorithms. The RPK technology performs the necessary = encryption functions in less than 10 milliseconds using an 823-bit key = compared to the best performing RSA-based equivalents that require = greater than 100 milliseconds to perform the same type of function using = a much weaker 512-bit key. The application is not limited to 823-bit = keys. The design of the system, based on the new HAWK processor is = flexible and can accommodate and process various sized keys, smaller or = larger than 823 bits based on downloadable parameters. ADESA officials = explained that the simplicity of the RPK algorithm makes it much simpler = to implement than the popular RSA approach. It was RPK's simplicity, = offering a much faster and cheaper solution while providing even higher = security, that drove the choice over RSA for this application. =20 About the RPK Fast Public Key Cryptosystem RPK is a relatively new public key cryptosystem that is based on = mathematics widely used in cryptography today. It was designed to be = immediately commercially viable without the years of study that a new = area of mathematics normally requires, such as the Elliptic Curve = Cryptosystem (ECC). The source of the security for RPK is the same as = that of Diffie-Hellman key exchange, a widely used and well studied = cryptographic technique. RPK offers real advantages for high speed = networking, SmartCard, wireless communication applications as well as = high volume software processes such as credit card transactions.=20 RPK has at its core an invention called a Mixture Generator. In the = preferred implementation, three fairly long linear feedback shift = registers are used. This state machine has two modes of operation. One = that uses the shift registers for exponentiation and the other as a = generator of a random stream of bits used in a combining phase for the = actual encryption. Effectively, RPK allows for the amortization of two = "costly" exponentiations over the entire length of a message because the = core engine is used to initially establish a secure state of the machine = and then switches modes to perform very high speed encryption. This has = been referred to as a paradigm shift where the operation of encryption = does not require the costly calculations that an RSA or even an ECC = implementation would require for each block of data that is about the = size of the key. This mechanism can also be implemented in silicon = quite efficiently such that at high strength it is much cheaper to = produce than alternative technologies. Finally, it is also possible to = create a Mixture Generator that is made up of Elliptic Curve groups = which would provide a similarly speedy and efficient initialization mode = that could still produce high speed encryption as noted above. About the HAWK VLSI Crypto Processor The HAWK VLSI cryptography-enhanced processor is the result of more than = three years of research and development conducted at the EPFL in = Lausanne, Switzerland in the area of high speed compression and = encryption. The HAWK processor will benefit most cryptography = implementations but is particularly well suited for use with RPK. "The HAWK processor is the most innovative approach that we have seen = yet for implementing cryptographic processes in silicon," said Bill = Raike, Chief Technology Officer for RPK Inc. and inventor of the RPK = fast public key cryptosystem. "HAWK breaks the barrier for high speed, = low cost, low power and high strength encryption for embedded systems." Background RPK, Inc. is a supplier of next generation fast public key encryption = technology. RPK was invented and originally patented in New Zealand. = The company is therefore unaffected by restrictive U.S. export rules. = RPK has been successfully exported to virtually all countries of the = world at high strength. The company's headquarters are based in San = Francisco, California, USA, with an offshore research and development = center located outside of Auckland, New Zealand. http://www.rpk.co.nz=20 ADESA, Inc. is a leading ASIC design firm based in Geneva, Switzerland = with expertise in embedded and cryptographic applications. EPFL is a leading teaching and research technical institute in Lausanne, = Switzerland. The school is known for its work in advanced processor = design. *** ----- End of forwarded message from Jack Oswald -----

1 0

Re: Just Say "No" to Congress
by David Gilchrist 17 Dec '03

17 Dec '03

At 04:26 PM 5/21/97 -0400, Ray Arachelian wrote: >On Sun, 18 May 1997, Vladimir Z. Nuri wrote: > >> R.A.: >> >You seem to be misinformed. You don't send your money to Uncle Sam. It >> >gets taken out of every pay check before you even see it. Then, come >> >April 15, you fill a piece of paper out with the hope you'll get some of >> >it back. But sometimes, Uncle Sam takes even more. Don't do it. Work for yourself. You make four payments a year. <snip> >I myself consult out. Consulting out means that the money isn't taken >out at all. You just have to pay it back come April 15. Day job, being >a full time job, money gets taken out automagically by the evil agents >of the IRS critters. Consulting money, come the 1099 form, gets taxed >after. Incorporate and you don't even get a 1099. > >So even if you manage to upturn this law and get to keep the money until >April 15, it wouldn't affect me much. IMHO it's much easier if the money >gets withheld, then having to pull hairs out doing tax forms come April. > Turbotax is hairless, painless and stupid proof. I know. I use it. >Now if you can somehow repeal income tax, that would be a useful >achievement. :) Consulting out is on the right track. While you are waiting for the income tax laws to change, _take advantage_ of what is lawfully available. Crispin wouldn't have a clue on this one. Incorporate. Any state. It's cheap. You can avoid some social security taxes for a system that won't be there in few years anyway. Remember when you could refile back a year or two if you had a bad year (income averaging)? A corporation can carry a loss back 15 years or *forward* , too, _and_ get a tax refund practically instantly. It is imho the levelest playing field available for the individual (wearing the impenetrable corporate cloak (no shit, bulletproof), impenetrable even by the irs) against taxation. As for tax forms in April, use Turbotax. You don't have to know shit and it does complicated things for you like depreciation. Depreciate your car, your home office etc. Own your assets personally and lease them to your corporation. Rents are free of social security taxes. Your car, your office etc. With a little imagination you may be able to make it fit your situation. If you're straight salary, _no_ other (reportable) income, you may be pretty much screwed but paying them when you don't have to doesn't make much sense. > <snip> >> I don't buy into the alienation and cynicism on this list peddled >> by TCM, truthmonger, et.al., and I suggest that anyone else who >> does is selling themself short, and in fact part of the problem and >> not the solution. That's my point, use them when you can. > >"If you're not part of the solution, you're part of the precipitate" -- >whomever.. Say, whatever you've been smoking, precipitate David

1 0

RFC 2144 on CAST-128 Encryption Algorithms (fwd)
by cpunks＠algebra.com 17 Dec '03

17 Dec '03

----- Forwarded message from Adam Shostack ----- >From cpunks(a)manifold.algebra.com Thu May 22 13:12:33 1997 From: Adam Shostack <adam(a)homeport.org> Message-Id: <199705221736.NAA17266(a)homeport.org> Subject: RFC 2144 on CAST-128 Encryption Algorithms (fwd) To: coderpunks(a)toad.com (The Coderpunks list) Date: Thu, 22 May 1997 13:36:16 -0400 (EDT) X-Mailer: ELM [version 2.4ME+ PL27 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-cypherpunks(a)toad.com Precedence: bulk I hadn't seen this mentioned. This is to coderpunks, bcc'd to cypherpunks & cryptography. Adam ------ A new Request for Comments is now available in online RFC libraries. RFC 2144: Title: The CAST-128 Encryption Algorithm Author: C. Adams Date: May 1997 Mailbox: cadams(a)entrust.com Pages: 15 Characters: 37532 Updates/Obsoletes: None URL: ftp://ds.internic.net/rfc/rfc2144.txt There is a need in the Internet community for an unencumbered encryption algorithm with a range of key sizes that can provide security for a variety of cryptographic applications and protocols. This document describes an existing algorithm that can be used to satisfy this requirement. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. Distribution of this memo is unlimited. ----- End of forwarded message from Adam Shostack -----

1 0

RFC 2144 on CAST-128 Encryption Algorithms (fwd)
by Adam Shostack 17 Dec '03

17 Dec '03

I hadn't seen this mentioned. This is to coderpunks, bcc'd to cypherpunks & cryptography. Adam ------ A new Request for Comments is now available in online RFC libraries. RFC 2144: Title: The CAST-128 Encryption Algorithm Author: C. Adams Date: May 1997 Mailbox: cadams(a)entrust.com Pages: 15 Characters: 37532 Updates/Obsoletes: None URL: ftp://ds.internic.net/rfc/rfc2144.txt There is a need in the Internet community for an unencumbered encryption algorithm with a range of key sizes that can provide security for a variety of cryptographic applications and protocols. This document describes an existing algorithm that can be used to satisfy this requirement. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. Distribution of this memo is unlimited.

1 0

(Fwd) key recovery report, information hiding, and fire ants
by Charles Anthony 17 Dec '03

17 Dec '03

------- Forwarded Message Follows ------- Date: Wed, 21 May 1997 09:45:53 -0700 (PDT) From: Phil Agre <pagre(a)weber.ucsd.edu> To: rre(a)weber.ucsd.edu Subject: key recovery report, information hiding, and fire ants Reply-to: rre-maintainers(a)weber.ucsd.edu [I trust Matt and Ross, but the fire ants story is too good to be true.] =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= This message was forwarded through the Red Rock Eater News Service (RRE). Send any replies to the original author, listed in the From: field below. You are welcome to send the message along to others but please do not use the "redirect" command. For information on RRE, including instructions for (un)subscribing, send an empty message to rre-help(a)weber.ucsd.edu =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Date: Wed, 21 May 1997 07:05:53 -0700 (PDT) From: risks(a)csl.sri.com Subject: RISKS DIGEST 19.17 RISKS-LIST: Risks-Forum Digest Wednesday 21 May 1997 Volume 19 : Issue 17 ---------------------------------------------------------------------- Date: Tue, 20 May 1997 20:27:08 -0400 From: Matt Blaze <mab(a)research.att.com> Subject: RISKS of Key-Recovery Encryption In January 1997, an ad-hoc group of cryptographers and computer scientists met to explore the technical implications, risks, and costs of the ``key recovery'', ``key escrow'' and ``trusted third party'' encryption systems being promoted by various governments. We have just completed a preliminary report of our findings. We have specifically chosen not to endorse, condemn, or draw conclusions about any particular regulatory or legislative proposal or commercial product. Rather, it is our hope that our findings will shed further light on the debate over key recovery and provide a long-needed baseline analysis of the costs of key recovery as policymakers consider embracing one of the most ambitious and far-reaching technical deployments of the information age. Our preliminary report is available as follows: On the web at: http://www.crypto.com/key_study In PostScript format via ftp: ftp://research.att.com/dist/mab/key_study.ps In plain ASCII text format via ftp: ftp://research.att.com/dist/mab/key_study.txt ======================================================================= THE RISKS OF KEY RECOVERY, KEY ESCROW, AND TRUSTED THIRD-PARTY ENCRYPTION Hal Abelson Ross Anderson Steven M. Bellovin Josh Benaloh Matt Blaze Whitfield Diffie John Gilmore Peter G. Neumann Ronald L. Rivest Jeffery I. Schiller Bruce Schneier 21 May 1997 Executive Summary: A variety of ``key recovery,''``key escrow,'' and ``trusted third party'' encryption requirements have been suggested in recent years by government agencies seeking to conduct covert surveillance within the changing environments brought about by new technologies. This report examines the fundamental properties of these requirements and attempts to outline the technical risks, costs, and implications of widely deploying systems that provide government access to encryption keys. The deployment of a global key-recovery-based encryption infrastructure to meet law enforcement's stated specifications will result in substantial sacrifices in security and greatly increased costs to the end-user. Building the secure infrastructure of the breathtaking scale and complexity demanded by these requirements is far beyond the experience and current competency of the field. Even if such an infrastructure could be built, the risks and costs of such a system may ultimately prove unacceptable. These difficulties are a function of the basic law enforcement requirements proposed for key-recovery encryption systems. They exist regardless of the design of the recovery system -- whether the system uses private-key cryptography or public-key cryptography; whether the database is split with secret sharing techniques or maintained in a single hardened secure facility; and whether the recovery service provides private keys, session keys, or merely decrypts specific data as needed. All key-recovery systems require the existence of a highly sensitive and highly available secret key or collection of keys that must be maintained in a secure manner over an extended time period. These systems must make decryption information quickly accessible to law enforcement agencies without notice to the key owners. These basic requirements make the problem of general key recovery difficult and expensive -- and potentially too insecure and too costly for many applications and many users. Attempts to force the widespread adoption of key-recovery encryption through export controls, import or domestic use regulations, or international standards should be considered in light of these factors. The public must carefully consider the costs and benefits of embracing government-access key recovery before imposing the new security risks and spending the huge investment required (potentially many billions of dollars, in direct and indirect costs) to deploy a global key recovery infrastructure. ------------------------------ Date: Sat, 17 May 1997 13:59:48 +0100 From: Ross Anderson <Ross.Anderson(a)cl.cam.ac.uk> Subject: Information-Hiding Workshop Call for Papers, WORKSHOP ON INFORMATION HIDING (pruned for RISKS) 15 - 17 April 1998, Portland, Oregon Many researchers are interested in hiding information or in stopping other people doing this. Current research themes include copyright marking of igital objects, covert channels in computer systems, subliminal channels in cryptographic protocols, low-probability-of-intercept communications, broadcast encryption schemes, and various kinds of anonymity services ranging from steganography through location security to digital elections. These closely linked areas of study were brought together in 1996 by a workshop on information hiding held at the Isaac Newton Institute in Cambridge. This was felt to be very worthwhile by the research community, and it was decided to hold a second workshop in 1998. This second international workshop on information hiding will be held in Portland, Oregon from the 15th to the 17th April 1998. See http://www.cl.cam.ac.uk/users/rja14/ihws.html for the call for papers. Papers should be submitted by 31 Dec 1997 to awk(a)mailbox.jf.intel.com (Program Chairman David Aucsmith, Intel Architecture Labs, 5200 N. E. Elam Young Parkway, Hillsboro, OR 97124-6497, USA). The program committee also includes Ross Anderson, Steve Low, Ira Moskowitz, Andreas Pfitzmann, Jean-Jacques Quisquater, Gus Simmons, and Michael Waidner. Details of the first (1996) information-hiding workshop are at http://www.cl.cam.ac.uk/users/fapp2/steganography/bibliography/workshop.html [Watch out for the invisible steganosauruses. PGN] ------------------------------ Date: Tue, 20 May 1997 12:33:20 -0400 From: "Mich Kabay [NCSA]" <Mich_Kabay(a)compuserve.com> Subject: Another Computer Bug: Ants in the Machine >From WIRED via PointCast: > Another Computer Bug: Ants in the Machine > by Ashley Craddock, 19 May 1997 > Stephanie Upps watched in horror as one of her final papers disappeared > off her PowerBook at 2 a.m. one night during her last semester as a > University of Texas graduate student. Her friends couldn't find the bug, > so she called the 1-800 support line in desperation. "They told me to > pull out the battery and give them the serial number," she says. "When I > did, it was just crawling with ants." Far from a fluke, Upps' encounter > with ants in the machine is happening to others with greater > frequency. "The problem's endemic across Texas," she said. The author makes the following key points: * Major problem is fire ants, an exotic introduced to the Southern US in the 1920s. * Fire ants seem to like living in and eating electrical equipment. * The critters may be attracted by electrical fields; Craddock writes,` "They have some short-range attraction to electricity," says Dr. Harlan Thorvilson of Texas Tech's Department of Plant and Soil Sciences. . . . "They become almost mesmerized and behave oddly, piling dirt against the wires and signaling to other members of their communities who come and join them." ' [MK: I don't want to make a mountain out of an ant-hill, but this looks like a case of form(icidae) over function. I expect further creepy puns from our moderator, perhaps about how the victims are engaged in formication and should ant-icipate trouble.] M.E. Kabay, PhD, CISSP (Kirkland, QC), Director of Education National Computer Security Association (Carlisle, PA) http://www.ncsa.com [Turn on the fire-hider-ants; someone is in for a shock. PGN] ------------------------------ End of RISKS-FORUM Digest 19.17 ************************

1 0

ecash & remailers
by Adam Back 17 Dec '03

17 Dec '03

It occurs to me that there is a problem with remailers using Chaum's ecash as offered by MT bank and others. The attacker could coerce the sender of an anonymous message into revealing his blinding value, and use this to obtain the identity of each remailer hop by colluding with the bank. (The bank keeps a database of the blinded coins minted against who they were given to; unblinding reveals the coin which can then be compared against those deposited by remailers, tallying sender with remailer, all the way to the exit remailer.) To stop this, the sender should discard the blinding values, thereby removing his ability to be later coerced, or to later trace the recipient of his cash. Is there a way to purge blinding values from the ecash directory? Adam -- Have *you* exported RSA today? --> http://www.dcs.ex.ac.uk/~aba/rsa/ print pack"C*",split/\D+/,`echo "16iII*o\U@{$/=$z;[(pop,pop,unpack"H*",<> )]}\EsMsKsN0[lN*1lK[d2%Sa2/d0<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<J]dsJxp"|dc`

2 1