December 2003 - cypherpunks-legacy

Re: RC2 Source Code - Legal Warning from RSADSI
by tien＠well.sf.ca.us 17 Dec '03

17 Dec '03

I don't practice intellectual property law, but I think y'all should be careful, legally speaking. Without more facts, you don't know if the purported disassembly was lawful. >From: Rich Salz <rsalz(a)osf.org> >Date: Thu, 1 Feb 1996 19:46:50 -0500 >Subject: Re: RC2 Source Code - Legal Warning from RSADSI > >Once lost, trade secret can never be regained. The person(s) responsible >can be sued so they never work again :), but it's unclear if RSA can >stop anyone using unpublished trade-secret source. > >At any rate, I'll stop my comparison of the distributed RC2 and the >licensed RC2 since RSA's done it for us. :) > /r$ I think the first and second sentences don't map. It's true that once a trade secret is "lost," it's lost (though I suppose if everyone forgets it and someone rediscovers and protects it it's regained). But you must distinguish between *legally* lost and merely practically disseminated. Trade secrecy is not complete or real secrecy. If I were under NDA to RSA to keep RC2 secret, passed it on to Rich, and RC2 met the legal test for trade secrecy, it is still a trade secret in the law. I don't recall the remedies, but I'm fairly sure that if Rich has the right level of knowledge/notice, he's not immune. >From: "Brian A. LaMacchia" <bal(a)martigny.ai.mit.edu> >Date: Thu, 1 Feb 96 21:06:12 -0500 >Subject: Re: RC2 Source Code - Legal Warning from RSADSI > > Date: Thu, 1 Feb 1996 18:26:15 -0500 > Mime-Version: 1.0 > Content-Type: text/plain; charset="us-ascii" > From: jrochkin(a)cs.oberlin.edu (Jonathan Rochkind) > Sender: owner-cypherpunks(a)toad.com > Precedence: bulk > > Now, copyright might be another matter. But you can't copyright an > algorithm, only specific text in fixed form (ie, the source code). So this > would mean you couldn't use the particular code posted to sci.crypt, but > wouldn't stop anyone from using the algorithm, if they wrote their own code > (to be safe, without having seen the RSA-copyrighted code, only having the > algorithm described to them by someone else). > >If the source code posted to sci.crypt was in fact a copy of an RSADSI >copyrighted soure code listing, then making copies of that listing is a >copyright violation. However, copyright protection does not extend to >the underlying algorithm, so unless RSADSI has a patent on the algorithm >the idea is free, and can be reimplemented using a "clean room" or >"Chinese wall" approach. If the posted source code was *not* a copy of >RSADSI source code but instead produced by disassembling object code >RSADSI's claims are tenuous at best. RSADSI could conceivably claim >that the disassembled code is a derivative product of their copyrighted >object code, but I think they would have a hard time distinguishing >themselves from the facts in _Sega v. Accolade_. > >I fail to see how the legality of "alleged-RC2" is any different than >that of the "alleged-RC4" code which was published last year. > > --bal Trade secrecy is separate from either copyright or patent. It covers both patentable and nonpatentable stuff. Its great advantage is its potential duration -- so long as it's not independently generated or reverse-engineered. Its great drawback is it's hard to maintain. I think Brian is right in what he said, but the critical qualification is how the posted source code was produced. One could have a trade secret in the algorithm; Sega v. Accolade only addresses the copyright issues, if memory serves. The Ninth Circuit found that the dissassembly was infringement, because it involved copying of the protected expression, but excused the infringement based on "fair use." *** Keep in mind that fair use is multifactor, and the Sega decision expressly noted that Accolade was only trying to achieve compatibility, only indirectly harming the market for Sega's videogames. This alone might distinguish disassembly to get RC2 source in order to put RC2 "out there," even from a copyright perspective. What's unclear in the law is RSA's power to control dissassembly by contract. Traditionally, reverse engineering has always been a legitimate means of penetrating trade secrecy. The problem arises, though, if one agrees not to reverse-engineer. If I got an RSA product and agreed not to disassemble and not to disclose anything I might happen to discover, then I have a contractual, not statutory, duty. This is like the shrink-wrap license issue: if I buy Lotus Notes, a shrink-wrap "no dissassembly" provision may well be unenforceable. Such a provision is more likely enforceable in a truly bargained contract. This is all contract law. So if the person who disassembled was under a contractual bar, disassembly could be misappropriation. (I'm not clear on current misappropriation law, which is in a statute in California if I recall.) I'm not really up on all this, and it's very fact-sensitive, but I don't think the legal issues are very simple, and I would counsel some caution. Are those enough qualifications and disclaimers? Lee

1 0

What is this threat?
by nobody＠REPLAY.COM 17 Dec '03

17 Dec '03

The USG offers a $500,000 reward for stopping: Perception management and active measures activities. The FBI DECA terms it one of seven "foreign intelligence activities that are deemed to be significant threats to U.S. national security interests." ---------- URL: http://www.fbi.gov/deca.htm _______________________________________________________ DECA (pronounced "DECK-UH") is the FBI's program for the Development of Espionage, Counterintelligence and Counterterrorism Awareness. The DECA program disseminates information concerning national security matters. The FBI is the lead counterintelligence agency in the United States. It has the principal authority to conduct and coordinate counterintelligence and counterterrorism investigations and operations within the United States. The FBI, supported by other U.S. agencies as needed, conducts espionage investigations when the subject of the investigation is not under the jurisdiction of the Department of Defense, Uniform Code of Military Justice. _______________________________________________________ NATIONAL SECURITY THREAT LIST The FBI's foreign counterintelligence mission is set out in a strategy known as the National Security Threat List (NSTL). The NSTL combines two elements: * First, it includes national security threat issues regardless of the country of origin. * Second, it includes a classified list of foreign powers that pose a strategic intelligence threat to U.S. security interests. The issue threat portion of the NSTL was developed in concert with the U.S. Intelligence Community and key elements of the U.S. Government. As a result, the FBI identified seven categories of foreign intelligence activity that were deemed to be significant threats to U.S. national security interests. The FBI will investigate the intelligence activities of any country that are related to any of these seven issues. They are: 1. Proliferation of special weapons of mass destruction to include chemical, biological, nuclear, and delivery systems of those weapons of mass destruction. 2. Collection of information relating to defense establishments and related activities of national preparedness. 3. U.S. critical technologies as identified by the National Critical Technologies Panel. 4. Targeting of U.S. intelligence and foreign affairs information and U.S. Government officials. 5. Collection of U.S. industrial proprietary economic information and technology, the loss of which would undermine the U.S. strategic industrial position. 6. Clandestine foreign intelligence activity in the United States. 7. Perception management and active measures activities. _______________________________________________________ NATIONAL CRITICAL TECHNOLOGIES Foreign intelligence activities directed at U.S. critical technologies are of specific interest to the FBI. These critical technologies are listed as follows: * Materials: + Materials synthesis and processing + Electronic and photonic materials + Ceramics + Composites + High-performance metals and alloys * Manufacturing: + Flexible computer-integrated manufacturing + Intelligence processing equipment + Micro- and nanofabrication + Systems management technologies * Information and communications: + Software + Micro and optoelectronics + High-performance computing and networking + High-definition imaging and displays + Sensors and signal processing + Data storage and peripherals + Computer simulation and modeling * Biotechnology and life sciences: + Applied molecular biology + Medical technology * Aeronautics and surface transportation: + Aeronautics + Surface transportation technologies * Energy and environment: + Energy technologies + Pollution minimization, remediation, and waste management _______________________________________________________ National Security Begins With You You may be the target of foreign intelligence activity if you or your company are associated in any of the critical technologies listed above. Foreign powers may also seek to collect U.S. industrial proprietary economic information and technology, the loss of which would undermine the U.S. strategic industrial position. Foreign intelligence collectors target corporate marketing information in support of their nation's firms. Overseas travel, foreign contact, and joint ventures may further increase your exposure to the efforts of foreign intelligence collectors. If you suspect possible foreign intelligence activity, or have questions concerning the National Security Threat List strategy, please contact the FBI DECA Coordinator at the FBI Field Office nearest you. _______________________________________________________ Up to $500,000 Reward for Stopping Espionage An amendment to title 18 U.S.C. Section 3071, recently enacted, authorizes the Attorney General to make payment for information of espionage activity in any country which leads to the arrest and conviction of any person(s): 1. ...for commission of an act of espionage against the United States; 2. ...for conspiring or attempting to commit an act of espionage against the United States; 3. or which leads to the prevention or frustration of an act of espionage against the United States. Specifics of this amendment can be obtained from any FBI DECA Coordinator. _______________________________________________________ FBI Contact Numbers: To report suspected illegal intelligence or terrorism activity against the interest of the United States, telephone the DECA Coordinator at the FBI Field Office nearest you. Update Version: 9/25/95 _______________________________________________________

1 0

Re: Encryption and the 2nd Amendment (fwd)
by Jim Choate 17 Dec '03

17 Dec '03

Forwarded message: > Date: Fri, 2 Feb 1996 18:37:24 -0800 > From: tien(a)well.sf.ca.us (Lee Tien) > Subject: Re: Encryption and the 2nd Amendment > > I agree that a 2nd A. argument is legally worthless; so do Mike Godwin and > other persons whose legal opinions are generally carefully considered. > I still believe this issue is a prime candidate for testing the 9th and 10th. There is nothing specific in the Constitution which allows the government to control crypto technology (or any technology actualy) which is contrary to the 10th. Per the 9th it should be left up to the states or the people to decide. The current group of issues as mentioned in a post by Tim May earlier today are all related by these amendments. The precedence of the legislative and court bodies in this country ignoring these amendments may be at an end.

1 0

sent to U.Mass
by jf_avon＠citenet.net 17 Dec '03

17 Dec '03

Hi CPunks. I went into www.umass.com, somewhere into it up untill I could find an e-mail adress, and mailed this letter: -----BEGIN PGP SIGNED MESSAGE----- to: Dean of the University. From: Jean-Francois Avon Pierrefonds, QC, Canada jf_avon(a)citenet.net While I do not believe nor endorse the neo-nazi movements and their ideas, I consider interesting to be able to look at their arguments, if only to make my own opinion of them. I understand that you banned a WWW site providing such information. I also understand that this site presented this information to oppose the german govt. in their censoring actions against some such sites. I do not have a first hand knowledge of the content of the specific site (Zundel) that started the whole thing and I am convinced that many other pro-nazi might use some material presented in a decent way for quite questionnable ends. But nevertheless, from what I read, you seemed to have banned a site out of political correctness. I hope it is not true. Unfortunately, freedom and liberty, thoses crutial and typically american values, seems to be eroded first by thoses trusted to protect them: the american intellectual and scholar. We live in a very sad world, where reason is dissapearing slowly, being replaced by fear and low animal instincts. Please pardon my poor english. Jean-Francois Avon -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMRK0IgOWptJXIUrtAQHt1AP+ND5LeFPpc/ypyS2eBkK1SAsAyZazNpBf t9vrBs3LOgu8wCmfKV+H9Qczfp4wCtcs3gMux+U7w1E7Xj556iPBCXNcYLVI/RBN 8DzJLYN3ANlJIZqKDSv+GGmsfvx+wIXKEFiM8lKV+D1PZIeZ1HEdy9N3vT6H12oL 1LOQKRLG4tM= =H4wq -----END PGP SIGNATURE-----

1 0

Re: Imminent Death of Usenet Predicted
by Jordan Hayes 17 Dec '03

17 Dec '03

From tcmay(a)got.net Fri Feb 2 19:10:21 1996 I'm not despairing ... It seems to me that all the things you pointed out are just symptoms of the Internet growing up. You mentioned on the one hand that you don't like the trend that you see culminating in having all USENET posts be signed, but on the other hand that you'd like to see a 'sealed package' approach to your packets. The problem is clear: USENET *isn't* 'sealed packages' -- it's practically an outdoor billboard. And I think it's logical to expect some concensus-based rules for behavior there. This whole uproar about 'porno on the net' has to do with how children can 'stumble' upon it, as opposed to, say, renting it from Blockbuster[*]. I'm a little more upbeat than Tim, I guess. I see the trend toward 'socialization' on the 'public' part of the Internet as ultimately just fine, and the trend toward finding private means ('sealed packages') to transmit 'private' goods continuing. Soon I hope that there will be as much chance of children 'stumbling upon' X-rated JPEGs as they can today image satellite-delivered porno in their heads without a dish. I think the trend will continue so that people will eventually feel that their e-mail is about as safe from 'the public' as a phone call is. Absolute privacy will be resisted from the top because being 'in power' means always having a final veto; but what is the real risk of this? And don't forget: if you have privacy, you don't need anonymity. Swiss banks provide the ultimate example. /jordan [*] I think community standards are important. Whether it's speed bumps on side streets or calls for silence in a jazz club, the participants in a group should get to decide what is acceptable behavior within their group. That being said, I also believe it is one of the few roles that a national government to provide is guidance about a small number of issues (so before you hit that 'R' key, I don't believe that small towns can assert racism in their town charter ...).

1 0

Re: Microsoft's CryptoAPI - thoughts?
by John Banes 17 Dec '03

17 Dec '03

I have "standardized" the PS files on the MS website, so there should be no more problems. Sorry for the inconvenience. ---------- | From: Futplex <futplex(a)pseudonym.com> | To: Cypherpunks Mailing List <cypherpunks(a)toad.com> | Cc: CryptoAPI Information Alias | Subject: Re: Microsoft's CryptoAPI - thoughts? | Date: Friday, January 26, 1996 3:02AM | | rickt(a)psa.pencom.com writes: | > [Info can be found at: http://www.microsoft.com/intdev/inttech/cryptapi.htm] | | Has someone here managed to extract PostScript hardcopy of the | CAPI from this Web page? I tried earlier this evening and | wound up with a miniature | ecological disaster on my hands. The page says: | | "For ease of online reading and printing, we've provided copies of this | lengthy document in Microsoft Word and Postscript formats." | | I grabbed the ZIPped PostScript version and unZIPped it, which resulted in a | single file called "capiapp.ps". Making the wild assumption that this was | indeed a PostScript file, I sent it to the printer and forgot about it for a | while. | | An hour later I discovered a chaotic scene in the printer room, as the | printer had spewed about 1.5 reams of raw PostScript printouts. The output bin | had overflowed for a while, spraying paper in several directions. <heavy sigh> | | As it turns out, the file unhelpfully begins with | %-12345X@JPL ENTER LANGUAGE=POSTSCRIPT | preceding the usual "%!PS-Adobe-3.0" line. Worse still, it appears that the | capiapp.ps file is actually a catenation of many PostScript files (one per | chapter?), each beginning with a version of this ensnarling line. | | I could do some global search-and-replacing, etc., but I think I'll wait for | Microsoft to distribute a decent PS version of this document. Perhaps they | should consider not generating it with MS Word.... | | Grr! | | Futplex <futplex(a)pseudonym.com> |

1 0

Re: RSA disappears :-)
by Alan Olsen 17 Dec '03

17 Dec '03

At 01:28 PM 2/2/96 -0800, John Pettitt wrote: >rsa.com dissapeard from the net! The only valid nameserver for rsa.com is >rsa.com and since it's net connection is down anybody trying to talk to >www.rsa.com or send mail to rsa is getting host not found errors. Maybe it was because Tim May broke their cover. Alan Olsen -- alano(a)teleport.com -- Contract Web Design & Instruction `finger -l alano(a)teleport.com` for PGP 2.6.2 key http://www.teleport.com/~alano/ Is the operating system half NT or half full?

1 0

Re: PGP "official" logo?
by Alan Pugh 17 Dec '03

17 Dec '03

=snip= >Why is an icon or logo preferable to "Begin PGP signed..."? The little >rose, or chevrons, or escutcheons, or whatever, then have to be explained >to people. "PGP" is actually its own best logo. > >(There is also the important point that most uses of PGP are in >primarily-ASCII settings, in e-mail. Yes, I know that MIME and whatnot can >support graphics, but such uses are rare. Look at this mailing list, and >Usenet, for examples of how most messages are composed. I routinely delete >all messages that have "attachments converted" to them, and others have >told me they do the same thing.) i agree with mr. may. graphics are misplaced in email generally. it takes long enough to download my mail without the additional load of cute graphics. i can't image many graphics at all that would be much smaller than the biggest sig files. otoh, it _would_ be useful imo to have a pretty much 'standard' graphic to put on web pages similar to the 'netscape' buttons you see everywhere. they might do nothing but link to one of the cypherpunks home pages, but the more people see them, the more aware people will hopefully become. perhaps it will pique some folks curiosity. actually, i like rsa's logo, but it is obviously taken. that said, i've seen a few passes on this list of discussion of a graphic logo. the archives would be a good place to look for a fairly massive volume of posts on it. if anyone has a good idea, put it on a page and post the pointer. amp

1 0

Re: OFFSHORE RESOURCES
by Edgar Swank 17 Dec '03

17 Dec '03

Another URL for offshore investing, etc. is http://www.dnai.com/offshore/offshore.html Edgar W. Swank <edgar(a)Garg.Campbell.CA.US> -- edgar(a)Garg.Campbell.CA.US (Edgar Swank) The Land of Garg BBS -- +1 408 378-5108

1 0

Analysis of PGP keyserver web of trust
by Neal.McBurnett＠att.com 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- I wrote a Java program to analyze the the PGP web of trust and I've documented it on some web pages. They include information on the strongly connected components (the largest has 1291 keys in it), the longest "shortest-path" (21 signatures long), the 'central trustee' and 'central truster', the mean path length (6.4, by one definition), etc. http://bcn.boulder.co.us/~neal/pgpstat/ (For those who saw the earlier version, I've fixed some small bugs.) There is a lot of useful information here for folks who want to improve the connectivity of the public PGP web of trust. Cheers, Neal.McBurnett(a)att.com 503-331-5795 AT&T Bell Labs, Denver/Portland WWW: http://bcn.boulder.co.us/~neal/Home.html (with PGP key) - ----------------------------------------------------------------------- PGP Keyserver Statistics This is an analysis of the web of trust among users of the leading technology in the world of secure email communications, Pretty Good Privacy (PGP). See the [1]PGP Frequently Asked Questions for more information on PGP itself and other related tools. There is a set of public key servers around the world which allow PGP users to register their keys and publicly sign each other's keys via [2]email and [3]WWW interfaces. This analysis is based on the public keyring obtained from [4]ftp://ftp.uit.no/pub/crypto/pgp/keys/pubring.pgp on _1 Jan 1996_. For comparative analysis, here is the [5]Jan 1 version (7,976,108 bytes long). I could also provide a shorter and simpler file format which just lists which keyIDs signed which keyIDs. If there is interest, updates can be provided. Overall Statistics Public keys submitted ('pub'): 19124 Signatures ('sig'): 28031 Total number of unique keys referenced: 21107 Revoked keys: 839 Self-signed keyIDs: 7300 Other unique keyID-signs-keyID pairs: 17908 Note that less than half of the keys are signed by themselves. People should _always sign their own UserID_ on their own key! Otherwise, someone else can surreptitiously change the email address in order to encourage correspondents to send email to the wrong place. Only about 1/3 of the keys are signed by at least one another key, and only 1/6 have 2 signatures. To be a "good PGP-citizen", you should * Be very careful about signing keys. Have first-hand knowledge based on hard-to-forge communications that the key's fingerprint (pgp -kvc) in your keyring matches the user's real fingerprint. * Sign the keys of at least two other people * Get at least two signatures on your own key. * Extra credit: Sponsor a [6]key-signing party Strongly-Connected Components A 'strongly-connected' set of keys is defined as a set in which every key leads to every other key via some chain of signatures (aka signature path). Note that we are not incorporating any PGP-specific rules for establishing trust (e.g. the default CERT_DEPTH of 4, the default requirement for two 'marginally trusted' introducers to establish trust, etc.). After running pgp -kc on the keyring (with MIT PGP 2.6.2, for almost 2 days...) the number of signatures dropped from 28031 to 25810, presumably because some old signatures where thrown out. The analysis here was done with the original keyring, so all versions of PGP will not recognize all the signatures which are accepted here. Note that the program used for this analysis (pgpstat.java) so far only deals with keyID-keyID relationships, rather than dealing separately with each keyID/UserID pair. It does properly ignore revoked keys. Size of 'strong': largest strongly-connected component: 1291 Size of 'signees': keys signed by 'strong': 2775 Size of 'signers': keys which sign 'strong': 2001 The [7]largest strongly-connected component of this keyring (the set names 'strong') has 1291 keys in it. The [8]next-largest strongly-connected component has only 16 keys in it. There are another 1484 keys which are directly or indirectly signed by at least one key in 'strong' but which do not sign any key in 'strong' and are thus not in the strongly-connected component, for a total of 2775 keys in the 'signees' set that can be reached from the 'strong' set. Similarly, there are a total of 2001 keys in the 'signers' set which directly or indirectly sign at least one key in the strong component. Shortest-Path Distances Using a breadth-first search of the keyspace, we can calculate the shortest path from one keyID to other keyIDs it has directly or indirectly signed. Mean distance from strong keyIDs to signees: 6.41189 Mean distance to strong keyIDs from signers: 6.70961 Maximum shortest-path distance: 21 First, for each key in 'strong', we compute the mean length of the shortest path necessary to reach each key in 'signees': 6.41189. Next we do the converse, following paths of signatures into the strong component rather than out of it. The mean distances are different because a different set of keys is involved: signers vs signees. Finally, we note that there are several pairs of keys which have a shortest path distance of 21 between them. Here is the [9]example path, between these two keys: 6CB05C95 Karl F. Scheibner <scheibner(a)llnl.gov> 82996935 Brett Dubroy <1:225/357@fidonet.org> Anyone who is along this path can improve the tightness of the web of trust by finding someone they know further along the path and carefully signing their key. Centers of Trust: the Central Trustee and Central Truster By examining the shortest-path data more closely we can identify the keys which are closest to the 'center' of the web of trust. The 'central trustee' is the key which is signed most directly by others: the key which has the shortest mean distance from all of the 'signers'. Here is the current "top 10": Mean Max KeyID UserID 4.17191 11 CE766B1F Paul C. Leyland <pcl(a)foo.oucs.ox.ac.uk> 4.30235 12 53AAF259 Klaus-Peter Kossakowski, DFN-CERT <kpk(a)cert.dfn .de> 4.37881 12 32DD98D9 Vesselin V. Bontchev <bontchev(a)complex.is> 4.38381 12 D410B7F5 DFN-CERT <dfncert(a)cert.dfn.de> 4.4043 13 DA0EDC81 Phil Karn <karn(a)unix.ka9q.ampr.org> 4.4073 12 F82CEA91 Simon Cooper <sc(a)sgi.com> 4.43778 13 C1B06AF1 Derek Atkins <warlord(a)MIT.EDU> 4.46527 13 466B4289 Theodore Ts'o [SIGNATURE] <tytso(a)mit.edu> 4.47576 12 C7A966DD Philip R. Zimmermann <prz(a)acm.org> 4.48426 12 8E0A49D1 Wolfgang Ley, DFN-CERT <ley(a)cert.dfn.de> You can also get the [10]full list by mean distance. Here is the [11]distance to the cental trustee from the each of the signers along with info on how many keys sign and are signed by each key. The converse of this is the 'central truster', the key which trusts other keys most directly: Mean Max KeyID UserID 3.91928 10 32DD98D9 Vesselin V. Bontchev <bontchev(a)complex.is> 3.97694 11 C7A966DD Philip R. Zimmermann <prz(a)acm.org> 4.0191 12 DA0EDC81 Phil Karn <karn(a)unix.ka9q.ampr.org> 4.0418 12 0DBF906D Jeffrey I. Schiller <jis(a)mit.edu> 4.05838 11 CE766B1F Paul C. Leyland <pcl(a)foo.oucs.ox.ac.uk> 4.08396 12 7B7AE5E1 Germano Caronni <caronni(a)tik.ee.ethz.ch> 4.08973 11 4D0C4EE1 Jeffrey I. Schiller <jis(a)mit.edu> 4.13405 12 666D0051 Assar Westerlund <assar(a)pdc.kth.se> 4.17333 12 5826CF8D John Gardiner Myers <jgm+(a)cmu.edu> 4.17982 12 466B4289 Theodore Ts'o [SIGNATURE] <tytso(a)mit.edu> You can also get the [12]full list by mean distance. Here is the [13]distance to each of the 'signees' from the central truster, along with info on how many keys sign and are signed by each key. Further Questions Many other aspects of the web of trust could be explored. * It is important that the web be multiply-connected. p Good software to do bi-connectivity (or tri-connectivity, etc.) for directed graphs would be useful, especially if it identifies the most significant articulation points (keys which are critical for the connection of big pieces of the web). * Identification of large cliques or near-cliques (sets of keys which all sign each other, related to coloring problem, very hard.) * Software to generate a high-level graphical view would be useful. For example, a directed-acyclic-graph of the connectivity of the larger strongly-connected components would be interesting. * It shouldn't be too hard to make pgpstat.java into a server which could answer custom queries (shortest path from x to y, size of component that x is in, suggestions for who might be able to sign your key (e.g. other keys from the strongly-connected component which are in your domain), etc.) Tools The analysis tool, pgpstat.java, is an application written in the very nice new language [14]Java (Perl just doesn't have any decent hierarchical data structure support...). Source code will probably be made available after some cleaning-up for others who want to explore different keyrings or other avenues of analysis. Performance note: the algorithms used here mostly scale linearly in time complexity, based on the sum of the numbers of keys and signatures. In particular this is true for the code that finds the strongly-connected components (thanks to a favorite professor of mine, Bob Sedgewick, and his "Algorithms" book!) The one notable exception is finding the centers of trust and the longest shortest-path, which is quadratic in the size of the connected set, but doesn't have to be computed nearly as often, as a practical matter. The full analysis took less than 30 minutes using one processor on a Sun Sparc 1000 (50 Mhz?). There are lots of opportunities for optimization, and hopefully non-quadratic algorithms for at least approximating the center/longest path problems. Please let me know if you have any feedback on this analysis. _________________________________________________________________ [15]Neal McBurnett <neal.mcburnett(a)att.com> References 1. http://www.quadralay.com/www/Crypt/PGP/pgp00.html 2. http://www.pgp.net/pgp/email-key-server-info.html 3. http://www.pgp.net/pgp/www-key.html 4. ftp://ftp.uit.no/pub/crypto/pgp/keys/pubring.pgp 5. file://localhost/home/neal/public_html/pgpstat/public-keys.960101.pgp 6. http://www.quadralay.com/www/Crypt/PGP/pgp06.html#608 7. file://localhost/home/neal/public_html/pgpstat/strong-from 8. file://localhost/home/neal/public_html/pgpstat/strong2 9. file://localhost/home/neal/public_html/pgpstat/maxpath 10. file://localhost/home/neal/public_html/pgpstat/strong-from 11. file://localhost/home/neal/public_html/pgpstat/signers 12. file://localhost/home/neal/public_html/pgpstat/strong-to 13. file://localhost/home/neal/public_html/pgpstat/signees 14. http://www.javasoft.com/ 15. http://bcn.boulder.co.us/~neal/Home.html -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQBVAwUBMRL1t8KbwnFPAGm1AQHizwIAn+HiF7ohgcxlYAI9OS4St9FFghzCQ+8v TQYKssbcqS06Y0kkeTYyKFBRfwTrulxugE+aq6Jchpw2vo0C6YvEdA== =mXbe -----END PGP SIGNATURE-----

2 1