December 2003 - cypherpunks-legacy

Re: CJR returned to sender
by James A. Donald 17 Dec '03

17 Dec '03

At 10:16 PM 10/30/95 -0800, Jeff Weinstein wrote: > It [CJR application for T shirts] will force the bureaucrats > to make a decision, You cannot force bureaucrats to make a decision. They will act if it suits their purpose, and otherwise they will not act. Basic of principle of strategy in Go: If you give the other guy choices, you will lose. That is why go players always play asymmetrically if the stones are symmetric. --------------------------------------------------------------------- | We have the right to defend ourselves | http://www.jim.com/jamesd/ and our property, because of the kind | of animals that we are. True law | James A. Donald derives from this right, not from the | arbitrary power of the state. | jamesd(a)echeque.com

1 0

Re: Don't Kill the Messenger--A New Slant on Remailers
by Rev. Mark Grant 17 Dec '03

17 Dec '03

On Sun, 29 Oct 1995, Bill Stewart wrote: > More of a problem with this system is that it's only useful for terminal > remailers; to use it in the middle of a chain, the next remailer would > need to be configured to auto-accept such messages, or else your remailer > would need to have a list of known remailers and use direct delivery > for all mail sent to them. That's not a problem with Mixmaster, as it already knows whether the message is the last hop of a chain or not. I was hoping to get my hack finished this weekend, but got caught up in CTCP instead (which I'll release once I find out why it kills my xterm on exit 8-().. Mark

1 0

[joanne@theory.lcs.mit.edu: MIT TOC SEMINAR--DAN BONEH--Thursday, November 2--4:15pm!!]
by lethin＠ai.mit.edu 17 Dec '03

17 Dec '03

From: joanne(a)theory.lcs.mit.edu (Joanne Talbot) Date: Mon, 30 Oct 95 12:23:33 EST To: theory-seminars(a)theory.lcs.mit.edu Reply-To: theory-seminars-request(a)theory.lcs.mit.edu Subject: MIT TOC SEMINAR--DAN BONEH--Thursday, November 2--4:15pm!! MIT TOC SEMINAR Thursday, November 2, 1995 Refreshments at 4:00pm, Talk at 4:15pm in NE43-518 ``Quantum Cryptoanalysis of Hidden Linear Forms'' by Dan Boneh Princeton University ABSTRACT Recently there has been a great deal of interest in the power of Quantum Computers. The driving force is the recent beautiful result of Shor that shows that discrete log and factoring are solvable in random quantum polynomial time. We use a method similar to Shor's to obtain a general theorem about quantum polynomial time. We show that any cryptosystem based on what we refer to as a `hidden linear form' can be broken in quantum polynomial time. Our results imply that the discrete log problem is doable in quantum polynomial time over any group including Galois fields and elliptic curves. Joint work with Richard Lipton. Host: Shafi Goldwasser

1 0

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

17 Dec '03

> > > On this same track, I suggest that "/dev/random" devices for unix are > > > an excellent idea. Ted Tso did one for Linux that steals all the bits > > > of semi-random timing information it can. > > > > Anyone know where I can find more information on this wonderful device? > > I've just sent patches (versus the Linux 1.3.28 kernel) off to Linus. > There's a fairly long exposition at the beginning of > drivers/char/random.c which explain its theory of operation. A colleague drew my attention to this, and I was so pleased with it that I ported it to FreeBSD. I kept the interface as close to the original as I could, but made some changes for efficiency and ease: 1) I turned the huge comment at the top explaining the theory of operation into a man page (random(4)). 2) We felt that hooking all interrupts might be dangerous. IDE drives can interrupt at a heck of a rate, and so can some serial ports, and we felt that in these cases _not_ using the interrupt was a good idea. So I added an ioctl to allow the superuser to select his own set, appropriate to the hardware in use. It is nearly impossible to do this automatically. Gimme a yell if you want copies :-) 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

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

17 Dec '03

>At the moment, I'm thinking of making the mandatory schemes be Keyed MD5 >for authentication, and weakened RC4 with an IV for confidentiality, with >the added stipulation being that the user must be informed when key >weakening is being used. I may swap RC4 for DES; they're both public >domain, but RC4 is simpler. They're both shared key, but I don't make PK >stuff mandatory. The licensed version of RC4, or the software that was posted anonymously? Do you really feel comfortable basing an IETF standard on that? When you use the term RC4 do you mean the real version or the posted one, what will you do if they ever conflict? Can you even use the name RC4 for the posted version? It seems to me that RC4 means the RSA licensed code, which presumably you wanted to avoid when you wrote no mandatory PK. Where would you swap RC4 for DES? I assume your added stipulation is a "should" not a "must" item. How are you going to handle key management and naming? /r$

2 1

payee anonymity
by Hal 17 Dec '03

17 Dec '03

Another way payees could be anonymous would be to immediately spend their received coins, and do so anonymously. This works for the online ecash system. They simply pass the coins on without first exchanging them at the bank. There would have to be something they wanted to buy that they could receive anonymously, though. Hal

1 0

Re: Digicash will not fly (not)
by tcmay＠got.net 17 Dec '03

17 Dec '03

At 5:41 AM 10/30/95, M. F. (Pat wrote: >"James A. Donald" <jamesd(a)echeque.com wrote: >>While Chaum is a brilliant cryptographer, he is an incompetent businessman >> >>He has demonstrated this in numerous ways. >> >>The latest being "Cash" where the bank skims off 4% to 10% every time. >> >>No one is going to use digicash under these kinds of terms and >>conditions. > > >Doesn't just about everyone do precisely this when they pay sales tax? >Every time a buck arrives or departs a hand one pays a tax yet the system >(you and I)continues accepting these terms albeit painfully. Many types of business dealings are exempt from sales tax, through arrangements for resales. I don't know if the "skims off 4% to 10% every time" point accurately describes how the current Digicash model works, but certainly this will not fly as a long term rate. So many monetary transactions happen in the course of business that even a 4% fee _per transaction_ would rapidly wipe out most of the value. --Tim May Views here are not the views of my Internet Service Provider or Government. ---------:---------:---------:---------:---------:---------:---------:---- Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay(a)got.net 408-728-0152 | anonymous networks, digital pseudonyms, zero Corralitos, CA | knowledge, reputations, information markets, Higher Power: 2^756839 | black markets, collapse of governments. "National borders are just speed bumps on the information superhighway."

3 2

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

17 Dec '03

> Date: Mon, 30 Oct 1995 20:16:24 +0200 > From: Mark Murray <mark(a)grondar.za> > > A colleague drew my attention to this, and I was so pleased with it that > I ported it to FreeBSD. > > Which version did you grab? More recent versions of the driver use a > more efficient mixing algorithm suggested by Colin Plum. There's also > the beginnings of support for user-mode deamons to add randomness into > the random pool by writing to /dev/random. I also added support for > reading the instruction timing register for x86 platforms that support > it. Version 0.92 21st Sept 1995. 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. For the same (or similar) reason, giving the said unwashed masses _write_ privelige might allow them to set /dev/*random to a known state. You've probably already thought of this, but I just had to say it :-). > 2) We felt that hooking all interrupts might be dangerous. IDE drives can > interrupt at a heck of a rate, and so can some serial ports, and we felt > that in these cases _not_ using the interrupt was a good idea. So I > added an ioctl to allow the superuser to select his own set, appropriate > to the hardware in use. It is nearly impossible to do this automatically. > > Indeed; I can't emphasize this enough. The clock interrupt, for > example, is a very bad irq to try to use. In the Linux driver, only > device drivers who register their interrupt driver with the > SA_SAMPLE_RANDOM flag actually have the interrupt timings sampled for > the random number generator. (Hmm.. Thinks of ways of doing something similar. I'm not functioning too well right now.) > People have suggested using making it possible to select at run-time > which interrupts to sample, instead of at compiling it into the device > drivers. I've generally not been convinced this is a good idea, because > most system administrator won't likely know which irq's are good and > which are bad for random number generation. For example, although it > may not be obvious, the network interrupt may not be a good choice, > since an adversary who is monitoring the ethernet cable can make a > pretty good guess about the timing of your network interrupts, and hence > what the likely inputs are to the random number pool might be. 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... > Gimme a yell if you want copies :-) > > Sure, why not. I'd be interested to see what you did. Hokay! Please also send me _your_ latest. (BTW - did Linus put it in his latest kernel?) 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

3 2

Re: S. 1284 To Amend (C) Act
by Weld Pond 17 Dec '03

17 Dec '03

>> S. 1284, s1201: "No person shall import, manufacture or distribute >> any device, product, or component incorporated into a device or >> product, or offer or perform any service, the primary purpose or ^^^^^^^^^^^^^^^ >IANAL, but I thought these types of laws were already tested and deemed >unconstitutional in cases involving video-tape copying boxes, dual video >cassette dubbing decks, SCMS 'scrubbers', etc... I think the large gray area here is the phrase primary purpose. The primary purpose of a device is in the users mind only. Videotape copying of noncopyright materials is done on a vast scale now due to home camcorders. But even if only a few people had camcorders they should be able to purchase equipment that can be used legally. Introducing the concept of "primary purpose" makes law abiding citizens suffer because some people are breaking the law. If an item has any legal purpose it must be allowed. This trend to take technology that *can* be used to commit crimes out of the hands of citizen units is growing. We see it with crypto export controls and recently with the PA law and Federal law making it a crime to posess devices and software to reprogram cell phones. When this doesn't make a dent in the number of these crimes I predict we will see licensing of technologies such as eeprom programmers, spectrum analyzers, frequency counters, and yes of course strong crypto. Weld Pond - weld(a)l0pht.com - http://www.l0pht.com/~weld L 0 p h t H e a v y I n d u s t r i e s Technical archives for the people - Bio/Electro/Crypto/Radio

1 0

Article on PGP (Noise)
by Eric Anderson 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- C'punks I saw a good article on PGP in this month's issue of American Survival Guide. Not only did the article portray the use ofstrong crypto as a good thing for privacy and liberty, it also tells the reader where to obtain PGP. After that, the article goes into some of the issues surrounding PGP such as ITAR, Phil Zimmerman's legal troubles (It even tells how to contribute to his legal fund.) and how the government is really against it. After the background, the article gives clear, detailed, step by step instructions on how to use it; from the inital unzipping of the program to setup and key generation and management. All in all, I found this a very informative article for the new user and even some of the more advanced users (Hey-you learn something new every day, right?). It wasn't the type of article that wouldn't be covered in Time or Newsweak that's for sure. Eric -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQBVAwUBMJWDeyQV+sMsxjC5AQGT9QH9E8BHovGCmu7p9wB2nYQzmebqFPw3sfnR 2CuFTSvkdbg/4yArOsE87S+g28I2B/tscaVYdAO8HA5CdhVVAxbH0w== =wjpi -----END PGP SIGNATURE-----

1 0