- cypherpunks-legacy - lists.cpunks.org

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

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: /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

update.350 (fwd)
by Jim Choate 17 Dec '03

17 Dec '03

Forwarded message: >From physnews(a)aip.org Wed Dec 10 16:59:59 1997 Date: Wed, 10 Dec 97 14:35:44 EST From: physnews(a)aip.org (AIP listserver) Message-Id: <9712101935.AA25024(a)aip.org> To: physnews-mailing(a)aip.org Subject: update.350 PHYSICS NEWS UPDATE The American Institute of Physics Bulletin of Physics News Number 350 December 10, 1997 by Phillip F. Schewe and Ben Stein QUANTUM TELEPORTATION has been experimentally demonstrated by physicists at the University of Innsbruck (Anton Zeilinger, 011-43-676-305-8608, anton.zeilinger@ uibk.ac.at; Dik Bouwmeester, Dik.Bouwmeester(a)uibk.ac.at) First proposed in 1993 by Charles Bennett of IBM (914-945-3118), quantum teleportation allow physicists to take a photon (or any other quantum-scale particle, such as an atom), and transfer its properties (such as its polarization) to another photon--even if the two photons are on opposite sides of the galaxy. Note that this scheme transports the particle's properties to the remote location and not the particle itself. And as with Star Trek's Captain Kirk, whose body is destroyed at the teleporter and reconstructed at his destination, the state of the original photon must be destroyed to create an exact reconstruction at the other end. In the Innsbruck experiment, the researchers create a pair of photons A and B that are quantum mechanically "entangled": the polarization of each photon is in a fuzzy, undetermined state, yet the two photons have a precisely defined interrelationship. If one photon is later measured to have, say, a horizontal polarization, then the other photon must "collapse" into the complementary state of vertical polarization. In the experiment, one of the entangled photons A arrives at an optical device at the exact time as a "message" photon M whose polarization state is to be teleported. These two photons enter a device where they become indistinguishable, thus effacing our knowledge of M's polarization (the equivalent of destroying Kirk).What the researchers have verified is that by ensuring that M's polarization is complementary to A's, then B's polarization would now have to assume the same value as M's. In other words, although M and B have never been in contact, B has been imprinted with M's polarization value, across the whole galaxy, instantaneously. This does not mean that faster-than-light information transfer has occurred. The people at the sending station must still convey the fact that teleportation had been successful by making a phone call or using some other light-speed or sub-light-speed means of communication. While physicists don't foresee the possibility of teleporting large-scale objects like humans, this scheme will have uses in quantum computing and cryptography. (D. Bouwmeester et al., Nature, 11 Dec 1997; see also www.aip.org/physnews/graphics) DO EARTHQUAKES HAVE ELECTRICAL PRECURSORS? The elastic waves measured by seismometers are transmitted by the flexing crust while an earthquake is doing its worst. But some scientists believe that flexing also goes on in the hours and even weeks before a quake. Too small to be detected seismically, the flexing might well be sensed electrically. As underground strata rearrange themselves before a quake, the thinking goes, pockets of water are squeezed into new configurations, changing local conduction properties, which can be monitored with buried electrodes. On this basis Panayiotis Varotsos at the University of Athens (011-30-1-894-9849, pvaro(a)leon.nrcps.ariadne-t.gr) has reportedly predicted certain quakes in Greece weeks ahead of time by triangulating voltage differentials at the level of 10 millivolts/km over distances of 100 km. (Some skeptics dispute this assertion.) In new research, Varotsos buttresses his claims with laboratory studies of another system under pressure which puts out transient electrical signals before it fractures, namely a crystal containing a variety of dislocations and defects. Conductivity patterns in the crystal convince Varotsos that analogous patterns (although on a much bigger distance scale) observed in the buried electrode arrays constitute a true earthquake precursor. (Varotsos et al., Journal of Applied Physics, 1 Jan, 1998; journalists can obtain the paper from physnews(a)aip.org.)

1 0

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

17 Dec '03

All your individual answers make sense. Taken together, tho, they make HTTP-NG worrisome on the crypto front. For example, it's probably a real bad idea to replace DES with something commonly called RC4. The former has been under public scrutiny for years, the later still has not formally emerged from the shroud of trade secret. The keyed MD5 responses also don't inspire confidence. With all due respect, I strongly encourage you to leave crypto out of HTTP-NG for the time being. Wait to see what happens from the various IPng security, SSL, S-HTTP, the W3C work, et cetera. Leave some "holes" in the protocol, but don't tie anything down now. For better for the Web to wait six to 12 months for HTTP-NG, then for mistakes to occur in this area. /r$

4 5

FWD: Electronic Warfare (from the digitaliberty list)
by Fen Labalme 17 Dec '03

17 Dec '03

Interesting (if a bit mild for this list) article from another list some of you might be interested in (or already subscribed to).... ---- Forwarded Message ---- From: owner-digitaliberty(a)phantom.com Date: Tue, 31 Oct 1995 01:00:06 -0500 To: digitaliberty-digest(a)piltdown.phantom.com Subject: digitaliberty V1 #13 digitaliberty Tuesday, 31 October 1995 Volume 01 : Number 013 In this issue: Test Electronic Warfare See the end of the digest for information on subscribing to the Digitaliberty or Digitaliberty-Digest mailing lists. ---------------------------------------------------------------------- From: Bill Frezza (via RadioMail) <frezza(a)radiomail.net> Date: Mon, 30 Oct 1995 13:14:58 -0800 Subject: Test This is a test. <sigh> ------------------------------ From: DigitaLib(a)aol.com Date: Mon, 30 Oct 1995 18:02:17 -0500 Subject: Electronic Warfare Folks, Attached is a column that ran on the op-ed page of today's Communications Week. I have agreed to do bi-weekly opinion pieces for them focussing on the impact of technology on society, politics, and culture - all with a DigitaLibertarian slant (of course). My hope is that this fiesty group can keep me fed with grist for these pieces. For anyone that lives in NYC, I will be carrying the DigitaLiberty banner on a panel on digital commerce at the Multimedia Design conference at the Javits center Friday 11/3 at 3:30pm. Stop by and say hello. Regards, Bill - --------------------------------------------------------------------------- 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. ------------------------------ End of digitaliberty V1 #13 *************************** To subscribe to Digitaliberty-Digest, send the command: subscribe digitaliberty-digest in the body of a message to "Majordomo(a)phantom.COM". If you want to subscribe something other than the account the mail is coming from, such as a local redistribution list, then append that address to the "subscribe" command; for example, to subscribe "local-digitaliberty": subscribe digitaliberty-digest local-digitaliberty(a)your.domain.net A non-digest (direct mail) version of this list is also available; to subscribe to that instead, replace all instances of "digitaliberty-digest" in the commands above with "digitaliberty". ---- End Forwarded Message ----

1 0

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: FW: Symantec Norton, Your Eyes Only.
by Pearson Shane 17 Dec '03

17 Dec '03

Hi guys, If I could get access to the source, understand all of it fully, and understand how it will act under Win95 with whatever compiler they used, I could probably write my own. So I guess it comes down to trust. Thanks for the replies. Bye for now. > -----Original Message----- > From: David Honig [SMTP:honig@otc.net] > Sent: Saturday, January 24, 1998 5:08 AM > To: Pearson Shane; 'William H. Geiger III' > Cc: 'cypherpunks(a)toad.com' > Subject: RE: FW: Symantec Norton, Your Eyes Only. > > At 03:46 PM 1/23/98 +1100, Pearson Shane wrote: > >Hi William, > > > >Many thanks for the reply. > > > >I was hoping it was ok having Blowfish, > >but I guess it could be their own > >"efficient" version. > > > >Bye for now. > > > > WHGIII gave you the most conservative answer. That is, in cryptology, > the > correct answer. > > A more detailed analysis would say: > > * the blowfish algorithm is considered strong for various reasons > > * IFF the Norton program were written correctly > (not just the algorithm implementation, but key hiding, > worrying about getting swapped onto disk by the OS, etc.) > then it would be a useful tool for security. > > * Without examining the source, any assumption of security > from using the tool relies *absolutely* on your trust of the > implementor. > > (In a Turing award paper, Ritchie described how you > implicitly must trust your compiler-writers too.. the > compiler could have clandestine functions like inserting > extra code when it recognizes patterns) > > So you see how WHGIII was correct, although for practical > purposes (depending on the value of your data and the > attackers you anticipate, plus the security of the rest of your > system (only as strong as the weakest link)) you may find this tool > acceptable > in the non-exportable version. Keylength-limited versions are > worthless > from a security viewpoint. > > But on this mailing list, you won't find the yes/no answer > you probably want. Which is probably correct behavior for this list. > > Cheers, > > > ------------------------------------------------------------ > David Honig Orbit Technology > honig(a)otc.net Intaanetto Jigyoubu > > "The tragedy of Galois is that he could have contributed so much > more to mathematics if he'd only spent more time on his marksmanship." > > > > > > > > > > > > > >

1 0

Clinton for Nobel Peace Prize [CNN]
by Jim Choate 17 Dec '03

17 Dec '03

Forwarded message: > Clinton Nominated For Nobel Peace Prize > > OSLO, Norway (Reuters) - President Clinton, engulfed in asex scandal > and fighting for his political life, won anomination Tuesday for the > 1998 Nobel Peace Prize from admirersof his foreign policy. > [text deleted] ____________________________________________________________________ | | | The most powerful passion in life is not love or hate, | | but the desire to edit somebody elses words. | | | | Sign in Ed Barsis' office | | | | _____ The Armadillo Group | | ,::////;::-. Austin, Tx. USA | | /:'///// ``::>/|/ http://www.ssz.com/ | | .', |||| `/( e\ | | -====~~mm-'`-```-mm --'- Jim Choate | | ravage(a)ssz.com | | 512-451-7087 | |____________________________________________________________________|

1 0

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