December 2003 - cypherpunks-legacy

Re: The dumbest question...
by smb＠research.att.com 17 Dec '03

17 Dec '03

... is the one you don't ask. So here I go... #1 Isn't "part of the deal" of patent granting a requirement that the details of the thing being patented be revealed. If so, why isn't IBM required to reveal the details of s-box design? After all, they hold the patent on DES. They revealed the values of the S-box. Unless the patent included claimes relating to its design criteria, they didn't have to disclose them. Of course, then they wouldn't be protected if someone else were to reinvent and use those criteria in a cipher that isn't covered by other parts of the DES patent. #2 Skipjack has a 80 bit key which is proposed to be "escrowed" in two parts. Now considering that the likeliest attack on DES is a brute force key search of 2^55 keys, isn't it true that a compromise of one half of a "Clipper key" would allow a brute force attack to "discover the remaining 40 bits. If 2^55 is possible, then 2^40 is even easier, no? As several people have pointed out today, the two halves are 80 bits apiece, and they're XORed together to make the full key. You can't do a brute-force search on 80 bits.

1 0

LPC10 and CELP implementations
by Jim Nitchals 17 Dec '03

17 Dec '03

I'm working on implementing both of the above on Mac platforms, on an unofficial basis (I work for Apple.) The CELP decoder ran in realtime on a IIci (030) class Mac by recoding everything in integer instead of FP, but the encoder was too CPU intensive. Making the decoder even run was a big chore, involving a lot of rewrite and some assembly language in the worst parts. So I've set aside CELP for the time being, and will later see if it runs well on PowerPC. The LPC10 algorithm posted on super.org (along with CELP3.2a) is, like CELP, floating point intensive. I'm going to get both running on PowerPC native first, then recode LPC10 in integer and see if it will run in full-duplex on an '030 or '040 later. On a IIfx (fast '030), LPC10 requires about 7x realtime to process prerecorded sample speech. That's encouraging, because on CELP the changeover to integer sped up processing by about a factor of 7. The source code for LPC10 is clearly marked "NSA", which would make it especially ironic :) if someone happens to use my port in a secure voice application, subject to what Apple wants to do with my work. CELP at 4800 bits/second sounds very reasonable, and LPC10 at 2400 is quite passably intelligible although a bit robotic. I could improve LPC10's intelligibility with a little redesign but not without blowing off bitstream compatibility. If I built an improved speech coder (at 9600 or 14.4k bit/second) I'd have to find volunteers to port it to DOS & Windows boxes, or keep it proprietary to Apple. If anyone here is working on a secure voice application, may I suggest background file transfer capabilities. LPC10 leaves a lot of unused bandwidth on a 14.4k baud modem! Anyone interested in collaborating, or getting a current-status report at any time is welcome to write to me. I promise to keep it technical and avoid ranting & raving about Dorothy Denning :) Joe Campbell hasn't yet returned my recent message commenting on bugs and asking clarification on commercial use of the source. If Apple doesn't get clear rights to use it in system software I'll probably just post the improved versions to an ftp site somewhere and let it go at that. --------------------------------------------------------------------------- "UN-altered REPRODUCTION and DISSEMINATION of this IMPORTANT Information is ENCOURAGED." - R. McElwaine

1 0

(help with "To" field?)
by jimn8＠netcom.com 17 Dec '03

17 Dec '03

I thought it was elm causing the problem, so I posted the message regarding LPC10 and CELP using PINE. Sorry that the from field looks wrong. Can anyone tell me what I'm doing wrong (in email, not to the whole Cypherpunks group please?) - Jim Nitchals (jimn8(a)netcom.com)

1 0

Crypto and new computing strategies
by Hal 17 Dec '03

17 Dec '03

British physicist David Deutsch has been writing for several years on the theoretical properties of computers which would exploit quantum mechanics. Here is the abstract from his paper in Proc. R. Soc. Lond. A, v 400, p97-117, 1985: Quantum Theory, the Church-Turing Principle and the Universal Quantum Computer "It is argued that underlying the Church-Turing hypothesis there is an implicit physical assertion. Here, this assertion is presented explicitly as a physical principle: 'every finitely realizable physical system can be perfectly simulated by a universal model computing machine operating by finite means.' Classical physics and the universal Turing machine, because the former is continuous and the latter discrete, do not obey the principle, at least in the strong form above. A class of model computing machines that is the quantum generalization of the class of Turing machines is described, and it is shown that quantum theory and the 'universal quantum computer' are compatible with the principle. Computing machines resembling the universal quantum computer could, in principle, be built and would have many remarkable properties not reproducible by any Turing machine. These do not include the computation of non-recursive functions, but they do include 'quantum parallelism,' a method by which certain probabilistic tasks can be performed faster by a universal quantum computer than by any classical restriction of it. The intuitive explanation of these properties places an intolerable strain on all interpretations of quantum theory other than Everett's. Some of the numerous connections between the quantum theory of computation and the rest of physics are explored. Quantum complexity theory allows a physically more reasonable definition of the 'complexity' or 'knowledge' in a physical system than does classical complexity theory."

1 0

Re: Another view of the CFP
by koontzd＠lrcs.loral.com 17 Dec '03

17 Dec '03

>Subject: Re: Another view of the CFP >From: SINCLAIR DOUGLAS N <sinclai(a)ecf.toronto.edu> >In-Reply-To: <9403310139.AA19008(a)anchor.ho.att.com>; from >"bill.stewart@pleasant > >> The proposed standards I've seen on the net say you can't encrypt >> *after* using Clipper, because that makes Clipper key-theft useless. >> On the other hand, encryption with real systems before encrypting with >> Clipper is undetectable until after they decrypt the Clipper, so it's >> hard to enforce except on people who are already suspects, >> and is unlikely to be convenient to implement (for interoperability) >> on some of the major Clipper targets, like cellphones and fax machines. > >Makes sense, doesn't it? When the whitehouse guy said that encryption >below clipper was legal but not above, we thought he was confused. However, >we ACKed it with an NSA employee, and he confirmed it. His reasoning went >like this: encryption below clipper can't be stopped, since one can just >splice a cryptdec into the phone line. Encryption on top of clipper is >impossible since the clipper phone will only accept audio input. No >word on how that would effect clipper modems. > >Having said all this, I should note that the NSA employee was not acting >in an official capacity, and that he was not directly working on clipper. The AT&T Surety Communications Voice/Data Terminal 4100 is an STUIII with a type IIIe (e for export, read clipper) cryptographic algorithm, the model numbers for type I and type II STUIIIs are series 1000 and 2000 respectively. AT&T Surity (tm) Voice/Data Terminal 4100 For Sensitive, Business Applications The AT&T Surity Voice/Data Terminal 4100 provides secure voice and data communications in one integrated package. It works both as a full-featured telephone for voice calls and as a smart modem for data applications. Part of an AT&T familty of Surity products, the Voice/Data Terminal is compact and light enough to carry with you when you travel. Developed in conjunction with the U.S. Government's STU-III program, the Voice/Data Terminal 4100 is designed to protect domestic and internation business communications. .... 4100 Specifications: Information protected - Sensitive business and/or business-proprietary User Community - U.S. corporations - High tech manufacturing - Multinational corporations - Legal and financial organizations Security features - Clipper encryption algorthin - Display window for - Secure Access Control authentification identification System (SACS) - Information to create a call - Auto-answer, auto-secure audit trail - Active and passive terminal - Non-error propagating zeroization - Plain text inhibit Key management - Negotiated key - Self-generated key - Secret key - Negotiated key with authentication Voice modes - Clear voice - Secure voice [] 4.8 kbps full-duplex CELP [] 2.4 kbps half-duplex [] 2.4 kpbs full-duplex LPC10e LPC10e Telephone features ... Secure data operation modes - 9.6 kbps full-duplex - 2.4 kbps full-duplex sync/async sync/async - 4.8 kbps full-duplex - 2.4 kbps half-duplex sync sync/async .... ------ There are clipper phones that accept data. This is probably the one the DOJ buys. Basing arguments on fallicies is counterproductive, and is the sort of thing Tim May was talking about.

2 1

New MacPGP, but only in German?
by qwerty＠netcom.com 17 Dec '03

17 Dec '03

Forward from Usenet. If anybody knows where to get the English version please let me know; I'd like to make it available. I checked, and this new version has a fix of MacPGP2.3's worst bug, which is a System Crash when you don't have the public key needed to check a signature, and you are using the Clipboard feature. I started translating it with Resedit, but decided it wasn't a half-hour job afterall, especially since I don't know any German. alt.security.pgp #10674 (0 + 13 more) [1] From: andreas.elbert(a)gmd.de (A.Elbert) [1] MacPGP2.3a V1.1 Date: Tue Mar 29 08:09:03 EST 1994 Followup-To: alt.security.pgp Organization: GMD Lines: 6 i recently purchased "Mausefalle", a UA for the MausNet, which came with a AppleScript-able version of MacPGP. You can find it a copy (of MacPGP2.3V1.1) in ftp://ftp.darmstadt.gmd.de/incoming/MacPGP not sources, so far, but some ReadMe's and signatures. The author can be reached as Christoph_Pagalies(a)hh2.maus.de I posted this, and that's all there is of the thread so far: -----BEGIN PGP SIGNED MESSAGE----- I fetched that file (slowwwww). The readme file says, >This archive contains: >1. MacPGP 2.3a V1.1 German version (including international language.txt >and German readme) >2. MacPGP 2.3a V1.1 English (including the English readme for V1.1) >3. Documentation (English only) Each of the three folders has been signed so you can check for any manipulations (if you already have a previous PGP version). Yet all I saw was a folder with the German program: MacPGP 2.3a V1.1 Q dt. All the menus and buttons are in German, but the message window is English. Where's the English version? And what's the date of origin of this program? It seems to be an independent MacPGP2.3, as it only mentions changes since MacPGP2.2, not since MacPGP2.3v.1.0.5, which is what everybody is using now, otherwise known as just "MacPGP2.3". No mention of fixes for bugs that were in MacPGP2.3v.1.0.5, such as crashing during decryption using the Clipboard feature, if you don't have the right public key to check a signature with. We shall see (once I can read the damn menus) :-) ! -=Xenon=- P.S. If you want to know what version you have (which will turn out to be 1.0.5 if you have "MacPGP2.3"), open the program with ResEdit and look in the "Version" resource. P.S.S. The source code for MacPGP2.3 has always only been labeled as version 1.0.4! Does this mean the version I'm using has no source code available? I guess the NSA didn't want us to know what they put in there? -----BEGIN PGP SIGNATURE----- Version: 2.3 iQCVAgUBLZmT6gSzG6zrQn1RAQEKbAQAjiNGnwprYEz0uGTSvMkGzb5Bk4oFKuUR Si0pJJ6n+ebiOvcs8G3cycH54Mb43ULJFegqlg+k3fyxz0ijtRjqe4zFgIuFEXsn QGEUdtPZ2cRWmeVaATNJuQk8dEJixy+QSBA2GI3MRcoHoKJ73nU9ToPTYunSAcfT /Ea8czh4ygo= =UomE -----END PGP SIGNATURE-----

1 0

Sternlight update
by Matt Thomlinson 17 Dec '03

17 Dec '03

I know this isn't immediately pertinent, but I wanted to offer a pointer to sci.crypt. Currently a discussion of key lengths ("how long do {RSA|IDEA} keys have to be to be `safe'?") is going on; pretty interesting. Funny, I noticed a familiar name contributing (well, asking questions) and then _this_ post: ---------- Forwarded message ---------- From: strnlght(a)netcom.com (David Sternlight) Subject: Re: I concede the key length/cracking point. [...](matt) Finally, it's been suggested to me that the Clipper issue isn't about today, but about tomorrow,and that rich, smart cryptologic organizations may have no trouble today, but it's hoped that by the time tomorrow comes along, Clipper will be so widespread that non-Clipper can be handled by "other" means. In conclusion, I have to give a nod to the folks who are afraid non-Clipper might be banned some day: If in a few years widely available cheap machines (after all the roughly $1500 Power Mac is what, about 50 MHz?) make much longer keys easily feasible with short encryption/decryption times, then in a few years the government MIGHT actually want to ban non-escrowed crypto very badly. It would probably happen after the current Administration leaves office, making the current White House statements the literal truth for THIS administration. Alternatively, if the NSA has approaches we don't know about which mean that such longer keys are still vulnerable, then we might never see such a ban in the U.S. Note that it's possible to state the above carefully, non-hysterically, and without being offensive. Having taken a few hesitant steps down that path, a few things become clearer. For example the current effort in the Netherlands to ban non-escrowed crypto, and all crypto without permission, perhaps suggests that in the Netherlands they are there already--that is that their cryptologic capabilites aren't of an order comparable to some others and thus they have to face the "banning" decision now. Perhaps the same has been true for France for a while. We do have good reason to believe GCHQ is very advanced--we Americans have learned a thing or three from them, from what I read in the open literature. Thus it's possible the issue hasn't yet become critical in the U.K. Dunno about the Germans. It's possible that they got more from Hitler's former crypto experts than anyone knows and they are very advanced, or it's possible they have "special" relations with the U.S. or maybe even (this would be interesting) the U.K. of a kind that gives them capabilities the Dutch don't have. Given their forward position in the old Cold War days, it wouldn't surprise me. David -----------End Forwarded Message---------- Whoa! blew my mind. I think we finally got through to him. Now we'll have to finish brainwashing him (ready, tentacles?) and put him in a suit and tie. He can be our new spokesman. By the way, this isn't a fake mail -- he's been waltzing around like this for a week or so. matt Matt Thomlinson University of Washington, Seattle, Washington. phone: (206) 548-9804 Check my home page -- ftp://ftp.u.washington.edu/public/phantom/home.html PGP 2.2 key available via email, or finger phantom(a)hardy.u.washington.edu

1 0

Re: crypto software/papers/docs CD -- is there any interest?
by GERSTEIN＠SCSUD.CTSTATEU.EDU 17 Dec '03

17 Dec '03

Tim May writes: >Mark Henderson writes: > >> Forgive the somewhat commercial nature of this message, but I think >> it is well within the lines of the cypherpunks mission of getting >> code out to people. >> >> I'm considering the possibility of producing a CD (for distribution >> in North America only) of crypto source code, information/papers and >> binaries for common platforms. >>...[BUNCH OF STUFF DELETED]...... > >You'll have to be real careful here, as charging money means >copyrights have to be more scrupulously watched than when sites just >"informally" contain copyrighted material. (I'm not arguing for these >laws, just noting them.) ...[ANOTHER BUNCH OF STUFF DELETED]...... >(There are lots of issues here, which get debated over and over again >in various forums. All I'm saying is that charging $50 for a >compilation of articles, FAQs, scanned items, etc. is likely to >trigger a lot of things. Just a heads up.) > ...[STILL MORE DELETED]...... >--Tim May -=-=-=-=-=-=-=-=-=-=- Wouldn't doing something like this be like distributing shareware on a CD-Rom? Most of the Rom's I've seen have programs and the like, but a few have had source code, papers, hypercard stacks, etc. that were all copyrighted but still pushed out on the Rom. I think the only problem would be if you were charging more money than a "reasonable duplication fee". Most people will agree that this would be the cost of the media and maybe a little something for your time. Just another of my 0.02¢... Adam Gerstein "After this, nothing will shock me." ---------- "In a Time/CNN poll of 1,000 Americans conducted last week by Yankelovich Partners, two-thirds said it was more important to protect the privacy of phone calls than to preserve the ability of police to conduct wiretaps. When informed about the Clipper Chip, 80% said they opposed it." - Philip Elmer-Dewitt, "Who Should Keep the Keys", TIME, Mar. 4, 1994 -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- To sign on to the letter, send a message to: Clipper.petition(a)cpsr.org with the message "I oppose Clipper" (no quotes). You will receive a return message confirming your vote.

1 0

Clipper/Capstone/Skipjack excerpts from Cud 6.28
by paul＠hawksbill.sprintmrn.com 17 Dec '03

17 Dec '03

A couple of interesting articles on Clipper/Capstone/Skipjack which were included in the latest CuD, for those who haven't already seen it... - paul 8<-------------------- cut here ------------------------------- Date: Wed, 30 Mar 1994 22:03:00 CST Sender: CU-DIGEST list <CUDIGEST(a)vmd.cso.uiuc.edu> From: "(Jim Thomas)" <TK0JUT2(a)NIU.BITNET> Subject: Cu Digest, #6.28 ---------------------------------------------------------------------- Date: Sun, 27 Mar 94 17:35:00 -0700 From: walter.scott(a)HOTLINE.COM(Walter Scott) Subject: File 1--Downs Down On Clipper The Clipper Chip proposal from the Clinton Administration -- which would essentially have government broker individual electronic privacy rights -- is collecting still more opposition. One of the most recent opponents to Clipper is media icon Hugh Downs. Downs is well known for his days as a co-host of the Today Show, host of the game show Concentration, and his current position as co-host of ABC-TV's 20/20. Downs is also a respected advocate for "mature" adults. Downs delivered his "perspective" as to Clipper on the 03-27-94 edition of ABC radio's "PERSPECTIVES." In Downs' segment, much cryptography history -- as it relates to radio -- was explained while Downs laid the foundation for expression of his opinion on Clipper. The following text is a direct transcript of Downs' summation: ------------- TRANSCRIPT BEGINS ------------------------ It's not designed to stop criminals from sending encrypted messages because criminals will always be able to do that. If the NATIONAL SECURITY AGENCY puts a spy chip on American computers, then the criminals will simply avoid the chip and use other computers that don't spy on them. But, it wouldn't be just criminals who would buy foreign made computers. Anyone who wants a private life would have to buy foreign, too. According to John Perry Barlow, who's co-founder and Vice-chair of the Electronic Frontier Foundation, Vice President Gore says he wants the Clipper Chip installed in all American-made computers designed for export. Now, you don't have to be a computer whiz to realize that -- if American computers were forced to have a spy chip built into them -- then fewer people would buy American computers. The computer owes an enormous debt to cryptologists because cryptologists needed machines to disguise radio messages. The information highway is certainly as wide open as radio. Indeed, much of it is already radio. Cellular phones and cellular FAX will quickly expand to cellular modem and satellite communications. As it is, most of this information goes out unprotected. The time has arrived for individuals to have high levels of security. The information superhighway will eventually contain every scrap of information we could possibly imagine. And that means there will be all sorts of unscrupulous people out there trying to hack into our lives. Information-highwaymen are bad enough when they're fourteen years old. But now, adults -- who work for the government -- want to play hacker, too. The Clipper spy chip is bad business for everyone. Information-highway-safety should be a top priority for all of us. ------------ TRANSCRIPT ENDS -------------------- The Hotline/Seattle ~ (206) 450-0948 ------------------------------ Date: Tue, 22 Mar 1994 15:47:00 GMT From: chris.hind(a)MAVERICKBBS.COM(Chris Hind) Subject: File 2--Reply to "Clipper Paranoia" (CuD #6.26) This is my reply to: shadow(a)VORTEX.ITHACA.NY.US(bruce edwards) Subject--Opposing Clipper is "paranoia" with good Reason (Cu Digest, #6.26) >Its existence will make no difference at all. The very smart ones >may use PGP or something else, and again, clipper will be meaningless. We could easily build it into the net, making it impossible for the government to stop us. Sound like a good plan? >Because it will probably prove constitutionally impossible >to outlaw widespread private encryption -- something big brother finds >hard to swallow -- the clipper/encryption push seems to me to be about >another kettle of sharks. Completely true, encryption cannot be outlawed. The government is ripping itself off by giving us powerful encryption for personal use. But for the dark personal secrets, are we really gonna use the clip chip? Not me! I'll use PGP or something else. Criminals aren't going to use the chip unless they're really ignorant or blatantly idiotic. So the government is really spending lots of money to making our lines more secure from illegal phone tappers and such but not doing a thing for them. I believe we're getting the better part of the deal! Do they really want to listen in on phone calls to our relatives? I don't think so. I promote the Clipper Chip! Thanks for the free gift! T> In my opinion (and this I am sure is obvious to most everyone) the >encryption, bugging-port, e-mail reading agenda pursued by government >is no more than the first icy finger of the Empire, encircling the >throat of cyberspace. A little dramatic here? They might win the battle but they haven't won the war. The final battle will be when we establish a global Interactive Television system. Then it will pit the public against the US government and the allies it has in this dispute (if any). Nobody wants a video camera normally used for video conferencing to be watching them in their own living room without them even knowing it. By this time, people will know a lot more about this scheme and most likely the public will win this battle unless the majority of the population is as ignorant as a two year old child to the world around them. ------------------------------ Date: Wed, 30 Mar 94 13:24:38 PST From: dave(a)PCE1.HAC.COM(Dave Fandel) Subject: File 9--How Clipper Actually Works In all the anti-Clipper flaming that has been occuring I haven't seen anything about how Clipper actually works. I generated the following based on a lecture in a secure computer systems class I am taking. +---------------------------------------------------- Clipper Operations: Chip +----------------+ | | Message (M) -->| Algorithm (E) |--> Encrypted Message (B) = E [M] | Chip ID (ID) | K | Chip Key (U) | User Key (K) -->| Family Key (F) |--> Encrypted ID and Key (A) = | | E [ID | E [K]] +----------------+ F U Note: E [Q] means Encrypt Q with key R R +----------------------------------------------------------- The User Key is a session key that is generated by the two ends in the following manner: Side A Side B Generate a, X Generate Y a, X and Y are random # Send a and a^X ------> Receive a and a^X <------ Send a^Y Receive a^Y Generate K=(a^Y)^X Generate K=(a^X)^Y ie key K=a^(XY) So a, a^X, and a^Y can all be intercepted without giving away key. +---------------------------------------------------------------- So where does the government and the Key Escrow come into it? Note the 2nd output from the clipper chip - it is the ID of the chip and an encrypted version of the session key. The government will know the family key and can extract the ID. Then they go to the two escrow agencies (NIST and the Treasury Dept.) and get the two components of the chip key U. This allows the session key to be extracted and the message to be decrypted. Agency 1: ID and U(A) U(A) --+ OR --> U Agency 2: ID and U(B) U(B) --+ +------------------------------------------------------ General comments: 1. The Algorithm for the clipper chip is an NSA Type II algorithm called Skipjack. Type II is for unclassified, but sensitive. 2. If you could reprogram the Chip Key (U) or block the transmission of the encrypted ID and key this concept wouldn't be to bad. 3. The other point of vulnerability is at the manufacturing location where the Chip Key is originally generated. All 3 pieces of info (ID, U(A), and U(B)) have to be in the same place to generate the key. Dave Fandel dave(a)pce2.hac.com 3/30/94 If there is anything incorrect in this document please let me know. ------------------------------ 8<--------------------------- cut here ------------------------------ Cheers, _______________________________________________________________________________ Paul Ferguson US Sprint Enterprise Internet Engineering tel: 703.904.2437 Herndon, Virginia USA internet: paul(a)hawk.sprintmrn.com

1 0

Re: Very funny, Polyanna :-( [namespace pollution]
by Graham Toal 17 Dec '03

17 Dec '03

From: Eric Hughes <hughes(a)ah.com> contracting and for authentication. The current systems don't support this, and will, I suspect, not support this any time soon. In the meanwhile such policies will have to be created manually, even if their operation is transparent. >Whatever solution we can find will have to involve active support >from the keyservers I suspect. The key servers are just serving data. To add policy criteria to the key servers is to extend their functionality beyond their original intent. So? It has to be done *sometime* by someone. The point I was making was that for pgp (or any equivalent cyphered mail system) to work *en masse*, it has to be completely automatic and idiot-proof. I'm not talking about *us* here, I'm talking about your old mother, or Mac users, or the company technophobic managing director etc. What I see as desirable for such people is that their mail is encrypted whenever possible, but they don't have to do anything to make it happen. This means that the current web of trust scheme is not an applicable model, because these people have defined *no* trusted paths at all. We need some relatively trustworthy mechanism for getting pgp keys that will foil a denial-of-service attack - either the one I suggested where someone sets up a key for a mailing list or mail2news gateway (either maliciously or accidentally as with our friend Paulie-Anna) - or where someone creates a key for a specific person (as one joker did for Sternlight last year (this was a second one; Sternlight had one of his own first which he never revoked before he deleted his private key...)) which means that person won't be able to receive mail - if auto-pgp mechanisms become common. To me it looks like this has to be done by heavy-handed control coming from the keyserver admins, though I'd prefer that there was a more democratic way. Please suggest anything you think is appropriate... For the moment, I think that an auto-pgp mechanism will have to use a relatively secure server like SLED that can't have arbitrary keys added to it by all and sundry. If this is sufficiently different to the current key server mechanism that Eric doesn't object, then fine :-) Actually, the mechanism I forsee for doing this sort of thing is the tcp/ip interface to a keyserver that Ben Cox suggested last november. It *could* be bolted on to the finger server at wasabi, but I think the whole concept needs us to stand back a bit and think of what we really want before we start hacking. One mechanism that crossed my mind - when a new key is added, the keyserver that gets it first might hold on to the new key until after it had mailed the key owner and requested confirmation. This ought to be possible to automate. This would also block the cases where someone bulk uploads their keyring with keys on it which they'd been given in confidence, by people who didn't want their employers or government to know they were using pgp... Graham PS cc'd to alt.security.pgp - would the cypherpunks interested in this thread follow it there with me please?

3 2