December 2003 - cypherpunks-legacy

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

Re: /dev/random for FreeBSD [was: Re: /dev/random for Linux]
by frantz＠netcom.com 17 Dec '03

17 Dec '03

At 17:19 10/31/95 -0600, Martin Diehl wrote: > 2. When doing time domain measurements (Hewlett Packard had some good > application notes on this subject), you must consider base clock > jitter. Ill try to illustrate with a diagram: > > actual event: V V > clock granularity: /...../...../...../...../...../...../ > > the problem is that no matter how small the basic clock unit is > (symbolized by "/", above), you can't be sure how much of that unit > has passed when the event (symbolized by "V", above) occurs. For > example, on the original IBM PC, clock interrupts occurred about 18.2 > times per second (55ms interval). In that architecture, you can't > time an event and have an uncertainty of less than 2 times 55ms Ah, but there is a neat hack that works well if you can dedicate the whole processor to doing the timing. This works with systems that do not have preemptive multi-tasking. (Getting it to work with preemptive multi-tasking is a harder excersize). Credit where credit is due, I first saw this technique used, probably in 1968, on the IBM/360 (60HZ clock) with a pair of programs called PACER and RATER. Monitor the clock location. (It doesn't matter whether it is incrmented by hardware or software.) Run a timing loop from when it changes until it changes again and count the number of times through the loop. Then use the same timing loop and count how many times the loop runs from a clock tick to the event of interest (or from the event of interest to the next clock tick). Use the ratio of the two counts to interprolate between the times you can get from the clock. You have used the processor's instruction rate to synthesize a better clock. Bill

1 0

Keyed-MD5, and HTTP-NG
by baldwin 17 Dec '03

17 Dec '03

Simon, There are a few different ways to add key material to MD5 to make it suitable as a shared-secret authenticator function. Some of these are less resistant to attacks than others. For example, the keyed MD5 mechanism that is part of the current IPsec specifications can be attacked using 2**60 chosen messages. Fortunately, the IPsec specs also require that the shared MD5 key be changed every 2**32 messages, so this attack is unlikely to succeed. Specifically, IPsec uses MD5 as follows: X = MD5(key | keypad | Message), where "|" means concatenation and the "keypad" pads out the key to 512 bits. Basically, this function is the same as standard MD5 with a different initialization vector for the compression operation on the first block of the message. RSA Labs recommends that a people use an authenticator like X = MD5(key1, MD5(key2, Message)). This resists the chosen plaintext attacks that were published at the crypto conference in Spring 1995. There are also some very fast MAC algorithms being proposed these days. As Phill Hallam mentioned, you may want to look at the work of Phil Rogaway. At a minimum, make sure that your standard allows people to migrate from a current solution based on MD5 to a future solution based on new functions. However, I would be relunctant to require new functions until they have had a chance to be tested by the cryptographic research community. --Bob Baldwin

3 2

Digicash on Scientific American
by Aleph One 17 Dec '03

17 Dec '03

Another thing before I go to bed. On the November issue of Scientific American the Essay column writen by Anne Eisenberg is titled "Doing Busioness on the Net". Its short (one page), but metions PK crypto, touches upon the dangers that online transcations pose to privacy, and talks a bit about ecash. Sadly there is no mention of ITAR *sight* Aleph One / aleph1(a)dfw.net http://underground.org/ KeyID 1024/948FD6B5 Fingerprint EE C9 E8 AA CB AF 09 61 8C 39 EA 47 A8 6A B8 01

2 1

Please send cash
by fc＠all.net 17 Dec '03

17 Dec '03

I just picked this up from the Risks forum: > Date: Mon, 30 Oct 1995 16:14:59 -0500 > From: Drew Dean <ddean(a)CS.Princeton.EDU> > Subject: HotJava 1.0 alpha 3 security issues > > We have found several security problems in the 1.0 alpha 3 release of > HotJava from Sun Microsystems. The two most important problems are that > HotJava does not enforce the stated limits on where an applet can connect to > (an applet can talk to any place with which you have IP-level connectivity), > and HotJava is vulnerable to a man-in-the-middle attack, where someone can > watch your web-surfing, both seeing your requests, and the content that you > receive. Two of the Java attacks I outlined in this forum and got abuse for. > While HotJava prevents applets from actively opening connections that > violate the user-selected security policy, it allows an applet to accept > connections from anywhere. At this point, an applet only has to use any one > of a number of channels to communicate where it is, and have the remote end > do the active open. > > HotJava also allows an applet to set the proxy servers that the browser > uses. This opens up a huge hole for anyone concerned about the privacy of > their web surfing. Attacks 31-49 work here. > Please note that these bugs are specific to the 1.0 alpha 3 release, and are > _not_ bugs in the Java language itself, nor do they apply to Netscape 2.0 > beta 1J, which doesn't permit network connections. We have notified Sun of > these problems, and are presently writing a paper on these and other issues. > We will make more information available on our Web page after we hear back > from Sun. Drat - Sun doesn't offer awards. > > http://www.cs.princeton.edu/~ddean/java/ > > Drew Dean Dan Wallach > ddean(a)cs.princeton.edu dwallach(a)cs.princeton.edu Inquiring minds want to know. -- -> See: Info-Sec Heaven at URL http://all.net Management Analytics - 216-686-0090 - PO Box 1480, Hudson, OH 44236

2 2