December 2003 - cypherpunks-legacy

$10M breaks MD5 in 24 days
by Hal 17 Dec '03

17 Dec '03

I am not attending the Crypto conference, but I sat in on the evening "rump session" the other day. One of the more interesting papers had a claim (with little detail, unfortunately) that for ten million dollars you could build a machine that would "break" MD5, in the sense of finding another message which would hash to the same as a chosen one, in 24 days. This result did not depend on any internal structure in MD5, but was purely a result of the hash size (128 bits) and the time it takes to calculate a hash. The main new result which allowed this was a more efficient way of handling a parallel search for collisions (two messages which hash to the same thing). In some earlier methods, n machines provide only a sqrt(n) speedup. The new method improves this, although my notes don't show exactly how close they come to an n-fold speedup. The Secure Hash Standard (SHS, aka SHA) is, they said, 64K times slower, hence this technique would take 64K times longer (or cost ~64K times more?) to break that hash. I don't think this is probably anything to really worry about, but maybe it points out a need for a longer hash in the next few years. Hal P.S. The paper was by Paul C. van Oorschot & Michael J. Wiener.

5 6

No Subject
by Anonymous 17 Dec '03

17 Dec '03

Kudos to Hal Finney for his descriptions of Stefan Brand's offline cash. As with other offline cash protocols it contains the following assumption: > Let's call the user Irving, and > the number which encodes his identity (it might just be his bank account > number in this case) we will call I. What happens when we've caught Irving double spending (or million spending?) Is it guaranteed that Irving will have enough in his bank account to cover the fraud? I don't see any way to guarantee that except for absurdly large security deposits. Also, are bank accounts required to be in True Names so that multi spenders can be caught and punished? If so, how do we prevent the use of numbered accounts, Duncan Frissel's nom de guerre accounts, etc. and do we really want to set up that kind of True Name infrastructure? Also, what about stolen coins? If Irving can succeed in stealing a coin from Jane without her knowledge, Irving can spend it untraceably as many times as he can get away with (perhaps thousands or even millions, depending on what security precautions we layer above the offline cash), and Jane gets fingered. On the other hand, Jane might simply give Irving some coins, plausibly claim they were stolen, and split the proceeds from Irving's spending spree. In general, multi spending might occur because of accident, malice, or a combination of those two factors. How do we distinguish between accident and malice to determine liability, reputation loss and/or punishment?

1 0

U & Pu is good for U
by Brad Dolan 17 Dec '03

17 Dec '03

>From: IN%"jdd(a)aiki.demon.co.uk" >To: IN%"psmarie(a)cbis.com" >CC: IN%"cypherpunks(a)toad.com" >Subj: RE: U & Pu "poisoning of the environment" > >In message <9408251512.AA11369(a)focis.sda.cbis.COM> "Paul J. Ste. Marie" writes: >> > > Epidemiologic studies of workers [even wartime workers with impressive >> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >> > > body burdens/ exposures] in a number of uranium bomb-making centers have >> ^^^^^^^^^^^^^^^^^^^^^^^^ >> > > found ~ no health effects. >> > >> > This is quite similar to saying that nerve gas is harmless because >> > scarcely anyone working in storage areas has been killed by it. Or >> > that bullets won't harm you because people handle crates of them and >> > they don't get shot. >> > >> No, it is not. If you had read the message more carefully, you would >> have had to phrase your example as, "This is quite similar to saying >> that nerve gas is harmless because scarcely anyone who has inhaled >> substantial amounts of it has been killed by it." > >In all of these cases there is a serious attempt to make sure that the >workers are not harmed by the dangerous substances involved. I must >say that the phrase "impressive body burdens" is fairly incomprehensible. I grant you that "impressive" is not too specific but "body burden" is a common way of referring to the material which is taken into the body and retained. Typically, most material inhaled or ingested is quickly exhaled or excreted out of the body. Some exposure (and dose) accrues during this time. If some material remains deposited in the body, exposure continues. >But nevertheless, my point stands: workers are carefully protected from >the plutonium and U235 in nuclear weapons plants. By the standards of the time, workers during WWII were pretty well protected. By our standards, which may be overly conservative, some WWII-era workers received large doses and/or body burdens. Because these workers (1) had exposures and (2) were monitored, they are the group of choice for epidemiological studies. > When their radiation >badges show what is considered a high level dose, this does not mean >that they have been exposed to anything like, say, the radiation from >a kilo of unshielded plutonium. I would be happy to hold a kilo of unshielded plutonium in my hand. I would probably think it wise to wash it later. Pu is an alpha emitter. Its radiation will not penetrate the dead layer of the skin. I have held pieces of uranium in my hand. I'm still here. >If radioactive substances are used as weapons, the intention will be >to do the maximum possible damage. I don't think that anyone would >survive for long after exposure to, say, a suspension of plutonium >in air designed to be breathed in, perhaps as an aerosol. I would bet that you could get a lot more effect for your terrorist dollar with aerosols of any number of other, more commonly available substances (like gasoline). I don't have ready access to a good library right now to go pull references but if you follow up on the references to these three papers, you should find more than you will ever care to read on the topic: Wilkinson, G.S.; Tietjen, G.L.; Wiggs, L.D.; Galke, W.A; Acquavella, J.F.; Reyes M.; Voelz, G.L.; Waxweiler, R.J. Mortality among plutonium and other radiation workers at a plutonium weapons facility. Am. J. Epidemiol. 125:231-250; 1987. Checkoway, H.; Mathew, R.M. Shy, C.M.; Watson, J.E. Jr.; Tankersley, W.G.; Wolf, S.H.; Smith, J.C.; Fry, S.A. Radiation, work experience, and cause specific mortality among workers at an energy research laboratory. Br. J. Indust. Med. 42:525-533; 1985. Peterson, G.R.; Gilbert, E.S.; Buchanan, J.A., Stevens, R.G. A Case- Cohort Study of Lung Cancer, Ionizing Radiation, and Tobacco Smoking Among Males at the Hanford Site. Health Physics, 58:3-11; 1990. >To repeat my point: you say that statistical studies of workers in >nuclear weapons plants which are specifically designed to minimize >the effects of radiation show that radiation has done little harm. Loosely put, the studies say, "Workers at facility X whose exposures varied from {small} to {large} showed/did not show increased death rates from {long lists of diseases}." >Well, I should hope so. >On the other hand I say that such studies are poor criteria for >judging the effects of radiation intended to do the maximum possible >harm. Well, these studies are about all we have to go on right now. The wartime residents of Hiroshima and Nagasaki do provide a large set of folks exposed to "radiation intended to do the maximum possible harm" but, darn it, none of them were wearing dosimeters. People do study these groups, making educated guesses about doses, but it's hard to draw precise conclusions on that basis. To draw this off-topic topic to a close, I recommend the following to help bring the various risks into perspective: Cohen, B.L.; Catalog of Risks Extended and Updated. Health Physics, 61:317-335, 1991. >I think that this is really indisputable. >-- >Jim Dixon Sorry for disputing. Brad bdolan(a)well.sf.ca.us

1 0

Re: Using PGP on Insecure Machines
by wcs＠anchor.ho.att.com 17 Dec '03

17 Dec '03

> > Also importantly, the user interfaces for PGP simply suck as it > > stands, making people like Tim uninterested in going through the .... > At the risk of repeating myself, what's the problem with wrapping PGP in > a shell script? Works for me - see a previous mailing, complete with > wrapper scripts. I can send either encrypted or just signed email > without especially noticing it. Wrapping PGP in shell scripts is only useful for people who use shells, and a lot of people either use GUIs instead (often non-extensible ones), or keep their PGP on PCs at home rather than their networked Unixen at work where they get their mail. This means that to use PGP, they need to do things like kermit from home to work, read their mail, save it in files, kermit the files to their PC, PGP-decrypt and read them on the PC, etc. It's a bit easier if people have remote-scriptable terminal emulators on their PCs, which let the Unix end run a script to save the file and download it and maybe fire up PGP on the PC, but it still feels annoyingly like work, and if your Unix box can download files to your PC and run them, it can run pgp-steal-keys just about as well as real PGP. Similarly, if you've got TCP/IP running on your PC, whether through SLIP or directly, you've still got a security risk to worry about. You can reduce these problems by running a _real_ operating system on your PC, but it's tougher to run your favorite applications that way, and you still need to either run all your mail down to the PC, which isn't practical for lots of people, or explicitly forward the stuff down there from your main mail system. There's another transparency problem, at least for reading encrypted mail - you either need to type in your passphrase each time, which is annoying and increases exposure somewhat, or you need to leave it aorund in environment variables, etc., which also increase exposure. On the other hand, a shell script approach can be just fine for signature checking, as long as your mailreader has a painless interface, since there isn't much security risk from having PGP on a machine without your real secret key and passphrase there. There's still some risk - if the machine is shared with other people, someone may be able to replace PGP with pgp-cc:-kgbvax or pgp-nsa-sig-verify - but it's a start. Bill # Bill Stewart AT&T Global Information Solutions, aka NCR Corp # 6870 Koll Center Parkway, Pleasanton CA, 94566 Phone 1-510-484-6204 fax-6399 # email bill.stewart(a)pleasantonca.ncr.com billstewart(a)attmail.com # ViaCrypt PGP Key IDs 384/C2AFCD 1024/9D6465

2 1

Re: Nuclear Weapons Material
by Patrick Juola 17 Dec '03

17 Dec '03

In order to cause damage, alpha emitters like plutonium must come in intimate contact with a material, such as the tissues of your lungs or bones or the inside of your favorite memory chip. A billionth of a gram of plutonium inhaled or swallowed is something to seriously worry about, but you can hold a lump of the stuff in your hand as long as it is covered with a leakproof cladding or vitrified into a ceramic. It is in this sense that plutonium is extremely toxic and hazardous to the environment, while at the same time not being particularly radioactive. Heavy shielding is not required between you and it. My understanding is that the heavy metal toxicity of Pu exceeds the radioactive toxicity by several (10?) orders of magnitude. In other words, the fact that Pu is an alpha emitter is irrelevant to the risk -- it's simply like lead poisoning only several billion times worse. Simple arithmetic yields that the amount of alpha exposure from a billionth of a gram of an alpha emitter with a half-life measured in thousands of years is infinitismal. - kitten

2 1

Re: Nuclear Weapons Material
by thad＠pdi.com 17 Dec '03

17 Dec '03

To: cypherpunks(a)toad.com Subject: Re: Nuclear Weapons Material >> Roy M. Silvernail says: >> Plutonium oxide has a reputation for causing eventual lung cancer when >> inhaled in microgram quantities. But if the plutonium metal is sintered >> into a ceramic, it's not loose and breathable. I can't say how >> otherwise toxic it might be, but I'd expect it to be similar to other >> heavy metals. So the poker chips sound pretty safe. They'd be safe unless the pot got really big. I recall hearing a radio show in which some nuclear engineer was saying that such-and-such and incident couldn't have really gone critical, because when that happens, it starts to glow sort of bluish color, and you feel heat as if you were standing in front of a really big oven. The way it sounded, I got the impression that unintended criticalities did happen now and then. Thad Beier Pacific Data Images 408)745-6755 thad(a)pdi.com

1 0

Spoofing Nuclear Weapons and PGP
by John Young 17 Dec '03

17 Dec '03

Responding to msg by dichro(a)tartarus.uwa.edu.au (Mikolaj Habryn) on Thu, 25 Aug 5:51 PM >not really certain. *shrug* sorry. Read some books on >it - the amount of literature which should be >classified but is freely available is mind-boggling. To tie this back to crypto and technology: Under a sub-sub-sub-contract I once worked on some phony CAD drawings for the nuclear weapons production process, plotting false info that still appears in popular books, some of which has been posted here. The docs were then encrypted and stegonagraphied for authenticity. We were told that they were turned loose on the market for this product in other countries. I don't know if the USG was involved, there no security clearances. It may have been a commercial scam. Also, growing up not to far from LANL, I was told that kids of staff were encouraged to chat about B-this and W-that by the security people there as part of the fog around that outfit. This supports the suggestion for profligate use of PGP as a stratagem, to make it harder to tell the trivial from the other. Or is public encryption a stratagem to focus on software rather than hardware? Anybody hear anything about covert ID in new-generation CPUs, like done with supercomps? John

2 1

Re: Using PGP on Insecure Machines (fwd)
by chen＠intuit.com 17 Dec '03

17 Dec '03

> [ On Knuth no longer reading his mail ] > > > He's also trying to complete his "Art of Computer Programming" series... > > > > Is Volume IV out yet? My I-III still await the promise of the Intro... > > Not that I know of. A recent Computer Literacy newsletter has an interview with Knuth in which he says (if I recall correctly) that he plans to complete vols. IV and V by 1998, whereupon he will begin work on a revised edition of vol. I. He's now emeritus at Stanford so that he can write full-time. -- Mark Chen chen(a)netcom.com 415/329-6913 finger for PGP public key D4 99 54 2A 98 B1 48 0C CF 95 A5 B0 6E E0 1E 1D

1 0

Re: Nuclear Weapons Material
by Jim choate 17 Dec '03

17 Dec '03

> > There is some confusion in terminology here. The brass case is indeed > discarded when the round is fired. Byt 'casing' he means the exterior of > the warhead. The word 'round' is used for both the warhead+gunpowder+brass > and then for the warhead itself. Larger artillery pieces do not use a > brass shell case at all. The round is loaded, and then the powder is > rammed in after it. > That is called the 'jacket' in all the years I have handled weapons that is the only correct term for it. The casing is where the powder goes. We were not talking about artillery pieces in relation to the comment by me on this issue. I know little about artillery, I do know about tanks and aircraft because they are a life long interest for me. > > I can find no reference any U-core round being HE or otherwise carrying a > > charge. In all cases that I am aware of and can find reference to it is simply > > a KE attack on the target where the by products of the impact bounce around > > inside the target grinding up whatever is in there. > > I believe that this is true, except that the 'products of the impact' are > drops of metal and what they do is worse than grinding something up. > -- > Jim Dixon > The pieces in most cases are simply slivers of metal that breaks off the inside of the tank because of hyper-sonic shockwaves. They are not molten and do not in general cause a fire. Other than a lucky hit on a live round with the ammo door open there is little chance of starting a fire.

3 3

Re: In Search of Genuine DigiCash
by rah＠shipwright.com 17 Dec '03

17 Dec '03

> Making a digital cash system secure, scalable and distributed >is a non-trivial task, making it anonymous is still more difficult. But it's done already, right? At least as far as scoping out the problems and having reasonable solutions which now need to be tried out, I mean. If we're talking about problems of marketing, access to and from the rest of the financial infrastructure, enforcement for fraud (double spending), I think the problems are manageable enough for a market test, and I've done my best to talk about that here and elsewhere. If you're talking about algorithms, they're done already. They're to the point where people are writing better ones that do the same thing more efficiently. If you're talking about the operations stuff (handling cash, keeping track of unspent cash, identifying offenders, etc) I contend that the code is being written now or has been written already. >Guaranteeing anonymity creates alot of problems as was brought out in a >previous discussion on license based cash in which it was pointed out >that by colluding with consumers a bank can still "mark" bills. I am under the impression that technology exists that allows anonymous offline digital cash transactions where double spenders are identified. Is that not the case? >I am yet to see a single anonymous digital cash system which could not be >implemented more simply if the requirement on anonymity were not made. I >would be pleased to be proven wrong. How simply? Are the computational requirements for generating a piece of anonymous offline digital cash, for discovering double spenders, for holding and spending cash Chaum's digital cash, or, say, Brand's version, excessive when compared to non-secure methods, especially on-line methods? Why do you suppose these guys are spending money developing the stuff? Are they wasting their time? I've heard sums in the range of at least $10 million that Chaum has spent already... >What I'm really asking is for an example of this overhead that is being >reduced. First of all, I'd like you to talk a little about offline digital cash systems which are non-anonymous, and have all the other features of Chaum or Brands. Pointers to the information is fine, unless others want to see it here. If you're talking about *any* online system, I've got you hammered. I just won that fight on another list (or at least I think I did ;-)), and I'll dump it all to you through e-mail, if you want. I'll give you hint: my jumping off point was Eric's observation that offline methods don't involve the banking system to effect every transaction. >> There are other reasons >> for not doing on-line transactions. Including credit checks, interest >> calculations on outstanding balances, vendor reserve requirements, >> transaction threading, on-line wait states and bandwidth, etc. It's >> considerable. > >And its going to get more considerable when we have communities of agents >arguing with each other. I think we want to solve the problems created by >these requirements, not shy away from them. Agreed, but I don't think avoiding them all together by doing transactions offline is shy, I think it's economically necessary. Cheers, Bob Hettinga ----------------- Robert Hettinga (rah(a)shipwright.com) "There is no difference between someone Shipwright Development Corporation who eats too little and sees Heaven and 44 Farquhar Street someone who drinks too much and sees Boston, MA 02331 USA snakes." -- Bertrand Russell (617) 323-7923

1 0

Arizona State Email Non-Privacy Policy
by sw＠tiac.net 17 Dec '03

17 Dec '03

Dear Cypherpunks- A friend mailed the following questions, which I have edited. Please Cc: any replies to me for now as I'm getting back on cypherpunks after the digest was shut down. Note: A.S.U. is Arizona State University, in Tempe (next to Phoenix). >I want to ask you something. What sorts of illegal things could a person do >with an email account? What's happening is that A.S.U. has just adopted a >policy which allows them to...well, this is way it says: "The routine >management and administration communication systems or computers may include >the monitoring of any or all activity on these systems on a regular basis" >blah blah blah "Any message is permanent and may be read by persons other than >the intended reader." I'm sure this has always been the case, and that they >are just coming out with it. They also say that "We no longer take requests >for the Public Records Act." Do you know what that means? > ... >You know, some landlord out here just got arrested for installing video >cameras in his tennant's apartments... it seems like a similar situation to >this - what the University does. The reasons they give are, you know, they >just want to make sure no one is running a business, doing anything illegal >(A.S.U.P.D....heh!), or "inapproporate" like sending nasty messages to people, >or mail bombs or something. But it doesn't seem like they would need to sneak >into your mail to find out if your bugging people. The other thing, is that >they say that they can go into your mail without telling you first, and that >we should trust that they wont abuse this... > ... >Something else, I just found out that it's "inappropriate" to use the A.S.U. >system for social correspondence! It's listed uner abuses along with >computer fraud and pirating. (!) Quite a few people answered (thank you all) my earlier question by saying that doing your own encryption is the best solution. True in a way, but I know there are "student rights" groups that specifically work to intimidate college computer administrations into modifying these sorts of policies, also setting up standard privacy policies, etc. Is there some other mailing list or newsgroup where I would find them? -- forwarded by Steve <sw(a)tiac.net> - - - - - - - - - - why did the chicken cross the infobahn? finger for more info.

2 1

Cash, cheaters, and anonymity
by Hal 17 Dec '03

17 Dec '03

This is a response to an untitled anonymous post which raised some good issues. My answers may be a little controversial; feel free to disagree. One question is the ease of theft in a digital cash environment, and the consequences of claiming that secrets have been stolen. This problem was recognized very early on in discussions of digital signatures. The whole point of a signature is so that someone can be held to a commitment. But an easy "out" would be to "accidentally on purpose" let the secret keys be stolen, then to claim that the signature was actually forged. Contrariwise, a business might be vicitimized by actually having its secrets stolen and a forged signature created that committed it to an unfavorable action. I don't know what the best solution of these kinds of problems will be. Probably in the next couple of years we will see some test uses of digital signatures, and then we can see how these conflicts will be handled by the courts. Obviously, traditional methods like handwriting analysis which rely on physical imperfections will not be useful. Instead the issues to be examined would include the security methods used to guard the secrets, who might have had access to them, what the reputations are of the parties involved, and so on. It seems like these cases will not be easy to resolve cleanly. On the other hand, I would hope that people actually can learn to use care in safeguarding their secrets. The pass words and PINs we use today may be complemented by physical checks for voice patterns, thumb prints, perhaps (ironically) handwriting. Another approach would be to raise people's IQ to about 1000, so they could do an unbreakable authentication protocol in their heads :o. Failing that, there have been suggestions (one here a couple of days ago) to use various kinds of information exchange between the authenticating device and the human user in order to prove authorization in such a way that even a thief who has snooped on past exchanges will not be able to use the device. This approach is sometimes called the use of "pass algorithms". Applying this to the double-spending case, I suspect that Bob Hettinga is more on the right track in seeing the solution in the legal system rather than a simple "shucks, you caught me" forfeiting of a bond worth triple damages. There really should be no excuse for double spending, even of a penny, and the penalties could be made strong enough to deter most people. If a bank does not think they will be able to find and prosecute a person who is withdrawing off-line digital cash, they will probably not give any to him. Then if the money is double-spent, the person who withdrew it would be prima facie responsible, with a reasonable presumption that they did it unless there is significant evidence otherwise. I don't know that this is how it will work out but it is one possibility (unless the uncertainty just scares everybody away - but I think the digital signature experience will get people used to the concepts and problems). The other point I wanted to discuss was this issue of the bank authenticating the people who receive the cash. This does raise the spectre of a big brother system where there is some way to identify people with 100% certainty. Obviously this could be abused. My feeling is that there is a rather fine line we could walk in which this potentially-oppressive technology exists, but in which it is wielded in a way which enhances privacy and gives people the maximum degree of control over information about themselves. By analogy, think of a surgeon using a scalpel. This is a tool which is capable of terrible damage, and it is only by using it with the utmost skill that it brings about great benefits. Shunning knives altogether would be as bad as allowing everyone to hack and slash indiscriminantly. In a similar way, authentication technology is IMO a necessary enabling step for uses of cryptography which will enhance privacy. Off-line cash is one example. We have to protect the interests of all parties involved in a transaction or else it will not occur (voluntarily). A bank will not want to give out ecash tokens for which it is liable unless it is confident that it has some recourse in the case of fraud (such as double-spending). If users have to identify themselves to the bank in an utterly non-private way, that is only so that they can then spend the money in perfect privacy. The authentication that exists at the withdrawal step is wiped out by the blinding of the cash that is done before it is spent. It is a matter of balance. Without the authentication, you're not going to have off-line cash, IMO. You will be stuck with on-line systems in which everyone has to verify everything before accepting it. This means you pay a cost in communications overhead and possibly other foregone opportunities. Another example would be digital credentials. These can be thought of as digital tokens, somewhat like cash tokens, which have specific, published meanings. One might mean, "salary > $40K". Another, "age > 18 years". Like ecash, they can be issued and then re-blinded so they are not recognizable. Here we do not have the double-spending problem, but there is still a need for authentication. In order for these credentials to be trusted, the organizations which issue them will have to validate your eligibility. You'll have to show birth certificates, pay stubs, and all of the other kinds of paraphernalia you do today. The thought of this may grate in the minds of those seeking the freedom of digital anonymity. But, again, once this authenticating step is completed, you gain the advantages of a system where you could potentially borrow money, rent cars, and do other things which all involve authentication today, in complete privacy. You authenticate yourself once, and from then on the system works for you. So, my vision of the ideal future is neither a database society, where everything is recorded and tracked and privacy is protected only by a flimsy shield of laws that are widely flouted, nor a digital anarchy where identity is meaningless and trust among transitory pseudonyms is virtually impossible. Rather, I see a foundation of careful, nit-picking authentication upon which is built an elaborate structure of information flows fully under the control of the individuals involved. By adding the option for authentication to the mix, you actually expand the opportunities offered by digital privacy technology. Hal Finney

1 0

Actually plonking on a routine basis
by John Young 17 Dec '03

17 Dec '03

> >Responding to msg by tcmay(a)netcom.com (Timothy C. May) >on Thu, 18 Aug 4:41 PM > >>I'd be a lot more interested if there were >>some tie-ins to crypto policy and technology. > >Yep, this is what I want also but need participation by >others so I don't stick out too much and get Dixon-ized >by Perry, or, bless him, Nzook-ized by Graham. > >Just see what happens when I post shortly. > >John Goodness Perry, Why waste talent aping yourself? Tim wisely says above: use your smarts on crypto and techno. John

1 0

Alt.Cryptids.Plonk.Plonk.Plonk.
by Blanc Weber 17 Dec '03

17 Dec '03

I was just counting them, and realized: If you knew that you were in someone's kill file, and that only those who were also members of that illustrious group were the kind who would reply in reference to those who had put them there, those banished ones could talk about their censors in front of everybody and the censors ones would never know, although everybody else would. Secret expressions unconcealed. Blanc [cryptid: from cryptozoology - creatures whose existence has not been substantiated.]

2 1

You can hide from the Chip, but not from the Man.
by koontzd＠lrcs.loral.com 17 Dec '03

17 Dec '03

After reviewing the NIST rebuttal to Matt Blaze's Paper, 'Protocol Failure in the Escrowed Encryption Standard', referring to how the Unit ID (UID) was expanded from 24 bits to 32 bits, I e-mailed the following question to Dorthy Denning, informing her that I wanted to share the answer. The question arises, does the unit ID indeed contain a field registered to the equipment manufacturer? Professor Denning replied: "Yes, the UID contains bits that identify the manufacturer." (I didn't think to ask how many) The implication is that a counterfeit LEAF is detectible. As per FIPS Pub 185, The Escrowed Encryption Standard, a transmission or stream of data is preceded by the Cryptographic Protocol Field (CPF) which is registered to a particular application (Clipper phone - AT&T, for example). The CPF is used to determine where to find the LEAF, the LEAF Creation Method (LCM) and the Family Key (KF). Thus the CPF also identifies the manufacturer, or group of manufacturers for a theoretically second sourced product, by identifying the data protocols of the encrypted data (RCELP in the case of AT&T). A Bogus LEAF tested against the Escrow Authenticator (EA) must still match the manufacturer information found in the Unit ID. I would expect that there is between 10 and 12 bits of the UID specifying manufacturer. The bad news is that to escape detection by the Law Enforcement/National Security monitoring activity, you need to produce a LEAF that not only produces an acceptable Escrow Authenticator used by the recipient EES chip, but also produces a UID falling with some number of bits that matches LE expectations as a result of examing the CPF. The problem is that without knowledge of the Family Key and the LEAF creation method, there is no possiblity of checking for a match in the UID's manufacturers identifier.

2 1

Re: Nuclear Weapons Material
by David K. Merriman 17 Dec '03

17 Dec '03

>> I don't know much about modern munitions, but I do know that armor >> piercing rounds may have no charge in them at all. Generally, when a >> round pierces one side of a vehicle, it loses enough energy and is >> suitably deformed to prevent exit from the opposite wall. It does, >> however, bounce around quite a bit, which can be plenty of fun in a >> tank loaded with equipment, munitions, and soldiers. > > I was under the impression that the most common techniquoe for >creating armour-piercing munitions was to use shaped-charges. While >depleted uranium has it's uses (being, as someone said, rather dense), >mass alone will not get through everything. A shaped charge will get >through more things more violently :) > And in the process, vaporize a signifcant amount of metal - effectively depositing a few microns (at minimum) of metal plating on everything inside the AFV (including passenger's lungs, skin, etc). My first choice would be not to be present for *either* event; far distant second choice would be taking my chances with riccochets. Dave Merriman - - - - - - - - - - - - - - - - - - - - - - - - - - Finger merriman(a)metronet.com for PGP/RIPEM public keys and fingerprints. Unencrypted Email may be ignored without notice to sender. PGP preferred. Remember: It is not enough to _obey_ Big Brother; you must also learn to *love* Big Brother.

1 0

Re: Nuclear Weapons Material
by David K. Merriman 17 Dec '03

17 Dec '03

>> I have seen the exact same chain-gun mounted on F-16's and A-10's here at >> Bergstron AFB in Austin at at least two different air shows. I am going on >> this alone. I do not know if this was ever an active use of the gun. >> > > Are we thinking of the same A-10? Tank-killer? The one that >houses a multi-barrel gun the size of a small car, and fires shells >which could pass for milk bottles in a dark room? I've seen an F-16, and >i don't think it could carry the chain gun off an A-10 - or have i >missed the point somewhere? > I worked a few months in the GE plant where they make these wonderful little toys ("GE - We Bring Good Things To Life" - hah!). The A-10 does indeed use the 30mm cannon, while the fighter aircraft use 20mm. Externally, the guns look *very* similar - you've got to get close enough to count the barrels (which is too damn close, if it _really_ matters :-) to be sure: 20mm uses 6 barrels, 30mm uses 4 (at least, at the time I was there - mid-80's). Either shoots 4,000 rounds/minute. Then you've got everyone's favorite, the 40mm, firing 3,000 rounds/minute through 3 barrels. If you had to compare a 40mm and a milk bottle in a dark room, the milk bottle is probably the small one :-) Not something I'd want to be on the receiving end of, in any case. Of course, we all realize that the size of the ammo refers to the projectile, not the casing, which is typically about half again the projectile diameter, for 'cased' ammo. I got to watch them light off all their little toys, with different types of rounds in them, while there - even after watching Navy guns fire, I was impressed. Dave (ex swab-jockey) Merriman - - - - - - - - - - - - - - - - - - - - - - - - - - Finger merriman(a)metronet.com for PGP/RIPEM public keys and fingerprints. Unencrypted Email may be ignored without notice to sender. PGP preferred. Remember: It is not enough to _obey_ Big Brother; you must also learn to *love* Big Brother.

1 0

Cash, cheaters, and anonymity
by tcmay＠localhost.netcom.com 17 Dec '03

17 Dec '03

Here's a long response. But it's my only post of today, as the list was going on and on about atom bombs, uranium sabots, and alpha particles, and with debate about why some of us are ignoring these posts and the posts of ranters and baiters. This topic is more in line with my reasons for being on this list. Sorry for the length. Hal Finney writes: >One question is the ease of theft in a digital cash environment, and >the consequences of claiming that secrets have been stolen. This >problem was recognized very early on in discussions of digital >signatures. The whole point of a signature is so that someone can be >held to a commitment. But an easy "out" would be to "accidentally on >purpose" let the secret keys be stolen, then to claim that the >signature was actually forged. Contrariwise, a business might >be vicitimized by actually having its secrets stolen and a forged >signature created that committed it to an unfavorable action. Hal is right the problem of *repudiation* or *disavowal* was recognized early on. Alice is confronted with a digital signature, or whatever. She says; "But I didn't sign that" or "Oh, that's my old key--it's obsolete" or "My sysadmin must have snooped through my files," or "I guess those key escrow guys are at it again." APPROACHES TO REPUDIATION **The purist approach: you *are* your key. If another biological unit obtains your key, he or she is effectively you. Guard your key carefully. **The modern American "excuse" approach: Hey, if you want to disavow a contract, like, just claim your key was stolen or, like, you lost it. I understand the reasoning behind adopting a more intermediate stance, but I think that only the purist stance will hold water in the long run.(A hint of this: untraceable cash means, for most transactions of interest with digital cash, that once the crypto stuff has been handled, whether the sig was stolen or not is moot, because the money is gone...no court can rule that the sig was invalid and then retrieve the cash!) [It is true that Chaum went to great lengths to develop system which preserve anonymity for single-spending instances, but which break anonymity and thus reveal identity for double-spending instances. I'm not sure what market forces caused him to think about this as being so important, but it creates many headaches. Besides being clumsy, it require physical ID, it invokes a legal system to try to collect from "double spenders," and it admits the extremely serious breach of privacy by enabling stings. For example, Alice pays Bob a unit of money, then quickly Alice spends that money before Bob can...Bob is then revealed as a "double spender," and his identity revealed to whomver wanted it...Alice, IRS, Gestapo, etc. A very broken idea. Acceptable mainly for small transactions. More on this later.] NEGOTIATED PROTOCOLS TO REDUCE RISKS However, just as most folks make arrangements with their bank/ATM machines (semantic meaning #2 of "ATM") to limit cash withdrawals to, say, $200 a day (it varies), so too can digital cash arrangements make similar contractual deals to limit losses. Some possible plans: * Plan A: The protocol insists on retinal scan or other biometric authentication between the "smartcard" used as the cryptographic keying device and the putative owner. The "Thunderball" plan. (issues: preserving anonymity with biometric authentication, spoofing of the channel between card and physical apparatus, theft of smartcard, etc.) * Plan B: The protocol only allows, say, $1000 per transaction. And no more than 3 transactions per day. Each transaction that is cleared sends a demon message to the account owner through a separate communications channel. (This sounds complex...the idea is to provide a signal that an account is being accessed, allowing the account owner to put a hold on the account. Even if he can't stop the transactions underway, or recently completed, because of the lags that may exist in this feedback, he can limit losses. Kind of a mix between off-line and on-line transactions....such mixes are to be expected, with the choice up to parties, depending on costs, risks, speed of communications, etc.) * Plan C: Use off-line cash only for "small" transactions, such as those now handled with physical coins and small bills. Use on-line clearing for larger amounts, with various forms of biometric security. This echoes how things are done today: off-line cash is what you can carry, in bill, coin specie, etc. Larger amounts (hundreds of dollars and up) is almost always handled on-line, via either credit cards (on-line clearing, albeit not anonymous/untraceable) or checks, cashier's checks, etc. (Coins and cash bills are really "on-line clearing" though, in that their existential properties make them acceptable immediately; they are not replicable, at least not easily, and hence can be conserved in transations. All the usual stuff about the nature of cash money.) Which will be used? (and there are many variants...) As usual, markets will allow choice. Many people will choose to limit exposure with Plan B-type transactions. Others will contract with insurance agents who cover risks by insisting on their own protocols for added security. (I don't mean conventional insurance agents, naturally.) MISCELLANEOUS STUFF >On the other hand, I would hope that people actually can learn to use >care in safeguarding their secrets. The pass words and PINs we use >today may be complemented by physical checks for voice patterns, thumb >prints, perhaps (ironically) handwriting. Another approach would be Most smartcards in use today support some form of local PIN entering, some way to provide a truly memorizable extra piece of identiy. Other biometric measures remain a hot area of research. Stroke recognition, thumbprints, etc. In about 5 years, when I think digital cash will be ready for prime time (pun intended), these additional mechanisms should be deployable, for a price. (Market-driven again: those who want to pay less in insurance will take better steps. Companies may adopt standards. Banks may enforce them.) ... >suggestions (one here a couple of days ago) to use various kinds of >information exchange between the authenticating device and the human >user in order to prove authorization in such a way that even a thief >who has snooped on past exchanges will not be able to use the device. >This approach is sometimes called the use of "pass algorithms". "Zero knowledge interactive proof systems" have been used for password systems; no amount of past snooping or eavesdropping helps. (Of course, the user still has to have physical security over his local computer, or PDA, dongle, or secret decoder ring.) This seems like a readily-solvable problem (and one we already accept with existing ATM machines). THE INCREDIBLE IMPORTANCE AND ELEGANCE OF ON-LINE CLEARING ... >Applying this to the double-spending case, I suspect that Bob Hettinga >is more on the right track in seeing the solution in the legal system >rather than a simple "shucks, you caught me" forfeiting of a bond >worth triple damages. There really should be no excuse for double *On-line clearing* for larger amounts is, in my opinion, the Right Thing. Networks are getting deployed widely and are speedy. ATM, SONET, ISDN, and all the rest. I want to elaborate on this, even though I think most of Hal's points are made with off-line clearing in mind. I want to make the case for why on-line clearing is the One True Digital Cash. Conceptually, the guiding principle idea is simple: he who gets to the train locker where the cash is stored *first* gets the cash. There can never be "double spending," only people who get to the locker and find no cash inside. Chaumian blinding allows the "train locker" (e.g., Credit Suisse) to give the money to the entity making the claim without knowing how the number correlates to previous numbers they "sold" to other entities. Anonymity is preserved, absolutely. (Ignoring for this discussion issues of cameras watching the cash pickup, if it ever actually gets picked up.) Once the "handshaking" of on-line clearing is accepted, based on the "first to the money gets it" principle, then networks of such clearinghouses can thrive, as each is confident about clearing. (There are some important things needed to provide what I'll dub "closure" to the circuit. People need to ping the system, depositing and withdrawing, to establish both confidence and cover. A lot like remailer networks. In fact, very much like them.) In on-line clearing, only a number is needed to make a transfer. Conceptually, that is. Just a number. It is up to the holder of the number to protect it carefully, which is as it should be (for reasons of locality, for self-responsibility, and because any other option introduces repudiation, disavowall, and the "Twinkies made me do it" sorts of nonsense). Once the number is transferred and reblinded, the old number no longer has a claim on the money stored at Credit Suisse, for example. That money is now out of the train locker and into a new one. (People always ask, "But where is the money, really?" I see digital cash as *claims* on accounts in existing money-holding places, typically banks. There are all kinds of "claims"--Eric Hughes has regaled us with tales of his explorations of the world of commericial paper. My use of the term "claim" here is of the "You present the right number, you get access" kind. Like the combination to a safe. The train locker idea makes this clearer, and gets around the confusion about "digimarks" of "e$" actually _being_ any kind of money it and of itself.) Off-line systems may be useful for paying for movies, toll roads, etc., but there the protocols can be set up to limit exposure to fraud. (Ontological constraints, such as number of movie theater attendees, etc., will limit the losses. Scams will likely still exist, but the problem seems manageable with some work.) And as networks get much faster, expect even off-line cash to fade. Depends on costs, insurance rates, benefits, and of course on regulations. >spending, even of a penny, and the penalties could be made strong >enough to deter most people. If a bank does not think they will be >able to find and prosecute a person who is withdrawing off-line >digital cash, they will probably not give any to him. Then if the The "first to the locker" approach causes the bank not to particularly care about this, just as a Swiss bank will allow access to a numbered account (or used to...please let's not have a dozen posts arguing about this, as is so often the case on this list!) by presentation of the number, and perhaps a key. Identity proof *may* be needed, depending on the "protocol" they and the customer established, but it need not be. And the last thing the bank is worried about is being able to "find and prosecute" anyone, as there is no way they can be liable for a double spending incident. The beauties of local clearing! (Which is what gold coins do, and paper money if we really think we can pass it on to others.) IS PROOF OF PHYSICAL IDENTITY NEEDED? ... >money is double-spent, the person who withdrew it would be prima facie >responsible, with a reasonable presumption that they did it unless >there is significant evidence otherwise. I don't know that this is >how it will work out but it is one possibility (unless the uncertainty >just scares everybody away - but I think the digital signature >experience will get people used to the concepts and problems). I recall some analyses of these situations a while back. I looked in my "Crypto" Proceedings but didn't find it. The danger of making the "person who withdrew it" a culprit if the money has already been "spent" is clear: he is just as likely to be an innocent victim of a setup as the guilty party. With off-line clearing, and not the "handshaked" beauty of immediate clearing, one has to rely on "trust"--tough with an anonymous person. On-line clearing has the possible danger implicit in all trades that Alice will hand over the money, Bob will verify that it has cleared into his account (in older terms, Bob would await word that his Swiss bank account has just been credited), and then Bob will fail to complete his end of the bargain. If the transaction is truly anonymous, over computer lines, then of course Bob just hangs up his modem and the connection is broken. This situation is as old as time, and has always involved protcols in which trust, repeat business, etc., are factors. Or escrow agents. REAL ESCROW AND TRUE NYMS Long before the "key escrow" of Clipper, true escrow was planned. Escrow as in escrow agents. Or bonding agents. Alice and Bob want to conduct a transaction. Neither trusts the other; indeed, they are unknown to each other. In steps "Esther's Escrow Service." She is _also utraceable_, but has established a digitally-signed presence and a good reputation for fairness. Her business is in being an escrow agent, like a bonding agency, not in "burning" either party. (The math of this is interesting: as long as the profits to be gained from any small set of transactions is less than her "reputation capital," it is in her interest to forego the profits from burning and be honest. It is also possible to arrange that Esther cannot profit from burning either Alice or Bob or both of them, e.g., by suitably encrypting the escrowed stuff.) Alice can put her part of the transaction into escrow with Esther, Bob can do the same, and then Esther can release the items to the parties when conditions are met, when both parties agree, when adjudication of some sort occurs, etc. (There a dozen issues here, of course, about how disputes are settled, about how parties satisfy themselves that Esther has the items she says she has, etc.) UNTRACEABLE MARKETS FOR ASSASSINATIONS To make this brutally concrete, here's how escrow makes murder contracts much safer than they are today to negotiate. Instead of one party being caught in an FBI sting, as is so often the case when amateurs try to arrange hits, they can use an escrow service to insulate themselves from: 1. From being traced, because the exchanges are handled via pseudonyms 2. From the killer taking the money and then not performing the hit, because the escrow agent holds the money until the murder is verified (according to some prototocol, such a newspaper report...again, an area for more work, thankfully). 3. From being arrested when the money is picked up, as this is all done via digital cash. There are some ways to reduce the popularity of this Murder, Incorporated system. (Things I've been thinking about for about 6 years, and which we discussed on the list and on the Extropians list. I'll save this for another time.) My point here is to show how on-line clearing works in conjunction with an escrow agent function.(Esther clears the cash, and can issue new cash to Bob, who "trusts" her that if he does the job, the cash will clear, as she's the escrow agent he's dealt with many times before.) THE DANGER OF EVER USING PHYSICAL IDENITY VERIFICATION >The other point I wanted to discuss was this issue of the bank >authenticating the people who receive the cash. This does raise the >spectre of a big brother system where there is some way to identify >people with 100% certainty. Obviously this could be abused. Danger! Danger! Danger! Any such system, that relies on physical IDs is substantially less private that banks today in many countries, and is not at all what I would call "digital cash." On-line clearing makes this unnecessary. >Without the authentication, you're not going to have off-line cash, >IMO. You will be stuck with on-line systems in which everyone has to >verify everything before accepting it. This means you pay a cost in >communications overhead and possibly other foregone opportunities. Agreed. But acceptable with a two-tiered system: - off-line cash for small transactions, with smartcards, "observer" protocols, and with built-in limits - on-line , immediately-cleared cash for larger transactions, also with various agreed-upon limits or requirements RISKS Is there a danger that people will lose the numbers that they need to redeem money? That someone could steal the number and thus steal their money? Sure. There's the danger that I'll lose my bearer bonds, or forget my Swiss bank account number, or lose my treasure map to where I buried my money (as Alan Turing supposedly did in WW II). People can take steps to limit risk. More secure computers. Dongles worn around their necks. Protocols that involve biometric authentication to their local computer or key storage PDA, etc. Limits on withdrawals per day, etc. People can store key numbers with people they trust, perhaps encrypted with other keys, can leave them with their lawyers, etc. All sorts of arrangements can be made. Where I'm not sure I agree with what Hal is saying is that _personal identification_ is but one of these arrangements. Often used, but not essential to the underlyng protocol. Again, the Swiss banks (maybe now the Liechtenstein anstalts are a better example) don't require physical ID for all accounts. (More generally, if Charles wants to create a bank in which deposits are made and then given out to the first person who sings the right tune, why should we care? This extreme example is useful in pointing out that _contractual arrangements_ need not involve governmental or societal norms about what constitutes proof of identity.) PAPIEREN, BITTE Hal goes on to talk about blinded credentials. A very important idea in our permission slip-happy society, and an idea that is not getting nearly enough attention. (Chaum's seminal "Transaction Systems to Make Big Brother Obsolete," from Oct or Nov of 1985, in "Communications of the ACM," remains required reading here.) But I also take a more radical view. Ask yourself why credentials are _ever_ needed. Maybe for driving a car, and the like, but in those cases anonymity is not needed, as the person is in the car, etc. Credentials for drinking age? Why? Let the parents enforce this, as the argument goes about watching sex and violence on t.v. (If one accepts the logic of requiring bars to enforce children's behavior, then one is on a slippery slope toward requiring television set makers to check smartcards of viewers, or of requiring a license to access the Internet, etc.) In almost no cases do I see the need to carry "papers" with me. Maybe a driver's license, like I said. In other areas, why? This gets to a core issue: the incredible benefits of locally clearing a transaction. Caveat emptor, buyer beware, etc. Cash on the barrelhead. In transactions where "future performance" is needed, as in a contract to have a house built, or to do some similar job, then of course the idea of on-line or immediate clearing is bogus...like paying a stranger a sum of money on his promise that he'll be back the next day to start building you a house. Parties to such long-term, non-locally-cleared cases may contract with an escrow agent, as I described above. This is like the "privately-produced law" we've discussed so many times. The essence: voluntary arrangements. Maybe proofs of identity will be needed, or asked for, maybe not. But these are not the essence of the deal. An interesting area. I apologize if this essay, while long, is not quite long enough to capture the ideas I wanted to express. To me, these are core ideas. Maybe not as core to those of you who favor talking about depleted uranium sabots (but what about Chobham armor and explosive armor?) or about "PGP rulz, d00d!," but core isseus to me. Your smileage may vary. --Tim May .......................................................................... Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay(a)netcom.com | anonymous networks, digital pseudonyms, zero 408-688-5409 | knowledge, reputations, information markets, W.A.S.T.E.: Aptos, CA | black markets, collapse of governments. Higher Power: 2^859433 | Public Key: PGP and MailSafe available. "National borders are just speed bumps on the information superhighway."

5 6

Re: Nuclear Weapons Material
by jkbacon＠pacifier.com 17 Dec '03

17 Dec '03

> I was under the impression that the most common techniquoe for >creating armour-piercing munitions was to use shaped-charges. While >depleted uranium has it's uses (being, as someone said, rather dense), >mass alone will not get through everything. A shaped charge will get >through more things more violently :) > Depleted uranium is used in armor piercing rounds for three reasons: 1. High density 2. High hardness - not quite that of tungsten, but its up there. 3. Upon impact it ignites (like magnesium) and burns. The burning uranium melts steel and also produces uranium oxide in the process. If this isn't "violent" enough, try fission. Kirk

2 1

No Subject
by Anonymous 17 Dec '03

17 Dec '03

I thank Hal Finney for his thoughtful reply, and Tim May for his excellent essay. It looks like we can start to draw a stronger conclusion: there are serious holes in the assumptions made by offline digital cash protocols when applied to computer networks rather than manually operated smart cards. Hal's comparison of coin theft to digital signature protection and repudiation is apt, but usually Irving only has one or a few keys to protect, while he might have thousands of coins, issued by various banks. I doubt digital signatures will ever be used alone much for signing expensive contracts. A digital signature on an expensive contract, in addition to being repudiable, will be suspicious, since if few people accept such signatures as strongly binding (the initial state), they will not be widely used on expensive contracts, and thus their existance on an expensive contract will be suspicous. I predict it will become common practice, or even law, that digitally signed contracts over a certain amount are automatically invalid unless further precuations have been taken (signatures of notary witnesses, or perhaps some better crypto protocol designed for this purpose). The trouble with offline cash in a network environment is that the upper limit for fraud liability can be incredibly high. If there are hundreds of thousands of vendors on the net, a situation CommerceNet predicts before the end of the decade, and they are using this offline protocol, then even with small transactions the fraud could run into the millions of dollars. There's plenty of incentive for Irving to steal Jane's coins, run off to some place on the net that has no extradition treaty, and pump good change out of the vendors and into his Lichtenstein account to his heart's content. We may yet find protocols to mitigate or limit this kind of fraud -- make change traceable if linked to double spending, do random online checks as a cypherpunks poster suggested last year, or similar precautions layered on top of the basic protocol. But so far these problems haven't been put on the front burner of digital cash design, and already we have people out there selling offline cash on the network as a superior solution! Reliance on law enforcement flies in the face of cypherpunk goals, and indeed against the goals of good cops as well -- one of their most vocal complaints is about people setting up systems that are vulnerable to crime, putting them in unecessary danger. It also goes against political reality to think that a startup operation can lobby governments all across the globe to protect a system that is ideal for money laundering and tax evasion. Ain't gonna happen -- they'll let those "dirty money banks and money laundering net sites" rot; they may even give Irving a helping hand. I disagree that "there is no excuse" for double spending. If the software is implemented badly (no fault of the user), it might get mixed up with systems programs in such a way as to cause double spending. For example, if the system crashes and one must recover from a month old backup, one has to go through that old purse and determine which coins have been spent. If the software and/or user makes a mistake in this process, we get double spending. If a network burps and sends a vendor two coins where there should have been one, we get double spending. The possibilities for accident are legion and cannot all be foreseen. "Shit happens". A protocol that treats common accident the same as criminal fraud, when the stakes are so high, is pathological. In the online system the consequences of double spending (or million spending) are far more benign. At worst one customer is out stolen coins. In a networked offline system those same few coins are a potential loss for every vendor on the net. As Tim May noted, we may not even need to recongize fraud in online cash -- just treat all online double spending as accident. No bonding, secured accounts, investigators, ID badges or cops with guns busting down Janes's door after Iriving has million-spent her coins. Here we both have a simple liability system and much less chance of fraud. Tim May also suggested that most offline protocols are intended for manually used smart cards. This makes sense -- unlike an network environment with automated spending agents, the scope of multi spending for manually used pruchases in small amounts is quite limited. On the network even fraud of a few cents per transaction can quickly add up to big $$$ across thousands of vendors. What are the communications costs of online clearing, anyway? Don't credit card clearings cost about two cents per transaction these days? If clearing costs are less than plausible offline cash fraud and fraud prevention costs, online cash is a winner, both now and increasingly in the future as bandwidth becomes even cheaper. sincerely, -- An Unauthenticated Agent with no credentials: WYSIWYG

3 2

Re: U & Pu is good for U
by jdd＠aiki.demon.co.uk 17 Dec '03

17 Dec '03

In message <199408252138.OAA15395(a)well.sf.ca.us> Brad Dolan writes: > >On the other hand I say that such studies are poor criteria for > >judging the effects of radiation intended to do the maximum possible > >harm. > > Well, these studies are about all we have to go on right now. The > wartime residents of Hiroshima and Nagasaki do provide a large set of > folks exposed to "radiation intended to do the maximum possible harm" > but, darn it, none of them were wearing dosimeters. People do study > these groups, making educated guesses about doses, but it's hard to > draw precise conclusions on that basis. There is a Sufi parable about a guy who loses something on a dark street. His friend finds him searching the ground carefully at the corner under a street light. He asks him what he is doing, and he explains that he dropped something. "Where?" "Down the street." "Then why are you looking here?" "Because there is a light down here." -- Jim Dixon

1 0

Re: (Fwd) Something of Interest (fwd)
by Jim Choate 17 Dec '03

17 Dec '03

Hi, I would like to add one thing, jf_avon(a)ssz.com doesn't exist as a valid user account or alias on any ssz.com system. ____________________________________________________________________ | | | _____ The Armadillo Group | | ,::////;::-. Austin, Tx. USA | | /:'///// ``::>/|/ http:// www.ssz.com/ | | .', |||| `/( e\ | | -====~~mm-'`-```-mm --'- Jim Choate | | ravage(a)ssz.com | | 512-451-7087 | |____________________________________________________________________| Forwarded message: > From owner-cypherpunks(a)ssz.com Sun Jul 20 01:15:32 1997 > Message-Id: <199707200622.XAA18842(a)baker.cnw.com> > From: "Blanc" <blancw(a)cnw.com> > To: <cypherpunks(a)toad.com> > Subject: Re: (Fwd) Something of Interest > Date: Sat, 19 Jul 1997 23:31:08 -0700 > MIME-Version: 1.0 > Content-Type: text/plain; > charset="iso-8859-1" > Content-Transfer-Encoding: 7bit > X-Priority: 3 > X-MSMail-Priority: Normal > X-Mailer: Microsoft Outlook Express 4.71.0913.4 > X-MimeOle: Produced By Microsoft MimeOLE Engine V4.71.0913.6 > Sender: owner-cypherpunks(a)ssz.com > Precedence: bulk > X-Mailing-List: cypherpunks(a)ssz.com > X-List-Admin: list(a)ssz.com > X-Loop: ssz.com > From: jf_avon(a)ssz.com > > |I received this out of the blues. I suppose that you received it > |too. > ........................................................... > > > I didn't receive it, and I set off quite a round of discussion with Jim & the > list, at one point. Guess I'm not considered controversial enough to get it. > :>) > > .. > Blanc > >

1 0

PGP, digicash, and tanks
by dfloyd＠runner.utsa.edu 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- The idea of DigiCash is a good one, and there have been many good ideas on it, but it will be hard to implement it in the US. The IRS will want to stop it cold as it gets around them, some people will fear it "The cash for PEDOPHILES", and Joe Blow will probably have a tough time getting used to it as it is very new to him. Another problem is being able to trust the bank who holds the notes. It will have to be a stable institution which does this, one that the IRS most likely has a grip on, or can get one. The SEC will probably want their way also. As to having PGP on a unix box, and the risks of this, I have a solution to this. What I do is keep my key on my Linux box at home, and have my mail forwarded there. It then is simple to reply and decode messages. pgpdaemon and pgpsendmail also help a lot with the quick encodes and decodes. As to tank rounds, aren't we getting a bit off track here? -----BEGIN PGP SIGNATURE----- Version: 2.6 iQCVAgUBLl3cdHDkimqwdwa5AQEO4wP/ZBX5ecquikmxVHVGDz7Hutg8ryX1taJK l4aVy10uHAv5wE4KptFq3k5enqKsdot3nJsG33GLCfsrcpm2qz1snwAvh+5WmK6y f7AnSJlx671dM9334qoKAuVpLahWFpmmWuoROSXx4rx3zSVIXKjkrWaSJLAHP0Ay cAY0quBcfhw= =r48u -----END PGP SIGNATURE-----

1 0

Re: Fast modular exponentiation
by Pat Farrell 17 Dec '03

17 Dec '03

Phil Karn <karn(a)unix.ka9q.ampr.org> writes: > I.e., if I come up with a list of clock counts for each basic > arithmetic instruction, how can I tell which algorithm is probably > best for my machine? Back in the days of Mix, Knuth worked out the model. But with modern pipelined chips with significant on-chip cache, the model becomes too complex to solve arithmetically. The usual solution is to use Berkeley's Architect's Work Bench (AWB) which allows you to model the chip's instruction set, cache structure, pipeline stall characterists, etc. while using a compiler to generate actual code to execute. You can then execute your algorithm against the chip, and declare a winner. Of course, you have to validate the chip model, and you have to know how the compiler optimizations work, how it interacts with branch prediction logic, etc. While awb is readily available for the usual Unix systems, using it for anything less trivial than a grad school compiler optimization course is a ton of work. It makes sense when you are inventing a new chip architecture, or even a significant revision to an existing chip. I believe that it is far too much work to use awb (or anything of similar capabilities) to evaluate algorithms for real world chips. For algorithm optimization, it makes more sense to study the chip's characteristics, and use a heuristic approach, testing real implementations. I've already measured nearly a four to one difference in execution times using Phil's DES code using different compilers and operating systems on the same hardware (my 486). But it is pretty unsatisfying to say that the best algorithm "depends" on half a dozen variables, and that we can't reliably predict (engineer) a solution. Pat Pat Farrell Grad Student pfarrell(a)cs.gmu.edu Department of Computer Science George Mason University, Fairfax, VA Public key availble via finger #include <standard.disclaimer>

1 0

Re: DSPs
by jdd＠aiki.demon.co.uk 17 Dec '03

17 Dec '03

In message <199408260422.VAA16628(a)unix.ka9q.ampr.org> Phil Karn writes: > I'm not really an expert on DSPs, but it does seem like they should be > good for modular exponentiation given the number of multiplies required. > But I don't think I'm the first to point that out. DSPs are actually optimized for the operation required in the FFT: integer inner products. A DSP will have hardware for extremely fast summations of expressions like c[i]*x[i] where the c[i] are constants, and new x vectors are introduced at a high rate. This is somewhat different than the kind of fast multiplication you are looking for. -- Jim Dixon

1 0