- cypherpunks-legacy - lists.cpunks.org

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

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

Rivest on the Design of RC4
by baldwin 17 Dec '03

17 Dec '03

Professor Ron Rivest will be presenting a talk titled "The Design of RC4" at the RSA Data Security Conference in San Francisco (January 17 to 19). It should be interesting. --Bob

2 1

SCO Unix Crontab Problems-Need Help
by ncra＠ix.netcom.com 17 Dec '03

17 Dec '03

I have a bourne shell that I need to execute in SCO unix 4.0 from a crontab. The script is a communications upload using ecu. The script runs just fine in terminal mode, but when it is executed in cron, it is not able to gain access of the modem for some reason. Q: Is there something special that needs to be added to the crontab line in order to allow for tty access. Please let me know if you have any suggestions.

1 0

Digicash tagged with payee?
by Hal 17 Dec '03

17 Dec '03

I have heard it claimed that when you make a payment with Digicash ecash, the identity of the payee is encoded or embedded into the cash somehow. This is an anti-theft measure (among other things, perhaps). The bank checks that the embedded identity in deposited cash matches the account name which is doing the deposit. My question is, how could this be done? How can the payor, at payment time, without communicating with the bank, embed a payee name irreversibly into the cash so that a thief cannot strip it out and replace it with his own name? Is it perhaps a matter of encrypting the cash with the public key of the payee? If so, how does the payor get that? Is it provided by the payee during the TCP connection? Is it authenticated with a certificate, perhaps signed by some Digicash root key? Off-list there has been some discussion about the role of certificates in ecash, and in cash systems in general. It would be interesting to know if this anti-theft provision of Digicash is actually provided by means of a certificate.

1 0

Re: Please send cash
by todd＠lgt.com 17 Dec '03

17 Dec '03

Yo Fred, nobody said you wer not right on the money, just that these issues clearly have fixes and are part and parcel to a pre-adolesencent product, not a mature one. Yes, you get two points for posting the bug report, but lose one for soap-boxing about the woes of the product in general... Keep up the good work, just drop the proslitizing and we all wouldn't mind hearing your rap. BTW - If your or your friends are up for a game of speed-chess... I'm willing, I used to be *rated* until I dropped off the circuit a few years ago... Winged Benoni, Classical Ruy, or maybe an Accellerated Dragon (for those who play the black)... I won't even charge you the nominal 5$ fee... >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 Regards, T. S. Glassey Chief Technologist Looking Glass Technologies todd(a)lgt.com (415) 324-4318 -----BEGIN PGP SIGNATURE----- Version: 2.6 iQB1AwUBMFu5E6gNRnWhagU5AQHI+gL+Mwpcd3lAWd8FF06qcG6rnLhIYveHW71a XC7xh1T0uu8qnYX31yMp17OG28jWpKUbWec1IM9/eXOi+gInA7rKICWczV8zo9Z0 0puxjRRN7yO4KfRb3cPpk+r0p6pDg01Y =bTYb -----END PGP SIGNATURE-----

1 0

Re: From Bill Frezza: Electronic Warfare
by anon-remailer＠utopia.hacktic.nl 17 Dec '03

17 Dec '03

On Tue, 31 Oct 1995, Bill Frezza <frezza(a)interramp.com> wrote: > 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 > Cypherpunks mailing list (majordomo(a)toad.com) you can get some excellent list address is cypherpunks(a)toad.com list manager is majordomo(a)toad.com sending list mail to majordomo will not work > 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. the entire issue is not tied to money the gummint is not just looking for more money can't anyone from the media get it right better story than w$j can make though congratulations you're more clueful than the average media stooge

2 1

"Dr." Fred
by anonymous-remailer＠shell.portal.com 17 Dec '03

17 Dec '03

The most charitable explanation for "Dr." Fred is that he's degenerated into the professional equivalent of those pathetic aging former chess masters who try to eek out a subsistence living by charging five bucks a game. People often play with them out of sympathy, or for the novelty of having lost to a past great. It's part of the chess culture, and it's basically harmless and sort of quaint. The difference, of course, is that its almost impossible to have sympathy for Dr. Fred. His hussle is for a hell of a lot more than subsistence. He was also never actually a master of his field, a fact that becomes increasingly obvious as our exposure to him goes on. Now he's reduced himself to trying to collect someone else's winnings.

1 0

No Subject
by anon-remailer＠utopia.hacktic.nl 17 Dec '03

17 Dec '03

On Tue, 31 Oct 1995, Anonymous wrote: > Wall Street Journal, October 30, 1995, p. B3. > Brad Meinert, senior analyst at research firm Input, says the > tremendous growth of the World Wide Web, a graphics Internet > interface, "is putting increased capacity demands for greater > bandwidth on the Internet infrastructure." I see our media friends are just as clueful as ever .... graphics Internet interface ?? Thats almost as bad as saying "Come visit our Internet Site" when they mean Web site !!

1 0