- cypherpunks-legacy - lists.cpunks.org

Re: NSA Realists v. Nuts (Was: Re: Crypto APIs)
by James A. Donald 17 Dec '03

17 Dec '03

At 05:02 PM 10/5/95 -0400, Perry E. Metzger wrote: > >"James A. Donald" writes: > > They want to rule over us. [...] There is no commonality of > > purpose, hence no possibility of cooperation. At 05:02 PM 10/5/95 -0400, Perry E. Metzger wrote: > I disagree. Most NSA types are probably stock government employees > who want to get their job done with the least muss and fuss. > > [...] > > I don't think the NSA is inherently the enemy at all. Signals > intelligence and protecting the U.S. and its citizens from signals > intelligence is probably necessary. Naturally members of an organization wish the organization to become great and powerful: A great and powerful Netscape would be a Microsoft. A great and powerful NSA would be a KGB or an SS. Naturally everyone likes their job to meaningful, everyone likes their job to have an impact. Everyone wants to be important. If the NSA are eyes without hands, they are impotent, they are useless. So they want hands. They want information about us to be used by the government, which means they want the government to exercise detailed control over us in response to their detailed information about us. Our function lust would, if fulfilled, give us only moderate satisfaction, their function lust, if fulfilled, would give them vast power, and hence vast satisfaction. Our function lust, if fullfilled, would give us more power over computers. Their function lust, if fullfilled, would give them more power over us. > However, in general, what you are looking at is just the > result of an entity trying to preserve itself having access to > governmental force. I doubt that there are many "national domination" > types in the agency, Despite grandstanding by the republicans, no government agency has ever been closed down, or suffered layoffs, merely because its function became completely obsolete. (Though some have suffered renamings and reshuffles, and some have been allowed to shrink through natural attrition) The guys who used to control prices in the trucking industry now work full time regulating each other. (I kid you not) We are still stockpiling helium to lift a fleet of dirigibles for world war one. (Like Dave Barry, I am not making this up, though the Republicans have planned to close down the helium agency.) Job preservation is irrelevant: They are government employees. Power is the issue. --------------------------------------------------------------------- | We have the right to defend ourselves | http://www.jim.com/jamesd/ and our property, because of the kind | of animals that we are. True law | James A. Donald derives from this right, not from the | arbitrary power of the state. | jamesd(a)echeque.com

1 0

Re: FORGED CANCELS of posts on n.a.n-a.m
by Erik E. Fair 17 Dec '03

17 Dec '03

An NNTP v2 protocol specification effort is underway in the IETF now. Strictly to clean up existing extended practice - not to do new things. Erik Fair

1 0

PC disk wipe software
by Perry E. Metzger 17 Dec '03

17 Dec '03

I thought I'd ask here, since its related to a lot of the stuff people have written for the PC platform in these parts. I need to securely wipe a bunch of data from an MS-DOS hard drive, so that it can't be recovered. Are there any readily available utilities for this? Will any of them selectively erase only data that isn't allocated to existing files? Perry

5 4

Re: Certificate proposal
by Hal 17 Dec '03

17 Dec '03

Bob Smart <smart(a)mel.dit.csiro.au> writes: >Consider the IPSEC case. The current situation is: >1. We go through some process, let's call it Process A, where we determine > that we want to talk to IP address 192.9.8.7. This would be, say, a DNS lookup on www.egghead.com. >2. We go through another process where we obtain the public key of 192.9.8.7. I get it by connecting to that IP address and asking for it, or perhaps I have it cached or I get it from some public cache. >3. We then try to decide, based on one or more certificates, whether we > trust the public key to be the correct public key for 192.9.8.7. I see the certificate is signed by someone I trust and it certifies that this key is good for connections to Egghead Software at www.egghead.com. >Now consider the key-centric version. >1. Process A returns a public key which denotes the destination we want to > talk to. OK, maybe this is some DNS variant that given www.egghead.com, returns a public key 0x12345678. >2. We then go through a process to obtain the IP address that belongs to > that public key. We probably won't use the public key as an index to > get that information. We probably use the information that was input > to Process A. In fact this information may fall out as a byproduct > of Process A. [However if we needed to make a scalable distributed > database of RSA public keys then I have a design to do this - > available on application.] OK, so now I do another DNS lookup on www.egghead.com to get the IP address. Or maybe I even use key 0x12345678 as an alternative index to get that address. >3. We don't need to trust any certificates or anything else at this stage. > The fact that the IP address belongs to the Public Key is signed by > the Public Key itself. Now you've lost me. Are you saying that the key is self-certifying, saying "I belong to 192.9.8.7"? That is, it is accompanied by a signature issued by that key itself on this IP address? I hate to be difficult, but this does not provide me with a warm feeling. Anyone could have issued that key, claiming to belong to that IP address. If the person who did so is able to interpose himself between me and that address then my messages are not secure. >The same thing happens with e-mail. If "Process A" gives us an e-mail >address to send to then we worry about whether we have the right public >key to go with it. If Process A gives us a Public Key then we can >have certainty about the associated e-mail address because the association >is signed by the Public Key. Again, I don't follow how we gain this certainty. >And a big win that just falls out of this is that I can have a >continuous exchange of information with one IP destination even if >it keeps changing its actual IP address (mobile computing) or I >can have an e-mail conversation with a person who keeps changing >their e-mail address. The things you want just fall out instead of >requiring clever software solutions. This can be dealt with in the certificate context by having a certificated key sign a statement that the IP address is now such-and-such. >In the key-centric world a certificate binds some attribute as a property >of a publc key. So an X.509 certificate would say "The owner of this >public key [i.e. person who knows the corresponding private key] owns >the following point in the X.500 namespace", rather than that "the >person identified by this DN owns the following publc key". Experience >has shown that the latter interpretation is a mine-field. It really >doesn't work. I don't really care whether the name is called an attribute, a distinguished name, or an ooblek. I just don't see how you're going to get along without it. The fact is, we live in a world populated by people and companies and we use names to identify them. I will grant that there are problems with uniqueness but I don't think the solution can be to just give up on the whole idea of names since they are so messy. Pretending that keys are communicating beings is not going to work. Hal

3 2

Re: Simple Hardware RNG Idea
by norm＠netcom.com 17 Dec '03

17 Dec '03

Simon Spero writes: .... > What about a beam of high intensity ionising radiation aimed at the > detector? .... You presumably use the oddness of the count for your random bit in some predetermined time interval. External radiation can change, but not bias the parity. If the counter saturates, the counter may be biased towards one parity but the software can easily detect saturation presuming it gets the count. You can use the source in a smoke detector.

2 1

Re: GC Tech GlobeID pilot
by Jay Campbell 17 Dec '03

17 Dec '03

> http://globeid.gctech.fr/cgi-gid/welcome?Language=English >Sorry again, but because real content is and will be available >we commited to deliver only a few hundreds Web Wallets for this >pilot. You can still use the web form to apply for one... Except for this clause... | Caution: Following form is provided for demonstration purpose only. | If you really want to participate to the Globe ID electronic wallet pilot | program, please contact Mr. Pierre Edelman or GID95(a)GCTech.fr. On the surface, this doesn't look much different than First Virtual or any of the myriad other "let me hold your credit card number for you" sites. -- Jay Campbell - Regional Operations Manager -=-=-=-=-=-=- Sense Networking (Santa Cruz Node) edge(a)you.got.net "Shoot the Fruit Loop" 408.469.9400 "On the Information Superhighway, I'm the guy behind you in this morning's traffic jam leaning on his horn."

1 0

(cpx) Mastercard, IBM, Netscape, CyberCash and GTE publish SEPP
by rah＠shipwright.com 17 Dec '03

17 Dec '03

--- begin forwarded text To: e-payment(a)cc.bellcore.com, ietf-payments(a)cc.bellcore.com, www-buyinfo(a)allegra.att.com Subject: Mastercard, IBM, Netscape, CyberCash and GTE publish SEPP Mime-Version: 1.0 Date: Thu, 05 Oct 1995 16:12:23 -0400 From: Amir Herzberg <amir(a)watson.ibm.com> MasterCard's Secure Electronic Payment Protocol is now available on the WWW at http://www.mastercard.com/Sepp/sepptoc.htm (without the `l'). This protocol is based on iKP but includes much more details. You can download it from the page above until we `re-hash' it into Internet Draft form. Comments are very welcome, and I suggest we use the e-payment mailing list for them (until an IETF working group is formed). I believe that the publication of this spec and the STT spec suggests that we should in fact proceed now with establishing a working group. So, I plan to submit an updated charter soon... Comments on it are also welcome. Best, Amir Text version of the page: Secure Electronic Payment Protocol Specification The development of electronic commerce is at a critical juncture. Consumer demand for secure access to electronic shopping and other services is very high; merchants want simple, cost-effective methods for conducting electronic transactions; financial institutions want a level-playing field for software suppliers to ensure quality products at competitive prices. The next step to achieving secure, cost-effective on-line transactions at a rate fast enough to satisfy market demand, is the development of a single, open industry specification. The generally accepted process for developing a technical standard or specification within an industry is comprised of five steps: Collaboration of interested parties Preparation of the document Availability of the document for comment Modification of the document based on the comments Publication of the document for implementation. In a effort to develop a specification for securing bankcard transactions over the Internet and other open networks, IBM, Netscape, GTE, CyberCash and MasterCard have cooperatively developed the following draft document, which is now available for review and comment. Each company brought unique and valuable experience to the effort. The result of this collaboration is Secure Electronic Payment Protocol (SEPP) an open, vendor-neutral, non-proprietary, license-free specification for securing on-line transactions. Currently in draft form, this document is available for review and comment by all interested parties. It also will be sent to Internet standards-setting bodies, including the Internet Engineering Task Force. Once comments are received, modifications will be made and a final document will be published in the public domain. Access to SEPP Specification This specification is structured in five files in order to make downloading easier: Preface: This file provides an overview of the entire SEPP document. Postscript (.Z), Postscript (.zip), Postscript (.hqx), Mac OS (Word 5.1[.hqx]) If you'd like to browse just this part, Click Here. Part 1 - Business Requirements: This file defines the major business requirements for secure electronic payments. Postscript (.Z), Postscript (.zip), Postscript (.hqx), Mac OS (Word 5.1[.hqx]) Part 2 - Functional Specification: This file contains the functional specification for the payment process and the certificate management system. Postscript (.Z), Postscript (.zip), Postscript (.hqx), Mac OS (Word 5.1[.hqx]) Part 3 - Payment System Specification: This file defines the detailed design for the payment system. Postscript (.Z), Postscript (.zip), Postscript (.hqx), Mac OS (Word 5.1[.hqx]) Part 4 - Certificate Management Specification: This file defines the detailed design for the Certificate Management System. Postscript (.Z), Postscript (.zip), Postscript (.hqx), Mac OS (Word 5.1[.hqx]) --- end forwarded text ----------------- Robert Hettinga (rah(a)shipwright.com) Shipwright Development Corporation, 44 Farquhar Street, Boston, MA 02131 USA (617) 323-7923 "Reality is not optional." --Thomas Sowell >>>>Phree Phil: Email: zldf(a)clark.net http://www.netresponse.com/zldf <<<<<

1 0

Nov. meeting: Austin, Tx
by Jim Choate 17 Dec '03

17 Dec '03

Hi all, The next meeting of the Austin Cypherpunks will be on Nov. 7 from 6-8pm at Ted's Greek Restaraunt on Congress at 4th. near Oscar Snowden. We will be meeting in the rear. The get together yesterday was pretty well attended with 5 person as well as Strick from the California cpunks. Thanks to those who attended and hope to see more of those who didn't at the next meeting. Jim Choate CyberTects ravage(a)einstein.ssz.com

1 0

Re: NetManage & Cylink Crypto
by Andrew Loewenstern 17 Dec '03

17 Dec '03

Anonymous wrote: > The link with Cylink will allow NetManage to license and include > the Cylink public key encryption technology in its applications > with a variety of ciphering systems to be used in the NetManage > suite, including: DES, Triple DES, Safer, IDEA, Skipjack, RC-2, ^^^^^^^^ > and RC-4. Hey, this is interesting... will Skipjack be included in future NetManage products or is this press-release only mentioning Skipjack as an example of a possible encryption algorithm for use with NetManage? andrew "Gentlemen, start your disassemblers."

1 0

Re: NSA Realists v. Nuts (Was: Re: Crypto APIs)
by David Van Wie 17 Dec '03

17 Dec '03

Perry E. Metzger wrote: >The real problem with the NSA is the same as the problem with the FBI >re: digital telephony. They've gotten used to a certain model of how >the world works and rather than adapt to new times where most people >have access to strong crypto, they have decided to use the laws to try >to retard the inevitable. Perry is absolutely right about this. We have been living in a "golden era" for the FBI and NSA. By analogy, we have also been living in a golden era for physicians: during the last several decades (in the developed world anyway) we have relied on antibiotics to the point where they are taken for granted. This time has passed, and there is no going back. The Golden Age of Antibiotics is over. Similarly, the Golden Age of Wiretaps is over. No amount of wishful thinking and convoluted logic can put the genie back into the bottle. An attempt to (in effect) make certain types of mathematics illegal will only serve to knock us out of our technological leadership position, not make our country safe from terrorism and drugs. Given a world in which strong crypto is actually used, and that use is illegal, how can a government make the punishment fit the crime? Would all use of illegal cryptography be treated as though there was an actual threat of terrorism? The death penalty? This is, of course, an absurd point of view. The government could no more accomplish this than they could make muttering over the phone (thereby defeating a plaintext wiretap), or the use of obscure language (such as Native American dialects) illegal. It just doesn't hang together as a rational approach. Like physicians, the FBI and the national security operations must devise alternative schemes to combat the real "enemy," terrorists and drug dealers -- not mathematicians and ordinary citizens trying to have a private conversation. The suppression of basic rights that would be required in any attempt to overcome the "force of nature" that is human knowledge would make a mockery of our "inalienable rights" as free people to conduct our lives without fear of the overbearing scrutiny of unrestrained government. dvw

1 0