- cypherpunks-legacy - lists.cpunks.org

FW: Laugh Of The Day - Fri, Feb 02 1996 (fwd)
by rah＠shipwright.com 17 Dec '03

17 Dec '03

--- begin forwarded text From: "Roger Koppl" <KOPPL(a)FDUSVR1.FDU.EDU> Organization: FAIRLEIGH DICKINSON UNIVERSITY To: austrianecon(a)agoric.com Date: Wed, 14 Feb 1996 12:38:57 EDT Subject: FW: Laugh Of The Day - Fri, Feb 02 1996 (fwd) Priority: normal Sender: owner-austrianecon(a)agoric.com Precedence: bulk Reply-To: AustrianECON(a)agoric.com I got this from a colleague. Apparently the source is LaughWEB. Sound familiar? Roger ---------- Forwarded message ---------- ***************************************************************** Be sure to visit LaughWEB (http://www.misty.com/laughweb/) ***************************************************************** *File Description: The Natural Life Cycle Of a Mailing List* THE NATURAL LIFE CYCLE OF MAILING LISTS Every list seems to go through the same cycle: 1. Initial enthusiasm (people introduce themselves, and gush alot about how wonderful it is to find kindred souls). 2. Evangelism (people moan about how few folks are posting to the list, and brainstorm recruitment strategies). 3. Growth (more and more people join, more and more lengthy threads develop, occasional off-topic threads pop up). 4. Community (lots of threads, some more relevant than others; lots of information and advice is exchanged; experts help other experts as well as less experienced colleagues; friendships develop; people tease each other; newcomers are welcomed with generosity and patience; everyone -- newbie and expert alike -- feels comfortable asking questions, suggesting answers, and sharing opinions). 5. Discomfort with diversity (the number of messages increases dramatically; not every thread is fascinating to every reader; people start complaining about the signal-to-noise ratio; person 1 threatens to quit if *other* people don't limit discussion to person 1's pet topic; person 2 agrees with person 1; person 3 tells 1 & 2 to lighten up; more bandwidth is wasted complaining about off-topic threads than is used for the threads themselves; everyone gets annoyed). 6a. Smug complacency and stagnation (the purists flame everyone who asks an 'old' question or responds with humor to a serious post; newbies are rebuffed; traffic drops to a doze-producing level of a few minor issues; all interesting discussions happen by private email and are limited to a few participants; the purists spend lots of time self-righteously congratulating each other on keeping off-topic threads off the list). OR 6b. Maturity (a few people quit in a huff; the rest of the participants stay near stage 4, with stage 5 popping up briefly every few weeks; many people wear out their second or third 'delete' key, but the list lives contentedly ever after). ****************************************************************************** LAUGH OF THE DAY - A service of LaughWEB (http://www.misty.com/laughweb/) To subscribe, send e-mail to majordomo(a)world.std.com, with text: subscribe lotd email_address To subscribe to lotd, point your web browser to: http://world.std.com/~joeshmoe/laughweb/lotd_subscribe.html ---------------------------------------------------------------------- Roger Koppl Associate Professor Economics and Finance Fairleigh Dickinson University Madison, NJ 07940 USA Internet: Koppl(a)fdusvr1.fdu.edu Phone: (201) 443-8846 Fax: (201) 443-8804 ---------------------------------------------------------------------- --- end forwarded text ----------------- Robert Hettinga (rah(a)shipwright.com) e$, 44 Farquhar Street, Boston, MA 02131 USA "Reality is not optional." --Thomas Sowell The e$ Home Page: http://thumper.vmeng.com/pub/rah/

1 0

Some thoughts on the Chinese Net
by Jon Lasser 17 Dec '03

17 Dec '03

Several people have posted to the list that the Chinese, censored, Internet will fail. Usually, the claim is that the censored network will fail mostly because of technical reasons, namely the inability of the Chinese government to censor everything. The other significant claim made was that the Chinese problem is "behind" the "firewall" leading into the country... Suggestions have been made that RSA is involved with China to implement this censorship. I would suggest that the Chinese solution to these problems is singular, and simple: the total inability to conduct any transaction anonymously. How can this occur? It takes two parts; one simple, one somewhat more difficult. The simple portion is a national (Chinese) database associating true names with key IDs. These keys will be usable only to sign documents, not to encrypt information, similar to the Federal DSS. The more complex portion (from my perspective, at any rate) is a modification of the standard TCP/IP protocol, requiring that each packet be signed by its originating user. This would require lots of software modification on the Chinese end, as well as a conversion process at the National firewall. (This is where the censorship takes place; the censors don't filter out unwanted information, they sign acceptable information. They then store a reference to the bit of information with a hash. If the hash checks out, they don't need to re-sign the data. This allows a ramp-up after a while to provide adequate quantities of information). The real question is who's going to design/implement this protocol? The answer is Western sofware companies which want to do business in China. RSA would obviously be called upon to design the protocol, as well as perhaps provide certain implementations of it. Another likely candidate is Microsoft, whose Windows OS has been declared a National Standard by China. It would hold obvious financial benifits for MS to develop a Chinese TCP/IP protocol for Windows. Any company which wants a monopoly in a country of > 1 billion people could probably get in on this deal. Now that all information has a recognizable source, dissidents in China can be arrested, and unacceptable information never makes it into the country. Can anybody say why this can't be implemented? Or why China wouldn't implement it? This is obviously a worst-case scenario, but one which appears, at least to me, to be technically feasable. I'd love to hear otherwise. Jon Lasser ---------- Jon Lasser (410)494-3072 - Obscenity is a crutch for jlasser(a)rwd.goucher.edu inarticulate motherfuckers. http://www.goucher.edu/~jlasser/ Finger for PGP key (1024/EC001E4D) - Fuck the CDA.

3 2

anonymous age credentials, sharing of
by Michael Froomkin 17 Dec '03

17 Dec '03

Suppose Alice is a CA who issues anonymous age credentials. Bob is 15 Carol is 25 Carol gets a legitimate anonymous age credential from Alice bound to an anonymous public key generated for this purpose. Carol then gives the key pair to Bob. Bob uses to do things only adults are legally permitted to do. (It's not bound to Carol's everday keypair because that's not anonymous....) What can stop Bob and Carol from subverting a scheme that relies on anonymous age creditials in this manner? If the answer is "nothing" this might mean that purveyors of "adult" material might have no defense against a law requiring that they collect a True Name + age creditential.... A. Michael Froomkin | +1 (305) 284-4285; +1 (305) 284-6506 (fax) Associate Professor of Law | U. Miami School of Law | froomkin(a)law.miami.edu P.O. Box 248087 | http://www.law.miami.edu/~froomkin Coral Gables, FL 33124 USA | It's warm here.

3 2

Re: The Emotional Killer (or out of the frying pan and into
by tallpaul＠pipeline.com 17 Dec '03

17 Dec '03

On Feb 11, 1996 23:48:29, 'jim bell <jimbell(a)pacifier.com>' wrote: >At 11:59 PM 2/11/96 -0500, tallpaul wrote: >>I want to write on the theme posted to the list in the message below where >>J. Bell wrote "It is their ACTIONS that I feel violate my rights; that is >>what justifies my seeking their deaths, should I choose to do so." >> >>First, one thing that marks the sane adult from the child and the floridly >>psychotic adult is the sane adult's knowledge that "feelings" and "facts" >>are two different things. >> >>It is one thing to "feel," as J. Bell or all of us might, that our rights >>have been violated. >> >>It is another thing to maintain, as J. Bell uniquely appears to do, that >>the "feeling" gives him the right to seek another person's death. > >You're clearly confused. I was responding to an accusation that I was >defending seeking somebody's death simply because of a disagreement of >OPINION. My comment was intended to remind the reader that it is the >ACTIONS of a person which justify the self-defense; not simply the >disagreement. I disagree and I believe that my quote (reposted by J. Bell) of his original statement supports me. He mentioned "ACTIONS" and he mentioned "OPINIONS" but he relied on his "feelings" as the touchstone of reality. More than ever I believe that he genuinely cannot understand the difference. He still confuses his "feelings" which exist nowhere but inside his head with "ACTIONS" which exist outside his head in the real world. He shows similar confusion as he continued to write. > >You falsely imply that a person can't be correct in his assessment that his >rights were, indeed, violated. > I implied no such thing. If anything, I implied the opposite. Human beings can assess reality. But they do not do so with "feelings;" they do so with intellectual reality testing, not emoting. > >> >>This and other posts by J. Bell and other lib'bers lead me to believe that >>their claimed interest in human freedom for everyone is little more than a >>cover for a set of authoritarian expectations that they can do whatever >>they want, free from any control, responsibility, or accountability. > >Since you just got through misrepresenting my position, probably >intentionally, it's pretty hard to take the rest of your opinions seriously. > >>The argued centrality of J. Bell's "feelings" over other people's lives is >>something that puts him in the god category. (Thankfully J. Bell is not one >>of the dreaded tax collectors or "socialist statists.") > >You're wrong yet again. Let's see, tallpaul needs a logic lesson: > >Let's suppose I _believe_ my rights are being violated. While that, in >itself, does not guarantee that this is CORRECT, on the other hand it >doesn't mean that it is INCORRECT, either. You're falsely implying that I >was ignoring the issue of correctness; I wasn't. > If he was not ignoring "correctness" I neither know nor see where in his original post he mentioned this. He may wish to give me a "logic lesson" over the issue of observation, but this also seems lacking in his post. --tallpaul

1 0

A brief comparison of email encryption protocols
by Raph Levien 17 Dec '03

17 Dec '03

This message briefly reviews and compares the four major email encryption protocols under discussion: MOSS, PGP, PGP/MIME, and S/MIME. Each is capable of adequate security, but also suffers from the lack of good implementation, in the context of transparent email encryption. I will try to address issues of underlying cryptographic soundness, ease of integration with email, implementation issues, support for multimedia and Web datatypes, and backwards compatibility. An additional grave concern is key management. Contrary to some beliefs, key management is not a solved problem. All of the proposals contain some mechanism for key management, but none of them have been demonstrated to be scalable to an Internet-wide email system. My belief is that the problems with key management do not stem from the classic Web of trust/certification hierarchy split, but the nonexistence of a distributed database (with nice interfaces) for holding keys. The encryption protocols also stand in the way of such a database, with key formats that are either overly complex, inadequate, or both. In case it is not clear by now, this review will be quite subjective, in many cases representing my own beliefs rather than objective fact. I'll try to point that out where I can. Also, I do not claim to have a thorough understanding of PEM and PKCS. Much of my knowledge comes from implementing premail, a tool that acts as "glue" between mailers and encryption packages. It supports PGP, MOSS (using the TIS/MOSS 7.1 implementation), and a draft of PGP/MIME, in addition to a wide range of anonymous remailer services. While usable, premail has many limitations, and certainly does not represent the "holy grail" of transparent email/crypto integration. Thus, my participation in the Internet Mail Consortium Secuirty Workshop (http://www.imc.org/security-workshop.html) I apologize for the wide distribution, and ask that followups be trimmed. PGP --- PGP (Pretty Good Privacy) is, of course, the de facto standard for email encryption on the Internet. PGP's underlying cryptography is quite sound - RSA (up to 2048 bits with the most recent implementation), IDEA with a 128 bit key, and MD5. PGP is entirely in accordance with the recent recommendations on minimum keylength (http://www.bsa.org/bsa/cryptologists.html) and in fact does not include a mode of operation in violation of those recommendations. This makes PGP (and, by extension, PGP/MIME) unique among the encryption protocols. PGP is packaged in a single application (i.e. a single binary) which performs encryption, decryption, signing, verification, and key management. It does not depend on the existence of great deal of infrastructure. These factors have, in my opinion, been decisive in PGP's popularity. However, PGP is still not suitable for fully transparent email encryption. The reasons are complex, and I will only touch on them here. The main missing feature is the lack of MIME integration. Thus, PGP is not suitable for multimedia types other than US-ASCII text. PGP does contain some support for 8-bit charsets, but at cross-purposes with MIME. Signature checking of non-US-ASCII data is simply not reliable. To give an idea of this problem, the most recent international version (2.6.3i) tries several different character set conversions when verifying signatures, to see if any of them will work. However, since a large fraction of email _is_ US-ASCII text, this feature alone probably does not explain the lack of deployment. PGP contains a number of implementation flaws (including silly things like not locking files, so that concurrent invocations fail). In addition, key management has some problems. Mostly, key management is hard to learn, time consuming, and requires a great deal of manual intervention. The "Web of trust" is supposed to fix this, by providing transitive trust of key authenticity. However, in practice the Web of trust has not delivered. In my experience (with many dozen correspondents), I have only had one or two keys transitively trusted. A standard PGP-signed message consists of a "-----BEGIN PGP SIGNED MESSAGE-----" line, the signed text (subject to some canonicalization rules), a "----BEGIN PGP SIGNATURE-----" line, a version line, the PGP signature itself, and an "-----END PGP SIGNATURE-----" line. All this is in the message body. The headers indicate that the message is a standard 7-bit, us-ascii, text/plain message. Thus, mailers have to parse the message contents to identify the message as PGP signed, or to extract the signed parts. This is at cross-purposes with MIME. Mailer implementors are reluctant to include such ad-hoc extensions. Existing extensibility mechanisms, based on MIME, cannot be used. PGP encrypted messages are similar - the identification as an encrypted message can only be made by parsing the message body. One technical problem with PGP is its inability to support single-pass processing, because the data format includes a size field. PGP/MIME -------- PGP/MIME is an effort to integrate MIME and PGP. There is a workable draft based on the MIME security multiparts, but the PGP/MIME mailing list is divided. Some particpants are happy with the existing draft, while others feel that other points in the design space (for the most part, labelling existing PGP message formats with appropriate MIME types) would be better. The design space is large and complex, with many constraints on efficiency, simplicity, backwards compatibility, and functionality. It is not clear that a consensus will develop at all. There are two implementations of the PGP/MIME draft: premail, and the PGPMIME reference implementation by Michael Elkins. For more information about the PGP/MIME draft, see http://www.c2.org/~raph/pgpmime.html . PGP 3.0 ------- Many people are hoping that PGP 3.0 will somehow come along and solve all their problems. PGP 3.0 is only an evolutionary improvement over the existing implementations (MIT PGP 2.6.2 and PGP 2.6.3i). For the most part, it will support only the existing message formats. There may be support for decoding draft PGP/MIME signed messages, but this is still being negotiated. The main advance in PGP 3.0 is a cleaned up implemenation. The PGP 2.6.2 code is disgusting, and should not be integrated directly into any mailer application. The 3.0 code will be modular and based on published interfaces. Furthermore, the 3.0 development team plans to release the code as both a stand-alone application and as a library. It is difficult to predict when the public release will happen. Based on what I've seen, fall of 1996 seems the most likely. MOSS ---- MOSS (MIME Object Security Services) is an attempt at an email encryption protocol in accordance with MIME. It is currently an Internet RFC. There is a reference implementation (TIS/MOSS 7.1). MOSS is mostly cryptographically sound. However, the choice of symmetric encryption algorithm (and key size) is left unspecified. Thus, it cannot be said that MOSS is in accordance with the recommendations for minimum keysize. In fact, the only public implementation, TIS/MOSS 7.1, uses 56-bit DES, which is in direct violation of these standards. The TIS/MOSS implementation has a number of other problems. It is big and complex, probably due to its TIS/PEM ancestry. For more information about TIS/MOSS, see http://www.tis.com/docs/Products/tismoss.html . MOSS supports two modes of key management: X.509, and completely manual key management. In this way, it is a dramatic advance over PEM, which only supported X.509, but life for implementors remains hard. One feature which I believe is sorely lacking is a cryptographic hash of the public key as the basic unit of manual key management. Thus, people either have to trust the mechanism by which the key was delivered, or examine the base-64 representation of the entire key. I consider this to be a serious usability problem. For an example of how hashes of keys have been done right, see Netscape 2.0's handling of untrusted certificates. S/MIME ------ S/MIME is an attempt to graft MIME support onto underlying PEM standards. See http://www.rsa.com/rsa/S-MIME/ for more info. I feel compelled to deal harshly with RSA's S/MIME FAQ (http://www.rsa.com/rsa/S-MIME/smimeqa.htm) It suggests that MOSS has interoperability problems because of multiple implementations, while S/MIME presumably doesn't. I take strong exception to this statement. There is no technical basis for it. I consider the possibility of admitting multiple implementations as a _requirement_ for an Internet email standard. However, because S/MIME is documented, it hopefully will be possible to create independent implementations, in spite of what RSA says. The only symmetric encryption algorithm mandated by S/MIME is 40-bit RC2. Thus, S/MIME is in violation of the key size recommendations. Further, RC2 has not been confirmed to be publicly known. If RC2 is not known, then an independent implementation of S/MIME is impossible. Fortunately, source code for an alleged implementation of RC2 has recently been posted to the Internet, resolving this problem, if it is authentic. If not, then my reservations remain. S/MIME also recommends 56-bit DES CBC and (either 112 or 168 bit) DES EDE3-CBC. This is good; any S/MIME implementation in accordance with the recommendations will conform to the keysize recommendations as well. S/MIME remains firmly grounded in the X.509 certification hierarchy, although the FAQ claims that the guidelines for hierarchies are "more flexible" than in PEM. One cryptographic weakness of S/MIME is that eavesdroppers can distinguish between encrypted and signed-and-encrypted messages. This violates the principle of disclosing a minimum amount of information. PGP, PGP/MIME, and MOSS do not have this problem. Probably the most controversial aspect of S/MIME is its signature format. An S/MIME signed message is a MIME multipart in which the first part is the data to be signed, and the second part is a complete PKCS #7 (section 10) signed message. This protects quite well against munging by mail transport, but has two problems. First, the size of the message is doubled. Second, the fact that the two singed messages are identical is not enforced (if it were, mailer munging would cause too many signatures to fail). Thus, Eve can send Alice and Bob a message (M1, (M2, Signature(M2))). Alice, not having an S/MIME implementation, would see only M1. Bob, having an S/MIME implementation, would see only M2, for which the signature would check. Alice, being suspicious, might call Bob up on the telephone and ask whether the signature was really valid. Bob would of course say yes. Unless they compared notes on the contents, they would not notice the discrepancy. To my mind, this counts as protocol failure, and thus it is not possible to claim that S/MIME conforms to best cryptographic practice. I would expect that doubling the message body will create performance problems in a Web environment. For example, if the first message is used for display, then it becomes necessary to compare the two messages. If, instead, the second message is used, then the first message will be responsible for significant added latency. Integration with mailers ------------------------ Integration with mailers is quite difficult. In general, the mailer implementor will need to add specific features to support cryptography. Because of the restrictiveness of ITAR regulations, such an approach may not be practical for US developers, at least while supporting strong cryptography. Perhaps the biggest feature required in the mailer is integration of key management and the "address book". If this feature is not implemented in the mailer, then two address books are required - one to select email addresses, and another to map email addresses to keys. This approach is used by premail, and is the source of many usability problems. It would be nice if a database existed which could map email addresses to public keys without manual intervention, but none of the proposals on the table are capable of it. Such a database would certainly improve usability, as well as making it considerably easier to Another feature that is required for fully transparent integration is caching of decrypted session keys. If not implemented, then the user interface delays in navigating a mail folder become unacceptable. To my knowledge, no implementation supports this feature. One dimension in the design space is whether the cryptographic engine is tightly integrated with the mailer (i.e. shares an address space), or is a separate process that communicates with the mailer. Both approaches have been implemented. Both approaches are subject to numerous pitfalls, which have unfortunately not been entirely avoided. These issues have more to do with implementation than with the encryption protocol, but I thought I'd mention them here, so that they are not actively thwarted. Conclusion ---------- All of the proposals described here can be used for secure email. None of them will be widely deployed in this capacity unless they are implemented well. I have concerns that both MOSS and S/MIME are susceptible to political pressure which will restrict key sizes insecurely in practice. I would like to see consensus develop around one of the proposals, so that energies used for implementation can be more focussed and effective. It is my hope that this conference will move in that direction. Raph Levien

2 1

A good cryptanalysis text?
by Sherry Mayo 17 Dec '03

17 Dec '03

> Hi all > > A friend of mine is looking for a good introductory cryptanalysis > text. Does Schneier's book cover this in much depth or is it more > cryptography as the name implies. > > My friend is a computer networking admin who is trying to widen > his background knowledge of security related issues (this may > mean that a more computing oriented intro is more suitable). > > Thanks in advance for any suggestions. > > Sherry > >

2 1

Re: Fair Credit Reporting Act and Privacy Act
by tcmay＠got.net 17 Dec '03

17 Dec '03

At 11:28 AM 2/9/96, Duncan Frissell wrote: >Look, the reason we hate the CDA is because it restricts speech. >Restrictions on credit agencies gossiping about you are also speech >restrictions. If you are out in the world, people are going to talk about >you. The credit agencies are much easier to handle and less intrusive than >the women were who talked about you while beating cloth on the rocks in the >stream back in the old village. Recall that in 1914 America adopted the "Gossiping and Busybodies Fair Reporting Act," requiring all gossipers and busybodies to register their planned speech acts with the typically-named Privacy Ombudsman (now Ombudsperson). The modest registration fee of $75, a lot of money in 1914 of course, appears to have had a chilling effect on this market, as there are few if any gossiping women beating clothes on rocks at the stream. More seriously, what I find useful when thinking "There ought to be a law!" thoughts is to imagine how it might be enforced against _me_. Creative visualization. For example, while I get angry at times with TRW and TransUnion like everyone else, I imagine a welter of laws about the keeping of records and I imagine someone coming to *my* door and announcing that he was there to inspect the contents of my hard drives to determine if I had unlicensed data. (Tim Philp's idea that this would only apply to "corporations" or "businesses" (not clear which he means) misses the point. Am I, for example, a business? Having such laws kick in at some well-defined threshold would simply shift the nature of the information-gatherers...for example, they's subcontract out the record-keeping to a raft of smaller, linked entities. Then you'd have to prosecute people and companies for accessing illegal data banks, etc.) I am willing to support a few laws, about murder, theft, rape, etc., but not busybody laws trying to control what information people collect. If someone asks what the relevance to this list is of this issue, then they really are as dumb as dirt, and as dumb as endangered dirt, too. --Tim May Boycott espionage-enabled software! We got computers, we're tapping phone lines, we know that that ain't allowed. ---------:---------:---------:---------:---------:---------:---------:---- Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay(a)got.net 408-728-0152 | anonymous networks, digital pseudonyms, zero W.A.S.T.E.: Corralitos, CA | knowledge, reputations, information markets, Higher Power: 2^756839 - 1 | black markets, collapse of governments. "National borders aren't even speed bumps on the information superhighway."

2 1

Cypherpunks in 3/96 WIRED -\"Wisecrackers\" by Steven Levy
by John Young 17 Dec '03

17 Dec '03

Indeed, congrats Steven, a swell, crackerjack story well told. Flattering exhibits of Damien and DW. Ponder the garish payback frontis-pieces announcing Steven's tale of "a throbbing collaborative network of potential crackers -- and, maybe, thieves and saboteurs." Steven, your credit sez the next book is "Crypto," about the revolution in cryptography. Can you give a date for publication?

1 0

Re: anonymous age credentials, sharing of
by tcmay＠got.net 17 Dec '03

17 Dec '03

At 7:38 PM 2/14/96, Michael Froomkin wrote: >Suppose Alice is a CA who issues anonymous age credentials. >Bob is 15 >Carol is 25 > >Carol gets a legitimate anonymous age credential from Alice bound to an >anonymous public key generated for this purpose. Carol then gives the >key pair to Bob. Bob uses to do things only adults are legally permitted >to do. (It's not bound to Carol's everday keypair because that's not >anonymous....) > >What can stop Bob and Carol from subverting a scheme that relies on >anonymous age creditials in this manner? Nothing, except biometric methods (fingerprints, retinal scans, electronic signatures (the pen type), DNA, etc.) That is, if the credential is transferrable by transfer (not a syllogism), then it can be transferred. If, however, the credential needs some input from a local biometric input device, then this makes it harder to transfer the credential. Unless the biometric device is bypassed.... (Likewise, Carol could log on to the illegal activity and "let Bob watch." Another form of bypassing viewing credentials.) >If the answer is "nothing" this might mean that purveyors of "adult" >material might have no defense against a law requiring that they collect a >True Name + age creditential.... There are interesting questions here....mostly I think of the "True Name" as only another credential, but this is a complicated argument to make, and I don't have the time right now. (Also, Perry is even now composing a "what does this have to do with cryptography?" perrygram.) --Tim May Boycott espionage-enabled software! We got computers, we're tapping phone lines, we know that that ain't allowed. ---------:---------:---------:---------:---------:---------:---------:---- Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay(a)got.net 408-728-0152 | anonymous networks, digital pseudonyms, zero W.A.S.T.E.: Corralitos, CA | knowledge, reputations, information markets, Higher Power: 2^756839 - 1 | black markets, collapse of governments. "National borders aren't even speed bumps on the information superhighway."

1 0

Hey Derek: who are you? (toad.com is glitching...)
by jf_avon＠citenet.net 17 Dec '03

17 Dec '03

Would the author of this message please reply to me by e-mail? I received it under the name <owner-cypherpunks(a)toad.com>, with no subject whatsoever. The remailer is freakin' out... >The other question I have is: who do you think the "customers" of PGP >are? If you think the majority of PGP's customers are the >crypto-privacy activitst types, you are highly mistaken. PGP has hit >the main stream, and is being used by many non-crypto-aware people. >Probably more of them than there are of us. > >If you want to discuss this more, let's take it to private email, >please. > >-derek > > **** NEW PGP 2.6.2 KEY ********* 2048 bits Key ID:24201BA1 1996/02/13 Jean-Francois Avon <jf_avon(a)citenet.net> Key fingerprint = 23 B6 24 31 86 67 FB 35 C7 A7 AF 12 A1 61 E9 3D **** OLD KEY: DO NOT USE ANYMORE UNLESS FOR VERIFYING SIGNATURES **** 1024 bits Key ID:57214AED 1995/10/04 Jean-Francois Avon <jf_avon(a)citenet.net> Key fingerprint = 84 96 76 AE EB 7C AB 15 88 47 87 B0 18 31 74 9F

1 0