December 2003 - cypherpunks-legacy

PGP 2.6.2 signator replacement bug fix
by Jim Castleberry 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- Here's a fix for a minor bug in PGP 2.6.2. I reported it to pgp-bugs last February and they responded promptly, but it hasn't been propagated to the release - I suppose 2.6.2 is "in the freezer". Anyway, the bug can cause a crash and other folks might like to put in the fix, so here it is. Anyone have any others? Jim Castleberry jcastle(a)in-system.com Original bug report starts here: - ------------------------------------------------------------------------- I believe I've identified a bug in PGP 2.6.2. The bug occurs on my system: HP 9000/735, running HPUX 9.03 MIT PGP 2.6.2 Compiled with either the native cc or gcc 2.6.3 Optimization level doesn't change the behavior (from -O0 to +O3). pubring.pgp contains all the keys on the servers, plus a few unpublished keys and some additional signatures. When an existing signature is replaced by a newer one by the same signator, memory gets corrupted. On my system, this results in a program abort. The problem is in file keyadd.c, function mergesigs(). When a signature is (possibly) going to be replaced, user_from_keyID() is called to get a pointer to the signator's user ID (as a C string in the in-memory user hash table. Then that pointer is passed to check_key_sig(), which passes it to getpublickey(), which passes it to readpublickey(), which reads successive user ID strings into it while it searches for the desired keyID. But the hash table contains dynamically allocated strings that are only as long as the string they hold. So when a longer user ID is read into it, memory past the end of the C string is corrupted. That trashes a hash table entry ("struct hashent"), destroying pointers and resulting in an illegal memory access later in the program. The offending code in mergesigs() only gets executed when a signature is being replaced with a more recent one by the same signator. It only showed up because I updated my pubring with all new keys on the servers for the last 31 days, and one key has an updated sig on it: pub 1024/AB1F4831 1993/05/10 Robert Walking-Owl <rrothenb(a)ic.sunysb.edu> Robert Walking-Owl <robert.rothenburg(a)asb.com> Here's a context diff for the fix. The signator userid isn't needed by check_key_sig() or the functions it calls since the signator's keyID is given, and if the userid is NULL then readkeypacket() ignores it, so just pass NULL to check_key_sig() and use the signator C string in mergesigs() as-is. Jim Castleberry - - cut here ------------------------------------------------------------------- *** old/keyadd.c Wed Oct 5 20:48:11 1994 - --- keyadd.c Wed Feb 15 22:37:53 1995 *************** *** 196,206 **** status = check_key_sig(fring, KeyIDpos, KeyIDlen, userid, fkey, keypos, ! ringfile, signator, (byte *) & xstamp, &sigClass); PascalToC(userid); - - PascalToC(signator); if (!status) { fprintf(pgpout, LANG("Replacing signature from %s\n"), - --- 196,205 ---- status = check_key_sig(fring, KeyIDpos, KeyIDlen, userid, fkey, keypos, ! ringfile, NULL, (byte *) & xstamp, &sigClass); PascalToC(userid); if (!status) { fprintf(pgpout, LANG("Replacing signature from %s\n"), -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQEVAwUBMJZkDJYkAuN55UFhAQG8aQf/bsx7xlS9P9SBE8ysMEbjMkKwdf6yZSCt fd0xBsUbTIsIS2Gzlx0ux7N3HWqJm/og2EBqebhfEzQk9IUBK8sp8Kbv8GtbUWrj ai2b6/hxu2yXbtQEAmTDJLO3fQCZ6yjkydFYaz2n+HuRxN4h6TlWwIHzQWOBCxuK qzPENr+c4YgMCHMVLGnAHDgPA8G9J/xX3UIPKQJQnrpAJwlGf+LTOkWeA+/kMLiw aos108n6698mcsIxXzHltCVlCaYYY6meFMHzD4rGjXOCURTtKTSRx1dJ7WNSn+1N JNwJSnFXrsvJRodko0fjpYnCUDNEbmEQgDsJX80wTdDfI+JH2LM/+g== =jh+s -----END PGP SIGNATURE-----

2 1

ecash remailer
by sameer 17 Dec '03

17 Dec '03

To provide payee anonymity: Enterprising cypherpunk, Ed sets up the Ecash Remailer. Alice pays Bob e$15. Alice is anonymous. Bob sends Ed the e$15 Ed cashes the e$ into his ecash mint account, withdraws e$13.50 then pays Bob those e$14 .. Bob can now spend those e$ at will. Bob is now anonymous. This requires some trust-in-Ed, but Bob could be anonymous from Ed just as Ed is anonymous. Perhaps this is the scheme lucky mentioned. I will have to get an account and implement it. -- sameer Voice: 510-601-9777 Community ConneXion FAX: 510-601-9734 The Internet Privacy Provider Dialin: 510-658-6376 http://www.c2.org (or login as "guest") sameer(a)c2.org

6 5

Electronic Warfare
by frezza＠interramp.com 17 Dec '03

17 Dec '03

Cypherpunks, With your indulgence I would like to post this short essay here, which was stimulated by a recent report posted on this list that was passed on to me. The essay just ran as an op-ed piece in this week's issue of Communications Week. I would like to thank and acknowledge the author off the original report as well as encourage the cypherpunk community to keep me posted on related issues. (I cannot keep up with the volume on this list and, hence, am not a subscriber.) Thank you, Bill Frezza Columnist Communications Week Network Computing Magazine frezza(a)interramp.com --------------------------------------------------------------------------- ELECTRONIC WARFARE WAGES ON - AND YOU'RE THE TARGET Although the flap over the Clinton administration's attempt to promote escrowed-key encryption systems like Clipper has temporarily faded, the war on electronic privacy continues. As proceedings at the Fourth International Conference on Money Laundering, Forfeiture, Asset Recovery, Offshore Investments, the Pacific Rim, and International Financial Crimes reveal, there has been no let up in our government's efforts to blockade the cyber-frontier. No, you won't learn much from the Wall Street Journal or the New York Times, written by journalist-generalists who have no clue about where this technology is heading. The Feds have become so skilled at manipulating the Old Media that stories about electronic privacy invariably center on the latest drug kingpin, pedophile, or domestic terrorist. Attacking these universally abhorred enemies of the people not only makes for good headlines but keeps privacy advocates off balance as they are forced to defend abstract rights using loathsome examples. But if you tune in to the Cypherpunks mailing list (majordomo(a)toad.com) you can get some excellent first hand reports from the front. In the relatively short period since the passage of the Bank Secrecy Act, which, among other things, obliges banks to file Suspicious Activity Reports on its customers, banks have become virtual deputies in the treasury department's war on uncontrolled financial transactions. And this war is increasingly spilling into cyberspace. The conference underscored the fact that, paradoxically, we are heading not toward more specific and well defined transaction monitoring regulations, but less. How so? The problem with making regulations precise is that what software algorithms can define, other algorithms can evade. Instead, regulation by "raised eyebrow" is becoming the norm. Federal bank examiners have been given significant latitude to invoke draconian penalties against uncooperative banks. Because bank officers have few due-process protections under this regime, it is no surprise that most of them have become sniveling toadies. The objective is to insure that banks "voluntarily" introduce even more aggressive, unpredictable, and intrusive monitoring than the government would ever dare mandate. And to make sure nothing slips through the cracks, human surveillance will be supplemented with artificial-intelligence agents that can perform pattern analysis on the aggregate flow of electronic transactions, flagging anything remotely suspicious. George Orwell would be impressed. Lest you think that all of this is motivated solely by the drug war, a visit to the Treasury Department's Financial Crimes Enforcement Network (FinCEN) homepage (http://www.ustreas.gov/treasury/bureaus/fincen/facts.html) should open your eyes. This battle is not just about drug prohibition, a crime the Treasury Department would have to invent if it didn't already exist. The real struggle is about the future of tax compliance, and it has you in its sights. A famous Revolutionary War era pamphleteer, writing under the pseudonym "Brutus", perhaps said it best 200 years ago when he wrote - "The national government through its taxing power will introduce itself into every corner of the city and country. It will take cognizance of the professional man in his office or his study; it will watch the merchant in his store; it will follow the mechanic to his shop and his work, and will haunt him in his family and his bed; it will be the constant companion to the industrious farmer in his labour; it will penetrate into the most obscure cottage; and finally it will light upon the head of every person in the United States. To all these different classes of people and in all these circumstances on which it will attend them, the language in which it will address them will be GIVE! GIVE!" What Brutus didn't know and what the cypherpunks foresee is that one day strong encryption will make it impossible to spy on our activities in cyberspace. Heightened conflict is inevitable. Expect the rhetoric to get a lot hotter as the government spinmeisters labor to keep us focused on public enemies while frantically trying to keep its hand in every citizens pocket and its eyes on every bankbook. # # # COPYRIGHT CMP PUBLICATIONS 1995 Bill Frezza is president at Wireless Computing Associates and co-founder of the online forum DigitaLiberty. The opinions expresses are his own. Frezza can be reached at frezza(a)interramp.com. ------------------------------------ | Wireless Computing Associates, Inc. | 704 Stoney Hill Rd., Suite 155 | Yardley, PA 19067 | ph 215-321-0929, fax 215-321-0490 | urgent Email: frezza(a)radiomail.net | bulk Email: frezza(a)interramp.com ------------------------------------

1 0

Re: Need Mail-to-News gates
by Rich Salz 17 Dec '03

17 Dec '03

>Until I can write a script to pull all the newsgroups from the active >file and place aliases for them in sendmail, the only way to use it is The "gag" program that comes with my news/mail gateway software known as newsgate can do this automatically. email to rsalz(a)nntp.com for a copy.

1 0

From Bill Frezza: Electronic Warfare
by Ray Arachelian 17 Dec '03

17 Dec '03

---------- Forwarded message ---------- Date: Sun, 29 Oct 1995 11:33:54 -0500 From: Bill Frezza <frezza(a)interramp.com> To: sunder(a)escape.com Subject: Can you post this? Ray, If you feel it is apporpriate, can you post the attached column to cypherpunks? Since I am not a regular subscriber (I can't keep up with the traffic) I thought it would be best to pass it by you first. Thanks, Bill Frezza ------------------------------------------------------------------------------ To: Cypherpunks(a)toad.com Subject: Electronic Warfare From: Bill Frezza (frezza(a)interramp.com) Dear cyhperpunks, Attached is a column that will appear on the op-ed page of tomorrow's (10/30) Communications Week that was stimulated largely by a report filed here by one of your members. I thought you would find it interesting and thought provoking. I would like to thank and acknowledge whoever it was that filed that report as well as encourage you all to keep me informed about related political developments. (I just don't have the bandwidth to follow the cyhperpunks list in its entirty.) It is my hope to bring the important issues you raise here to the attention of the industry and the general public. Regards, Bill Frezza Communications Week ELECTRONIC WARFARE WAGES ON - AND YOU'RE THE TARGET Although the flap over the Clinton administration's attempt to promote escrowed-key encryption systems like Clipper has temporarily faded, the war on electronic privacy continues. As proceedings at the Fourth International Conference on Money Laundering, Forfeiture, Asset Recovery, Offshore Investments, the Pacific Rim, and International Financial Crimes reveal, there has been no let up in our government's efforts to blockade the cyber-frontier. No, you won't learn much from the Wall Street Journal or the New York Times, written by journalist-generalists who have no clue about where this technology is heading. The Feds have become so skilled at manipulating the Old Media that stories about electronic privacy invariably center on the latest drug kingpin, pedophile, or domestic terrorist. Attacking these universally abhorred enemies of the people not only makes for good headlines but keeps privacy advocates off balance as they are forced to defend abstract rights using loathsome examples. But if you tune in to the Cypherpunks mailing list (majordomo(a)toad.com) you can get some excellent first hand reports from the front. In the relatively short period since the passage of the Bank Secrecy Act, which, among other things, obliges banks to file Suspicious Activity Reports on its customers, banks have become virtual deputies in the treasury department's war on uncontrolled financial transactions. And this war is increasingly spilling into cyberspace. The conference underscored the fact that, paradoxically, we are heading not toward more specific and well defined transaction monitoring regulations, but less. How so? The problem with making regulations precise is that what software algorithms can define, other algorithms can evade. Instead, regulation by "raised eyebrow" is becoming the norm. Federal bank examiners have been given significant latitude to invoke draconian penalties against uncooperative banks. Because bank officers have few due-process protections under this regime, it is no surprise that most of them have become sniveling toadies. The objective is to insure that banks "voluntarily" introduce even more aggressive, unpredictable, and intrusive monitoring than the government would ever dare mandate. And to make sure nothing slips through the cracks, human surveillance will be supplemented with artificial-intelligence agents that can perform pattern analysis on the aggregate flow of electronic transactions, flagging anything remotely suspicious. George Orwell would be impressed. Lest you think that all of this is motivated solely by the drug war, a visit to the Treasury Department's Financial Crimes Enforcement Network (FinCEN) homepage (http://www.ustreas.gov/treasury/bureaus/fincen/facts.html) should open your eyes. This battle is not just about drug prohibition, a crime the Treasury Department would have to invent if it didn't already exist. The real struggle is about the future of tax compliance, and it has you in its sights. A famous Revolutionary War era pamphleteer, writing under the pseudonym "Brutus", perhaps said it best 200 years ago when he wrote - "The national government through its taxing power will introduce itself into every corner of the city and country. It will take cognizance of the professional man in his office or his study; it will watch the merchant in his store; it will follow the mechanic to his shop and his work, and will haunt him in his family and his bed; it will be the constant companion to the industrious farmer in his labour; it will penetrate into the most obscure cottage; and finally it will light upon the head of every person in the United States. To all these different classes of people and in all these circumstances on which it will attend them, the language in which it will address them will be GIVE! GIVE!" What Brutus didn't know and what the cypherpunks foresee is that one day strong encryption will make it impossible to spy on our activities in cyberspace. Heightened conflict is inevitable. Expect the rhetoric to get a lot hotter as the government spinmeisters labor to keep us focused on public enemies while frantically trying to keep its hand in every citizens pocket and its eyes on every bankbook. # # # COPYRIGHT CMP PUBLICATIONS 1995 Bill Frezza is president at Wireless Computing Associates and co-founder of the online forum DigitaLiberty. The opinions expresses are his own. Frezza can be reached at frezza(a)interramp.com. ------------------------------------ | Wireless Computing Associates, Inc. | 704 Stoney Hill Rd., Suite 155 | Yardley, PA 19067 | ph 215-321-0929, fax 215-321-0490 | urgent Email: frezza(a)radiomail.net | bulk Email: frezza(a)interramp.com ------------------------------------

1 0

Re: Keyed-MD5, ITAR, and HTTP-NG
by Rich Salz 17 Dec '03

17 Dec '03

>GSS is often brought up on occasions like this. I have never seen an architectural >overview of what it is trying to achieve for me or how. When I am provided >with a clear definition of what it is I hope to arrive at a clear explanation >of why I'm not using it. Unfortunately the RFC process strips the rationale >part out of the specs. You don't understand it, but once you do you can explain why you're not using it? Do you really mean that, or am I misunderstanding? Many of the GSSAPI principals are in the Boston area: John Linn at OpenVision in Cambridge, John Wray at Digital in Littleton, Ted T'so and Marc Horowitz at MIT, etc. If you would like to have a discussion, face-to-face or phone, let me know and I will try to work something out. /r$

1 0

Re: Important Digital Cash Question...
by rah＠shipwright.com 17 Dec '03

17 Dec '03

>I think that the bankers name should be Ethel however. > > Phill Wait, wait! I have another one. I call digital cash bankers "underwriters", because they're basically underwriting digital certificates, like an underwriter in the capital markets does. So, we need a "U" name... Cheers, Bob Hettinga ----------------- Robert Hettinga (rah(a)shipwright.com) Shipwright Development Corporation, 44 Farquhar Street, Boston, MA 02131 USA (617) 323-7923 "Reality is not optional." --Thomas Sowell >>>>Phree Phil: Email: zldf(a)clark.net http://www.netresponse.com/zldf <<<<<

3 2

Re: Keyed-MD5, ITAR, and HTTP-NG
by Rich Salz 17 Dec '03

17 Dec '03

How are you going to handle mechanism negotiation?

3 2

Re: /dev/random for FreeBSD [was: Re: /dev/random for Linux]
by tomw＠orac.engr.sgi.com 17 Dec '03

17 Dec '03

In article <DHAMpE.34y(a)sgi.sgi.com>, "Theodore Ts'o" <tytso(a)MIT.EDU> writes: > Date: Mon, 30 Oct 1995 21:59:14 -0500 > From: "Josh M. Osborne" <stripes(a)va.pubnix.com> > When /dev/random doesn't have "enough" enthropy left does reading > from it return an error, or block? I would strongly suggest > blocking, as the non-blocking behavur is not really all that useful. > It acts like many character devices and named pipes in that if there is > no entropy available at all, it blocks. If there is some entropy > available, but not enough, it returns what is available. (A subsequent > read will then block, since no entropy will then be available.) > Actually, what's currently in Linux doesn't work precisely like this, > but it will soon. After talking a number of people on both sides of the > block vs. non-blocking camp, this seemed to be a suitable compromise. > At least one Major Workstation Vendor is planning on using this behavior > for their /dev/random, to appear in a future OS release. If we all can > standardize on this behavior, it'll make application writer's jobs that > much easier. One problem with this scheme is that if multiple processes have /dev/random open you can block unexpectedly. If I try to avoid blocking by first checking if entropy is available there's a race condition if another process reads from the device. Is there another way to avoid blocking? -- Sure we spend a lot of money, but that doesn't mean | Tom Weinstein we *do* anything. -- Washington DC motto | tomw(a)engr.sgi.com

3 2

There is still no perfectly anonymous currency
by Bryce 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- It occurs to me that even in an on-line-cleared system, that a collusion of Ursula the Underwriter and Bob the Payer can identify Alice the Payee by traffic analysis based on time contraints. Alice has to turn in the coin that Bob gave her in order to get it on-line- cleared *before* she can close the deal with Bob assuming that she believes there is a chance Bob's coin is bad (pre-spent). So Bob and Ursula can do some simple traffic-analysis-style coin-watching over the course of several transactions between Bob and Alice. This could become infeasible for Bob and Ursula in the case that there are very many such transactions going on at the same time and Alice (and some of the other payees) prudently add a traffic-analysis- foiling delay between acceptance of Bob's coin and turning it over to the bank, and between receiving confirmation from the bank and letting Bob know that the bank said "OK". (Of course all this, and in fact all conversations on this subject, presume the existence and proper usage of identity-protecting communication protocols between Alice and Ursula and between Alice and Bob.) Now in some applications it might be a problem for Alice to add these delays. (She might need to complete a great many transactions in a limited amount of time.) In this case Alice will have to choose between efficiency and identity-protection. Her tactic will further be hampered by the fact that only Ursula knows how many similar transactions are going on at any given time. Alice will have to guess. In sum, I have still not seen a proposal for an electronic currency scheme which ensures unconditional identity-protection for both payer and payee. On the other hand, if a bank allows pseudonymous accounts, or if coin-re-paying systems can be implemented, then some lesser degree of identity-protection is still attainable. On the third hand, if a bank allows instant, cheap, anonymous accounts or, equivalently, if the bank issues coins in return (or as Tony Eng has suggested, issues "deposit-vouchers" in return) instead of accessing the payee's account, then ensuring unconditional identity-protection for both parties is easy under several protocols, including the Chaumian Ecash protocol. (That is: auto-coin-laundering via an instant, one-use anonymous account that you control or via a new coin or a deposit voucher whose blinding factors you chose.) Bryce signatures follow "To strive, to seek, to find and not to yield." <a href="http://ugrad-www.cs.colorado.edu/~wilcoxb/Niche.html"> bryce(a)colorado.edu </a> -----BEGIN PGP SIGNATURE----- Version: 2.6.2 Comment: Auto-signed under Unix with 'BAP' Easy-PGP v1.01 iQCVAwUBMJbM0vWZSllhfG25AQG1MgP/UhbGC2Afih+/hrQcjvc4lOQBAWXQ8lDL HpMRI1002odcEQ3LX/Dy2H7+LwsnMQweVtQU3Q9Q8cVWOeSXSReoKAZinbjAvvfH Hf7xKZcmgX4xBhRmOeLxH2/noGL5iRkjONuMfQUFE85Rkc3ilh7IQr+UC8sGLUY1 2p/tXgsFJbM= =RzYl -----END PGP SIGNATURE-----

1 0