December 2003 - cypherpunks-legacy

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

Re: ecash remailer
by Bill Stewart 17 Dec '03

17 Dec '03

Sameer and Hal both suggested ecash-laundering methods to provide payee anonymity using methods like this: >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. As implemented here, Ed is strictly in the money-laundering businesss, and can expect a visit from the Feds as soon as they can break through the chain of digital mixes and crypto he uses to operate alt.money.laundry, or follow the money when _he_ tries to deposit it. On the other hand, he could operate a strictly legitimate business, selling financial assets such as bearer bonds or low-commission lottery tickets, or converting funds between different e-banks, or simply offering anonymous bank accounts with currencies in multiple denominations - Bob can set up an account with Ed's Eurocurrency Exchange in the name "Public Key nnnnn", deposit his $15, and withdraw US$14.95 worth of Yen or Deutschmarks or Kongbucks. Aside from Bob's need to trust Ed, and his need to trust Alice not to double-spend (since laundering used bills is much harder than laundering marked bills) it first looked to me like Ed has a serious risk that he'd be nabbed by the Feds as soon as he tried to spend the bills, so he has to trust Bob not to be spending ransom money or pharmaceutical profits. But as near as I can tell, _any_ merchant has that risk, because there's no way for Ed to distinguish between cash that Bob withdrew himself and cash that Bob got from someone else. Does this mean that anybody who sells goods to anonymous clients is automatically a money-launderer? If so, either the bogus money-laundering laws have to go (yay!) or laws against selling to anonymous clients will get written (boo!) or selective enforcement and entrapment will become increasingly popular, leading merchants to refuse to do anonymous business just to defend themselves against extortionists\\\\\\\\\\\\legitimate needs of law enforcement? #--- # Thanks; Bill # Bill Stewart, Freelance Information Architect, stewarts(a)ix.netcom.com # Phone +1-510-247-0664 Pager/Voicemail 1-408-787-1281 #---

2 1

W3 Self-Regulation?
by Dave Del Torto 17 Dec '03

17 Dec '03

[Where's Tipper when you need her? Answer:] FOR IMMEDIATE RELEASE Contact: Ron Warris, President, Internet Filtering Systems, Inc. phone: 1-403-258-5804, email: warrisr(a)colt.t8000.com Web: www.tenagra.com/ifsi DEMOCRATIC WORLD-WIDE WEB SELF-REGULATION ANNOUNCED CALGARY, ALBERTA, CANADA -- October 30, 1995 -- Internet Filtering Systems, Inc. (IFSI) today announced Net Shepherd, the first product designed to democratically rate and filter World Wide Web sites and selectively supervise access. Net Shepherd is the first PICS-compliant rating and filtering solution. Under the auspices of The World Wide Web Consortium, PICS (Platform for Internet Content Selection) is a cross-industry working group whose goal is to facilitate the development of technologies to give users control over the kinds of material to which they and their children have access. According to Ron Warris, president of IFSI, "There are a number of companies offering filtering solutions. What is really needed is a rating solution. How do you go about reviewing and rating 8.5 million volatile documents on the Internet? Our approach will allow the people who surf the Internet to be the people who rate the Internet. With Net Shepherd, parents, educators and other concerned organizations will be able to voluntarily participate in the rating process. Mr. Warris continues, "Net Shepherd will also provide parents with the ability to selectively filter documents viewed by their children. Parents can choose from a variety of rating databases that represent the accumulated ratings from others who hold similar views and philosophies. Organizations that wish to create rating databases for their subscribers will also be able to use Net Shepherd. You'll be able to subscribe to the Good Housekeeping database or the Lutheran Church database or the ACLU database. Take your pick. "The Internet has always been self-regulating and special-interest-group oriented. Now the World Wide Web can be as well." IFSI's mission is to become the preferred and premier provider of Internet rating systems and services for individual consumers, concerned groups and associations, as well as other filter software developers. A World-Wide Web site currently contains basic information about IFSI, and will evolve over the coming weeks into an extensive resource for those interested in Internet content filtering. It is located at URL <http://www.tenagra.com/ifsi/> >From the Web page: Internet Filtering Systems, Inc. is the developer of Net Shepherd, the first product designed to democratically rate and filter World Wide Web sites and selectively supervise access. The Internet has always been self-regulating and special-interest-group oriented. Now the World Wide Web can be as well. Net Shepherd is the first PICS-compliant rating and filtering solution. Under the auspices of The World Wide Web Consortium, PICS (Platform for Internet Content Selection) is a cross-industry working group whose goal is to facilitate the development of technologies to give users control over the kinds of material to which they and their children have access. Net Shepherd allows the people who surf the Internet to be the people who rate the Internet. With Net Shepherd, parents, educators and other concerned organizations will be able to voluntarily participate in the rating process. Net Shepherd will also provide parents with the ability to selectively filter documents viewed by their children. Parents can choose from a variety of rating databases that represent the accumulated ratings from others who hold similar views and philosophies. Organizations that wish to create rating databases for their subscribers will also be able to use Net Shepherd. IFSI's mission is to become the preferred and premier provider of Internet rating systems and services for individual consumers, concerned groups and associations, as well as other filter software developers. [cf. PICS (Platform for Internet Content Selection) at <http://www.w3.org/pub/WWW/PICS/>]

3 2

Re: /dev/random for FreeBSD [was: Re: /dev/random for Linux]
by Mark Murray 17 Dec '03

17 Dec '03

> Something I didn't mention earlier; we felt that letting the unwashed > masses read /dev/*random was not a good idea, as they could deplete > the pool of entropy all to easily for attack purposes. > > That should be a system administration issue. If someone wants to make > /dev/random readable only by root at their site, that's their business. > I don't see any point in trying to enforce that in the kernel code. Is not in the kernel, this is just the permissions on /dev/*random. > I don't agree that restricting read access is useful. First of all, if > the pool of entropy is depleted, someone who tries to obtain entropy by > reading /dev/random will know that they didn't get enough entropy. So > assuming a program that actually checks return values from system calls, > this is at worse a denial of service attack, and there are much easier > ways of performing those srots of attacks: "while (1) fork()", for > example. Hmm. Lemme think about this... > Secondly, making /dev/random only readable by "privileged programs" > means that people won't be able to compile their own version of PGP that > can take advantage of the random number generator. Instead, they would > have to use a setuid version of PGP, and I'm quite sure PGP wasn't > written such that it would be safe to turn on its setuid bit. How about SetGID? We were going for 660 root.kmem. > Finally, even if you did have trustworthy applications which you could > setuid and only allow those programs to have access to /dev/random, > someone who repeatedly ran those applications could still end up > depleteing the pool of entropy. > > So in the general case I would advise that /dev/random be left world > readable, since you *do* want general user programs to have access to > high quality random numbers. Ponder... I'll put this forward. > Again, /dev/random can be set to whatever permissions the system > administrator wants. Secondly, writing to /dev/random merely adds > randomness to the pool, via the mixing algorithm. It won't actually > permit people to *set* the state of the pool, and assuming that the > state of the pool is not known before the write operation, writing to it > won't allow the user to know what the state is after the write > operation. What happens if some attacker does: for (;;) { write_to_devrandom(NULL); check_to_see_if_state_is_crackable(); } ? "Gut feel" suggests to me that large ammounts of "predicted" input might be worse than the normal sort of system noise you have been using. > And, for race condition reasons, something which I need to implement > soon is an ioctl(), usuable only by root, that simultaneously updates > the entropy estimate *and* submits data to be mixed into the pool. (Why > this is necessary should be obvious after a few minutes thought.) Clue me in - I'm not quite with you? :-) > Are you sure about this? The stochastisity if this would be pretty > hefty. Not only would our attacker have to get the _time_ that the > interrupt occurred (if it interrupted our machine), he would then have > to process in brute-force mode all possible times in his error range. > What is more, more interrupts are coming in... > > I didn't say that it would be trivial for an attacker to do this, but > it's certainly *doable*. Some of the network traffic analyzers that > have been made available (I think Sandia National Labs has one that does > this), records down to millisecond accuracy when a packet was sniffed on > the network. Is this millisecond accuracy quantifiable in terms of bits of entropy? if so, the ethernet is surely safe? > For this reason, people shouldn't really trust initializing PGP's random > number generator over a network connection, since it is possible for an > adversary to obtain very high quality timings of when your telnet or > rlogin packets appeared on the network, and hence be able to guess > (within some error range) what the interkeyboard timings which PGP used > to initialize its random number generator. > > The adversary might have to try a large number of possibilities, but if > the number of possibilities is less than a brute-force search, you > definitely have a weakness --- a fact which Netscape learned to its > embarassment a few weeks ago. Again, if you can quantify the number of possibilities into bits of entropy, your code is good. Depending on current technology, this may have to change. M -- Mark Murray 46 Harvey Rd, Claremont, Cape Town 7700, South Africa +27 21 61-3768 GMT+0200 Finger mark(a)grumble.grondar.za for PGP key

5 5

censored? corrected
by anonymous-remailer＠shell.portal.com 17 Dec '03

17 Dec '03

NOTE: More than 8 hours have passed since I sent this text in plaintext directly to Cypherpunks without its being posted, so in this attempt I am sending it encrypted through ALUMNI remailer. - Gary Jeffers gjeffers(a)socketis.net INFO BLACKOUT From THE SPOTLIGHT newspaper's TECHNOLOGY & LIBERTY column by Clark Matthews - Nov. 06, 1995 issue. Powerful national security insiders have established effective control over the entrance gateways to Internet. Disturbing signs are now emerging that the "information superhighway" has been targeted for systematic sur- veillance and political dossier-building on Americans' opinions. This ominous news came in the first of a series of articles by investi- gative journalist Steven Pizzo in WEB REVIEW, an online magazine of cyber- culture and politics (http://gnn.com/wr/) published by Songline Studios of San Francisco. Pizzo is the author of INSIDE JOB, a groundbreaking expose' on the massive fraud and theft of insured deposits in 1980s savings and loan debacle. According to Pizzo, control of Internet "domain name registration" has passed into private hands-with the potential for serious mischief or worse. "Domain names" are the odd looking identifying names that are as- signed to individual computer systems that compose the Internet (logoplex. com, for example). Through a complex chain of licensing arrangements and corporate acqui- sitions detailed in Pizzo's article, this crucial control over Internet domain names has passed from the non-profit National Science Foundation to Network Solutions, Inc. (NSI) of Herndon, Virginia. Last May, amid growing public disbelief of Establishment media reports about the Oklahoma City bombing provocation, NSI was purchased by Scientific Applications Interna- tional Corporation (SAIC) of San Diego. SAIC is a $2 billion defense and FBI contractor with a board of direc- tors that reads like a Who's Who of the intelligence community. Board members include Admiral Bobby Ray Inman, the former director of the Na- tional Security Agency (NSA) and deputy director of the CIA; Melvin Laird, defense secretary under Richard Nixon; Donald Hicks, former head of re- search & development for the Pentagon; Donald Kerr, former head of the Los Alamos National Laboratory; and Gen. Maxwell Thurman (ret.), the commander of the U.S. invasion of Panama. Former members of SAIC's board include Robert Gates, the former CIA director under George Bush; current CIA director John Deutch; Anita Jones, Deutch's former Pentagon procurement officer, and William Perry, the pre- sent secretary of defense. The corporation also has a legion of computer network specialists and an entire division of computer consultants. SAIC currently holds contracts for re-engineering the Pentagon's information systems, automating the FBI'S computerized fingerprint identification system, and building a na- tional criminal history infomation system. The Internet is a marvel of computer software technology. It was de- signed to survive a nuclear attack on the United States-like the Post Office, it's literally smart enough to find a way to get the mail through, even if most of the network is missing. But control of Internet domain name registration means the ability to remove troublesome-or outspoken-computer systems from the network. Po- tentially, this control also confers the power to insinuate "phantom" domains into the network-for surveillance purposes, for example-or for real-time, automatic censorship. Furthermore, anecdotal evidence gathered by this author suggests that actual "truth control" is taking place on the 'net now. E-mail messages with controversial contents-including the details of the SAIC takover of domain names-have consistently disappeared as they travel across the net- work. News items concerning the Vincent Foster "suicide" investigation and allegations of NSA bank spying through compromised Inslaw software are being quickly and automatically canceled. And the cancellations are not by by their authors. CRACKDOWN With domain names under the control of secret government insiders, it is even theoretically possible that large parts of the Internet could be SHUT DOWN AND SILENCED at critical times. This could be accomplished by suddenly altering domain name registrations or interposing compromised "domains" at crucial points. These compromised systems could serve as "black holes" at critical times, stopping e-mail and important news from reaching the world-or the rest of the country. Exercises in "turning the Internet off" have already taken place in Taiwan and Hong Kong. In Taiwan, the 'net was successfully shut down. All network traffic-including news, opinions and e-mail sent by computer users-was successfully "bottled up" on the island and prevented from reaching the world. In Hong Kong, the Internet wasn't quite strangled, but the British authorities who control that colony managed to throttle free electronic speech with the rest of the world until everything was bottlenecked into a few little-known satellite links. These are alarming precedents and sure signs that powerful, shadowy forces are preparing to chop at the very roots of America's new Liberty Tree. The secretive people on the board of directors of SAIC are intell- igence professsionals skilled at manufacturing events-and then manufact- uring public opinion and consent by controlling the truth. Will Internet disinformation, censorship or "shutdowns" signal the next American crisis?

9 12

S/KEY available for HP48 handheld calc
by Laurent Demailly 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- Steve VanDevender (<stevev(a)greylady.uoregon.edu>) made available (GNU GPL) an S/KEY implementation for the nice HP hand held calc, It works very nice with both MD4 and MD5 based system (I personnaly tested with my MD4 based logdaemon-4.9, the author recommend OPIE's one) I've put his stuff on my anonymous ftp, you can fetch the stuff starting on ftp://ftp.box.eu.org/hp48/skey/ (ftp.box.eu.org=hplyot.obspm.fr=145.238.44.5) the executable I got from usenet has the following MD5 digest: 1b2613383708d4825f5842ed3e630d40 skey I hear you can get an hp48 for $30 in the Us (I paid my hp48g US$230 when it came out in France two years ago), So no more excuse of clear passwd over the net ! [nor to sell 'smart cards' mega bucks!] ps: Who write PGP for hp48 now ;-) ? [or maybe more seriously some skey hooks to it ?] dl - -- Laurent Demailly * http://hplyot.obspm.fr/~dl/ * Linux|PGP|Gnu|Tcl|... Freedom Prime#1: cent cinq mille cent cinq milliards cent cinq mille cent soixante sept Panama South Africa DST domestic disruption counter-intelligence cracking Legion of Doom -----BEGIN PGP SIGNATURE----- Version: 2.6.2i Comment: Processed by Mailcrypt 3.3, an Emacs/PGP interface iQCVAgUBMJzlz3k52/beodHxAQEAGQP/XcX3mOw8YIVKe3kEuUkRb6wjB7JAvTi3 t/aQNAT/LQR4ZCx954HbqS231P3qxuz2Hc88xs7HAfbzk91C6VQ9J/r1+C7yBMiR Jlk19lnWny8yHlkwm8KzF1TvqnZ6LvnGgLoiq5ExJIGJpRyJUf912LZf8N06tyFG IJs8ZcN8/Kk= =6RT6 -----END PGP SIGNATURE-----

1 0

Re: Exporting software doesn't mean exporting (was: Re: lp ?)
by Mark Murray 17 Dec '03

17 Dec '03

> > "Peter D. Junger" writes: > > : Where the hell did you get that idea? [that the ITAR applies to > > : foreigners abroad]. > > > > >From Section 120.17 of the ITAR which provides: > > > > _Export_ means: > > > > . . . . > > > > (4) Disclosing (including oral or visual disclosure) or transfering > > technical data to a foreign person, whether in the United States or > > abroad . . . . Hmm. Not only is this law unenforceable, it is unenforced. Anyone, non-US or otherwise can buy crypto books - you just can't get the code on floppy. Bruce Schneier went through this procedure when he CJ'ed "Applied Cryptography". \begin{lighter_note} The illegal bit about (for instance) the munitions T-shirt is that it has a bar code. _This_ makes it illegal for export, because not only is it machine washable, it is machine readable. \end{lighter_note} Academic exchange of mathematical knowledge has never been under scrutiny. "Technical data" will have to be interpreted to mean somethiing different, like details of the inner workings of militart encryption equipment and the like. M -- Mark Murray 46 Harvey Rd, Claremont, Cape Town 7700, South Africa +27 21 61-3768 GMT+0200 Finger mark(a)grumble.grondar.za for PGP key

2 1