December 2003 - cypherpunks-legacy

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