December 2003 - cypherpunks-legacy

PGP Time Bomb FAQ
by Michael Johnson 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- PGP TIME BOMB FAQ There has been some confusion about the annoying "Time Bomb" in MIT PGP 2.6, as well as some other PGP version compatibility issues. This is an attempt to clear up some of that confusion. WHY IS THERE A TIME BOMB IN MIT PGP 2.6? In the process of negotiating for the right to distribute a fully legal version of PGP that the patent assignees agree doesn't infring upon their patents, MIT agreed to include an inducement for people to upgrade from the alledgedly infringing freeware PGP 2.3a to the clearly legal freeware MIT PGP 2.6 or the also clearly legal Viacrypt PGP 2.7. Folks, you may not realize it, but the RSADSI/PKP concession to allow a freeware PGP in the USA is BIG TIME GOOD NEWS! To induce a small incompatibility with a downlevel version of PGP with several bugs in it is a small annoyance by comparison. WHAT IS THE NATURE OF THE TIME BOMB? On 1 September 1994 UT, by your system clock, MIT PGP 2.6 will start generating encrypted message and signature packets with a version byte (offset 3) of 2 instead of 3. It will accept either 2 or 3 as valid. This means that messages from PGP 2.3a and old messages from MIT PGP 2.6 can be read by MIT PGP 2.6, but new messages from MIT PGP 2.6 cannot be read by PGP 2.3a. See pgformat.doc in the MIT PGP 2.6 distribution for the location and use of these bytes. This time bomb is activated by code in pgp.c that looks like this: #define VERSION_BYTE_OLD 2 /* PGP2 */ #define VERSION_BYTE_KLUDGE 3 ... boolean legal_kludge; int version_byte = VERSION_BYTE_OLD; ... /* Turn on incompatibility as of 1 September 1994 (GMT) */ legal_kludge = (get_timestamp(NULL) >= 0x2e651980); ... if (legal_kludge) version_byte = VERSION_BYTE_KLUDGE; Although a method for disarming the time bomb is obvious to the casual C programmer, disabling this feature invalidates the RSA license to use the program, and really doesn't gain you much for reasons that will become obvious below. HOW DOES THIS TIME BOMB AFFECT COMPATIBILITY WITH OTHER VERSIONS? The bottom line is that PGP 2.3a and before (as well as Viacrypt PGP 2.4) cannot read all of the latest PGP version formats, starting on 1 September 1994. Here is a summary of the version bytes generated and understood: Format generated Formats before/after understood Version 1 Sep 94 (all times) - ---------------------------- ----- ---- ----------- 2.3 2 2 2 2.3a 2 2 2 Amiga 2.3a.4 2 2 2,3 Viacrypt 2.4 2 2 2 2.6ui 2 2 2,3 MIT 2.6 2 3 2,3 Viacrypt 2.7, pkcs_compat=1 2 3 2,3 Viacrypt 2.7, pkcs_compat=2 2 2 2,3 Viacrypt 2.7, pkcs_compat=3 3 3 2,3 (Not mentioned above is MIT PGP 2.5, which was a buggy beta, nor several other versions that are outside the mainstream PGP project). If you are using one of the versions above that cannot understand version byte 3 messages, you should upgrade to one that does. The upgrade from Viacrypt PGP 2.4 to Viacrypt PGP 2.7 is only US$10, and also provides several other enhancements. As you can see, people with downlevel versions of PGP will not be able to read all PGP messages directed at them, nor will they be able to verify all of the signed messages they might wish to verify. It is also worth noting that none of the new versions have any trouble reading the old format messages. WHAT IS THE RSA KEY MODULUS LENGTH LIMIT? The RSA key modulus length limit for compatibility with all mainstream PGP versions is 1024 bits (military grade). I recommend the use of this length, at least for now. PGP 2.3a, running on some platforms (but not others), use to be able to generate and use 1264 bit keys. In addition, some people have hacked their own copies of PGP to generate and use longer keys (up to 8192 bits or some such crazy number). Distribution of these hacked versions under the "Pretty Good Privacy" trademarked name is not recommended, since it upsets the trade mark owner (Philip Zimmermann) and interferes with some of his long term plans to support longer keys in a more organized fashion. IS 1024 BITS LONG ENOUGH? Conservative estimates of increasing computing power, advancing mathematical knowledge, and the propensity of certain spy organizations to spend lots of money on these things say that 1024 bit keys are strong enough for at least 20 years or so. Less paranoid prognosticators say that such keys are good for hundreds of years. More paranoid prognosticators think that someone has already broken RSA and not told us about it, so no RSA key is safe. My opinion is that RSA keys with a modulus of about 1024 bits in length is more than adequate to protect most electronic mail and financial transactions. What do you think? HOW DOES THE STRENGTH OF RSA AND IDEA COMPARE? As implemented in PGP, the IDEA cipher used for bulk encryption appears to be stronger than the RSA cipher. In fact, to strengthen the RSA to the same level as the IDEA cipher (assuming a brute force attack), it would take an RSA modulus of about 3100 bits. WHY NOT ALLOW LONGER RSA KEYS, ANYWAY? OK, so you are more paranoid than me, and want the RSA key to be at least as strong as the IDEA cipher. Why isn't there a higher limit to the RSA key size? First, there is the minor problem that RSAREF and BSAFE (which are tied to the RSA patent license for the freeware and some commercial versions of PGP) have a key length limit of 1024 bits. Changing this involves negotiations with RSADSI/PKP, and could take some time. Second, allowing longer key sizes could create a Tower of Babel problem of incompatible PGP versions, since not all versions could handle these long keys. Third, the implementation of longer keys needs to be done in an orderly manner such that all mainstream PGP versions (Viacrypt, MIT freeware, BSAFE-based commercial, and possibly a non-USA variant) are first upgraded to accept, but not generate, the longer keys. After all PGP users can accept the longer keys, then PGP versions can start generating the longer keys with no interruption in service. It still makes sense to have a length limit for compatibility reasons. I have asked Philip Zimmermann to increase that to at least 4096 bits when he can, and I think that he will do that in an orderly manner if there isn't too much in the way of hassles with RSAREF and BSAFE licensing. If this isn't secure enough for you, shift to conventional encryption and manual (direct person-to-person) key exchange, making sure that your keys have at least 128 bits of entropy. This can be done with pgp -c or another private key encryption program called dlock that has the virtues of (1) NO patent problems, and (2) very strong encryption. (DLOCK is not nearly as user friendly as PGP, but what do you want for free?) HOW DOES PKCS BYTE ORDERING IN KEYS AFFECT COMPATIBILITY? PGP versions 2.2 and before generated key and signature block formats with a different byte order than derived from the PKCS standards. PGP 2.3 also generated this old format if you specified +pkcs_compat=0 in config.txt or on the command line. This old format is now obsolete. Unfortunately, the old format cannot be parsed by RSAREF or BSAFE, so PGP versions based on these crypto engines (like MIT PGP 2.6) cannot read those packets. Viacrypt PGP, however, can still read both formats. Although this is annoying if you have a really old key that has lots of old signatures on it, the fact is that the older the key, the more likely someone has captured both it and the passphrase used to protect it. Therefore, I strongly recommend generating a new key and getting at least one other person to sign it. ARE MY OLD KEYS COMPATIBLE WITH MIT PGP 2.6? Unless they were created with the old, non-PKCS standard (i.e., created with PGP 2.2 or earlier, or created with PGP 2.3a with pkcs_compat set to 0), and unless they were created with a modulus of more than 1024 bits, then they are compatible. If a compatible key has an incompatible signature certificate, then the incompatible signature certificate will simply be stripped off by PGP 2.6. Otherwise, you can keep using your old key. In fact, if you just copy your key ring files to your new PGP 2.6 directory, then extract your old key with ASCII armor, it will be indistinguishable from a PGP 2.6 key, but have the same value, id, and signatures (assuming they were all in the PKCS format). WHY DOESN'T THE MIT KEY SERVER ACCEPT KEYS FROM PGP VERSIONS < 2.4? They don't want to be accused of contributing to the possibly infringing use of PGP 2.3a. WHY IS MY PGP 2.3a KEY ON THE MIT KEY SERVER? Because the MIT key server synchronizes with several non-USA key servers that run PGP 2.6ui or MIT PGP 2.6, and which accept keys from PGP 2.3a. When keys are extracted from those servers to synchronize with the MIT server, they appear to be coming from PGP 2.6, so they are accepted. WHY SHOULD I UPGRADE TO MIT PGP 2.6 FROM PGP 2.3a (BESIDES THE TIME BOMB)? First of all, if you are in the USA, the patent-legal status of MIT PGP 2.6 is good for your conscience. Second of all, there are a lot of bug fixes and features: Fixed a bug with the -z <passphrase> option. If no passphrase was given, PGP used to crash. When using -c, the IV is generated properly now, and the randseed.bin postwash is done. (This bug could have resulted in the same ciphertext being generated for the same plaintext, if the same passphrase is used.) Memory allocated with halloc() is now freed with hfree() in ztrees.c and zdeflate.c. (MS-DOS only.) The decompression code now detects end of input reliably, fixing a bug that used to have it produce infinite amounts of output on come corrputed input. Decompression has also been sped up. PGP -m won't try to write its final output to the current directory. This makes it less efficent if you want to save the text to a file, but more secure if you don't. If the line comment=<string> appears in the config file, the line "Comment: <string>" appears in ASCII armor output. Of course, you can also use this from the command line, e.g. to include a filename in the ASCII armor, do "pgp -eat +comment=filename filename recipient". PGP now enables clearsig by default. If you sign and ascii-armor a text file, and do not encrypt it, it is clearsigned unless you ask for this not to be done. The now enables textmode. Textmode detects non-text files and automatically turns itself off, so it's quite safe to leave on all the time. If you haven't got these defaults yourself, you might want to enable them. All prompts and progress messages are now printed to stderr, to make them easier to find and ensure they don't get confused with data on standard output such as pgp -m output. PGP now wipes temp files (and files wiped with pgp -w) with pseudo-random data in an attempt to force disk compressors to overwrite as much data as possible. On Unix, if the directory /usr/local/lib/pgp exists, it is searched fror help files, language translations, and the PGP documentation. On VMS, the equivalent is PGP$LIBRARY:. (This is PGP_SYSTEM_DIR, defined in fileio.h, if you need to change it for your site.) Also, it is searched for a default global config.txt. This file may be overridden by a local config.txt, and it may not set pubring, secring, randseed or myname (which should be strictly personal) The normal help files (pgp -h) are pgp.hlp or <language>.hlp, such as fr.hlp. Now, there is a separate help file for pgp -k, called pgpkey.hlp, or <language>key.hlp. No file is provided by default; PGP will use its one-page internal help by default, but you can create such a file at your site. On Unix systems, $PGPPATH defaults to $HOME/.pgp. PGP used to get confused if you had a keyring containing signatures from you, but not your public key. (PGP can't use the signatures in this case. Only signatures from keys in the keyring are counted.) PGP still can't use the signatures, but prints better warning messages. Also, adding a key on your secret key ring to your public keyring now asks if the key should be considered ultimately-trusted. Prviously, you had to run pgp -ke to force this check, which was non-obvious. On Unix, PGP now figures out the resolution of the system clock at run time for the purpose of computing the amount of entropy in keystroke timings. This means that on many Unix machines, less typing should be required to generate keys. (SunOS and Linux especially.) The small prime table used in generating keys has been enlarged, which should speed up key generation somewhat. There was a bug in PGP 2.3a (and, in fact in 2.4 and dating back to 1.0!) when generating primes 2 bits over a multiple of the unit size (16 bits on PC's, 32 bits on most larger computers), if the processor doesn't deal with expressions like "1<<32" by producing a result of 1. In practice, that corresponds to a key size of 64*x+4 bits. At the request of Windows programmers, the PSTR() macro used to translate string has been renamed to LANG(). The random-number code has been *thoroughly* cleaned up. So has the IDEA code and the MD5 code. The MD5 code was developed from scratch and is available for public use. Versions prior to 2.6 would not permit a new signature to be added to a key if there was an already existing signature from the same signer. Starting with version 2.6 newer signatures will override older ones *as long as the newer signature verifies*. This change is important because many keys have signatures on them that were created by PGP version 2.2 or earlier. These signatures can not be verified by PGP 2.5 or higher. Owners of keys with these obsolete signatures should attempt to gather new signatures and add them to their key. WHY SHOULD I UPGRADE TO MIT PGP 2.6 FROM PGP 2.6ui? If you are in the USA, PGP 2.6ui suffers from the same alledged patent infringement problems as PGP 2.3a. PGP 2.6ui also lacks most of the bug fixes and enhancements listed above since PGP 2.3a, since PGP 2.6ui is essentially just PGP 2.3a modified to accept both new and old packet version bytes (2 and 3). On the other hand, if you are outside of the USA and Canada, you should be careful not to offend the U. S. Department of State, Office of Defense Trade Controls, by exporting MIT PGP 2.6 from the USA or Canada. I suppose that you wouldn't break U. S. law if you got a copy of MIT PGP 2.6 that someone else exported, or you could get a copy of the PGP 2.6ui (that originated in Great Britain) if you don't care about the enhancements listed above, or if you want to be able to use 1264-bit keys. Note that if you use MIT PGP 2.6 in most countries, you are still bound by the RSAREF license because of the copyright law, and you are still limited in some countries to noncommercial use of PGP by the IDEA patent (unless you get a license from ETH Zurich). IS THERE AN EVIL PLOT, BACK DOOR, OR INTENTIONAL WEAKNESS IN MIT PGP 2.6? Not that I am aware of. It ships with source code, and I didn't see any way to hide such a thing in the source code that I looked at. Besides, if you really knew Phil Zimmermann, you would know just how repugnant such an idea is to him. IS THERE A LEGAL VERSION OF PGP FOR COMMERCIAL USE IN EUROPE? Not yet. To do that, you would have to (1) arrange to license the use of IDEA from ETH Zurich or wait for the coming triple-DES option in PGP, and (2) use the original (PGP 2.3a or 2.6ui) RSA code linked in with the new PGP (to avoid restrictions on the copyrighted RSAREF code). There is also the possibility of other local laws, such as those in France, restricting use of strong cryptography. IS THERE A LEGAL VERSION OF PGP FOR COMMERCIAL USE IN THE USA & CANADA? Yes. Use Viacrypt PGP for any commercial or personal use in the USA and Canada. I understand that there are some BSAFE-based PGP versions for commercial use in the USA, too, but you need to check with Philip Zimmermann on that to make sure that all of the copyright and licensing issues are handled properly. WHAT EXACTLY IS COMMERCIAL USE? I don't have an exact definition. Use some common sense. Are you encrypting sales reports, business plans, contract bidding information, and proprietary designs? Are your money making operations aided by the use of PGP? If so, and if one is available to you, you should buy the fully licensed commercial version. SINCE VIACRYPT PGP SHIPS WITH NO SOURCE, HOW DO I KNOW IT IS OK? Philip Zimmermann wrote or examined all of the source code. He says it is OK, so I trust him. I guess you have to decide for yourself. IS IT OK TO BUY VIACRYPT PGP, THEN USE MIT PGP FOR COMMERCIAL USE? RSADSI/PKP says it is not. On the other hand, since their only recourse is to sue you for damages, and since such a plan results in exactly the same revenue they would have if you did what they wanted, there are no damages to sue for. Personally, I use Viacrypt PGP except when beta testing PGP. IS THERE AN INTERCHANGE PROBLEM WITH THE DIFFERENT RSA ENGINES IN PGP? Fortunately, there is no problem interchanging RSA encrypted packets between original PGP, Viacrypt Digi-Sig, RSAREF, and BSAFE versions. They all do the same RSA computations. They are all different implementations of the same basic algorithm with a different legal status for each of them, which changes depending on what country you are in. The only annoyance is that unmodified copies of RSAREF and BSAFE can't handle more than 1024 bit RSA keys, but that isn't much of a problem (IMHO). HOW DO I UPGRADE FROM VIACRYPT PGP 2.4 TO VIACRYPT PGP 2.7 Call 800-536-2664 with your registration number, name, address, and credit card number handy. Hey, it is only US$10. No, I don't work for Viacrypt, nor do I get a commission on sales -- I just use Viacrypt PGP. WHERE DO I GET MIT PGP 2.6? By ftp: ftp://net-dist.mit.edu/pub/PGP/mitlicen.txt ftp://ftp.csn.net/mpj/README.MPJ ftp://ftp.wimsey.bc.ca/pub/crypto/software/README ftp://ftp.informatik.uni-hamburg.de/pub/virus/crypt/pgp/ Look for the files pgp26.zip, pgp26src.zip, and pgp26src.tar.gz. BBS: Colorado Catacombs BBS 303-772-1062 (free -- log in with your name) Hieroglyphics Voodoo Machine 303-443-2457 (log in as VOO DOO, password NEW) Download PGP26.ZIP, and for source, PGP26SRC.ZIP. Compuserve: Use IBMFF to look for PGP26.ZIP and PGP26S.ZIP. For a longer list, see the daily and montly postings on alt.security.pgp, or get ftp://ftp.csn.net/mpj/getpgp.asc WHAT KNOWN BUGS ARE IN MIT PGP 2.6? The function xorbytes doesn't. Replace the = with ^= to fix it. The effect of this bug is that RSA keys aren't quite as random as they should be -- probably not a practical problem, but worth fixing if you are going to compile the code yourself. DON'T SET PGPPASS when editing your keys, because if you do, and if you don't change your pass phrase, the key is lost. (If this happens, rename your backup keyring files to the primary files before you do anything else). These bugs have been fixed in the master source code, and will be corrected in the next release of MIT PGP. WHAT IS COMING IN FUTURE VERSIONS OF PGP? I won't steal the thunder from Philip Zimmermann, Jeff Schiller, Colin Plumb, and the rest of the team, but there is some neat stuff that they are working on. Transition from MIT PGP 2.6 and Viacrypt PGP 2.7 to the newer versions will be easier than transitions from other versions. If you have enhancements and suggestions for the PGP team, I suggest you coordinate with them so that your ideas can be integrated with the main PGP project. WHERE DO I REPORT BUGS IN PGP? Please send bug reports, bug fixes, ports to new platforms, and suggestions to pgp-bugs(a)mit.edu. WHERE DO I SEND OR FIND LANGUAGE KITS? If you have a language kit to share, you can also send it to me at mpj(a)csn.org for me to post on ftp.csn.net/mpj/public/pgp/, as well as sending it to some of the other PGP sites. IS PHILIP ZIMMERMANN STILL THE SUBJECT OF AN INVESTIGATION? Yes. He is still paying a lawyer lots of money to represent him, too. If you like PGP, then I would strongly suggest sending a donation to his defense fund at: Philip Zimmermann defense fund c/o Philip Dubois 2305 Broadway Boulder, Colorado 80304 USA CAN I REDISTRIBUTE THIS FILE? Permission is hereby granted to freely redistribute unmodified copies of this PGP signed file. ___________________________________________________________ | | |\ /| | | Michael Paul Johnson Colorado Catacombs BBS 303-772-1062 | | \/ |o| | PO Box 1151, Longmont CO 80502-1151 USA Jesus is alive! | | | | / _ | mpj(a)csn.org aka mpj(a)netcom.com m.p.johnson(a)ieee.org | | |||/ /_\ | ftp://ftp.csn.net/mpj/README.MPJ CIS: 71331,2332 | | |||\ ( | ftp://ftp.netcom.com/pub/mpj/README.MPJ -. --- ----- ....| | ||| \ \_/ | PGPprint=F2 5E A1 C1 A6 CF EF 71 12 1F 91 92 6A ED AE A9 | |___________________________________________________________| -----BEGIN PGP SIGNATURE----- Version: 2.7 iQCVAgUBLlDhNvX0zg8FAL9FAQHoZAP8C+XgqMzs1y0x1SHM45lzPzD8XK9JjjPk lHUSDlQ6uo5lRnBXxUVPpPlTmLW4E2AHvCM+mke4bsVbvNJnNK513tUELWDkGLf4 6rexV0wiZJ9VdnQW3HyN44Sug8/5W7mxmgbdIOwv4A+OOWwAqm/chOLXsFAVn1mP TLQSBl8sb3E= =Wq3r -----END PGP SIGNATURE-----

1 0

POST gaining ISDN privacy with data encryption
by Brian D Williams 17 Dec '03

17 Dec '03

REMEMBER: What fallows is a direct quote from the zine. | | ------------------------------------------------------------ | Communications News - August, 1994 | Gaining ISDN Privacy with data encryption | by Kevin Tanzillo | |Wunnava V. Subbarao, professor of electrical and computer |engineering Florida International University (FIU), along with |research associate Irma B. Fernandez, wrote a paper on testing and |evaluating encryption based data security in the ISDN environment. >Does anyone know where this was published, or where I might be >able to pick up a draft? >Adam I too am interested in this paper. I contacted FIU, Mr Subbarao is out of town till the end of the month, and his research assistant is off for a few days. (her husband had minor surgery) I left my number and will let the list know anything I find out. Can anyone else help? Brian Williams Extropian Cypherpatriot "Cryptocosmology: Sufficently advanced communication is indistinguishable from noise." --Steve Witham "Have you ever had your phones tapped by the government? YOU WILL and the company that'll bring it to you.... AT&T" --James Speth

1 0

Re: In Search of Genuine DigiCash
by mpd＠netcom.com 17 Dec '03

17 Dec '03

Robert Hettinga (rah(a)shipwright.com) writes: [Nice discussion of portfolio management elided] >> It is also unlikely that faith of financial institutions in >> supposedly unbreakable mathematics has been enhanced by the >> recent one-line fix announced for the DSS. > I don't think this is really a problem. It's just as if > somebody had figured out how to counterfeit money cheaper. > Countermeasures are taken and it isn't cheap anymore. The > neat thing about strong crypto is that it's strong in spite > of public algorithms. People who crack those algorithms > publish their results, or someone else will. The half-life > of a hidden innovation in that kind of environment is pretty > small. Ordinary counterfeiting is analog. Close inspection will always reveal differences which can be used to distinguish fake money. Counterfeit anonymous DigiCash, on the other hand, is indistinguishable from the real thing. If a bank is signing blinded notes for customers and has underwritten to exchange for cash any note bearing a verifiable signature, a cracked signature algorithm is a very serious matter indeed. The half-life of such an innovation could be practically forever, as long as the discoverer does not get greedy and his siphoning off of value remains hidden in the daily float. By the time the bank realizes that there seems to be much more ecash in circulation than they have issued, the perpetrator is likely to be long gone and the bank is likely to be kaput. If I cracked such an algorithm, publishing would be just about the last thing on my mind. Worst case scenario: Chemical bank announces "ChemCash", anonymous untracable Internet currency. Within 5 years, billions are in circulation, and all good citizen-units buy everything through the Web Shopping Network. Chaum wins the Nobel Prize in Economics. Chemical Bank Auditors notice that the books are looking funny, or at the very least, statistically strange. It is estimated that there are several tens of billions of dollars more ecash around than the bank has issued. Bank is insolvent. Congressional hearings. Government bailouts. Ecash falls from grace. Chaum joins inventor of lobotomy in Nobel Prize "Hall of Shame". Billionaire hacker Emmanuel Goldstein publishes his long-awaited memoirs from his estate in Argentina. He titles the book "How I Proved NP=P and Kept My Mouth Shut". "Hey - It could happen!" -- Mike Duvos $ PGP 2.6 Public Key available $ mpd(a)netcom.com $ via Finger. $

2 1

Re: RemailNet
by koontzd＠lrcs.loral.com 17 Dec '03

17 Dec '03

> A small historical note. It was not until 1986 that most >unauthorized interceptions of microwave radio common carrier >transmissions such as AT&T Long Lines TD-2 and TH routes were definately >and clearly made illegal (in the ECPA). Before that time such >interception for other than foreign government espionage purposes was a >gray area in the law, quite possibly there deliberately as was a curious >similar absence of any prohibition at all against interception of any kind of >digital data or record communications such as telegrams, twxs, faxes >etc. transmitted over any media. The Radio Act of 1934 makes no such distinctions, and does state that it is illegal to use information intercepted.

2 1

Re: In Search of Genuine DigiCash
by John Young 17 Dec '03

17 Dec '03

Responding to msg by mpd(a)netcom.com (Mike Duvos) on Tue, 16 Aug 9:21 AM >Ordinary counterfeiting is analog. Close inspection >will always reveal differences which can be used to >distinguish fake money. However, NY Times Monday reported in long front-page article on spread of digitized forged checks, including dupe of magnetic ID. Quotes: "The proliferation of desktop publishing has brought a new growth industry, the counterfeiting of virtually undetectable fraudulent checks, and banks and law enforcement officials say the cost to the economy could reach $1 billion this year. * * * The American Banking Association says [this] is the No. 1 crime problem facing banks. * * * It is much easier counterfeiting checks than cash." End quotes. Says center of activity is California but has spread to all parts of the US. ------------------------------- My standard pitiful offer to send this article upon email request. John

1 0

# or real Tim Mays....
by Jim choate 17 Dec '03

17 Dec '03

Hi all, I checked the Austin, TX phone book and found only 1 Tim(mothy) May. Considering that Austin is in the 350,000 range one might extrapolate the odds from there. In the Travis County area (where Austin is located) there is estimated to be 1 million cbu's ... Take it for what it is worth. Ravage (Info)Highway To Hell

1 0

new remailer remail@leri.edu
by sameer 17 Dec '03

17 Dec '03

A new remailer is running on remail(a)leri.edu. The key is: -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.6 mQCNAi5PKIUAAAEEALGSqJdXCiE2p0xq3V5pyVFx2q5m8TLas6PDNex8nKGc7Z15 GAD1KFGbIBz77BTDLY7fZkxOf0CWjlO8sQw4ofZeJosx4gfOPWsQL3Cf2PkEY2fV hO1rprZbLt2x3xsQPttEr5UsRw5tQJbQJnc1XBUQx3Wx++0EdPZ88ybouprJAAUR tCN0aGUgTEVSSSBSZW1haWxlciA8cmVtYWlsQGxlcmkuZWR1Pg== =UWc7 -----END PGP PUBLIC KEY BLOCK----- This is a "small" remailer--installed with my 1st generation installation script. (I think I sent the key to the servers..) -- sameer Voice: 510-841-2014 Network Administrator Pager: 510-321-1014 Community ConneXion: The NEXUS-Berkeley Dialin: 510-549-1383 http://www.c2.org (or login as "guest") sameer(a)c2.org

1 0

Re: In Search of Genuine DigiCash
by jim＠bilbo.suite.com 17 Dec '03

17 Dec '03

> "The proliferation of desktop publishing has brought a > new growth industry, the counterfeiting of virtually > undetectable fraudulent checks, and banks and law > enforcement officials say the cost to the economy could > reach $1 billion this year. > > * * * > > The American Banking Association says [this] is the No. 1 > crime problem facing banks. > This bring to mind the following question: Is there anything inherent in NON-anonymous digital cash schemes that make them more vulnerable to fraud, bribery or inside jobs? (I assume the schemes account for double spending and "counterfeiting" (however that applies to digicash).) Can a case be made that anonymous digicash is less risky (to a bank) than NON-anonymous digicash? Jim_Miller(a)suite.com

1 0

Too Much Marketing Hype, Too Many Cutesy Names
by tcmay＠netcom.com 17 Dec '03

17 Dec '03

I want to expand on my point about "cutesy" names. Believe me, I am not just picking on Bob Hettinga when I call "e$" a cutesy (and even execrable) name. But marketing hype is the bane of our age. People start picking company names long before they have anything to sell. Cleverness in naming is paramount. This is all fed by the thousands of mazazines, with most writers thinking that every section of an article has to to be tagged with a pun or clever phrasing. Thus we are barrraged with crap like "Toll booths on the Information Highway," Examples: * Digital Superhighway. Infobahn. I Way, etc. More coming every day. Every two-bit journalist wants to express his cleverness. Lots of bad puns, lots of stupid alliteration. * DigiCash, NetCash, EBux ("E bucks"..get it?), DigiFranques, E Bills (rhymes with "T Bills"), e$, Digidollars, etc. (About a year or so ago, someone was pushing hard to get "DigiMarks" accepted, with the abbreviation "DM." The name collision with Deutschmarks (DM) was apparently intentional. Clever, in a sophomoric way, but not useful. Similarly, "e$," with its U.S-centric resonances, is cute, but not very useful. And actually _misleading_, as it suggests a system tied to the U.S. dollar, when I presume no such linkage is intended.) Good and descriptive names are needed. In fact, the crypto community is probably lacking good names in some areas. "Digital cash" has a different flavor from "electronic money," which in turn has a different sense than a less flash description like "Chaum-style digital money." A lot of the confusion about NetCash not being "real" digital money, as one example, is over this naming confusion. So, good names are needed. Names that clearly evoke the underlying concepts, without misleading hype. But the "premature productization" that comes from naming things that don't yet exist with Madison Avenue-inspired names is where I think the problem lies. This is paralleled by the proliferation of company names...every consultant seems to have his own cutesy name. Don't get me wrong: names are important, and names don't have to be boring and banal. The issue is really about confusing the _naming_ of something with the _actual creation_ of items of value. I don't believe naming = creation, and creation is what interests me. (Yes, the term "crypto anarchy" was my naming, back in 1988. I thought it descriptive of the set of ideas, especially the political ideas. Perhaps I'm guilty, too, of too much hype. In any case, I've avoided such colonizations of name space in recent years.) --Tim May -- .......................................................................... Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay(a)netcom.com | anonymous networks, digital pseudonyms, zero 408-688-5409 | knowledge, reputations, information markets, W.A.S.T.E.: Aptos, CA | black markets, collapse of governments. Higher Power: 2^859433 | Public Key: PGP and MailSafe available. "National borders are just speed bumps on the information superhighway."

1 0

# of Real Tim Mays, RTM (r)
by John Young 17 Dec '03

17 Dec '03

Responding to msg by ravage(a)bga.com (Jim choate) on Tue, 16 Aug 12:57 PM Zero RTM (r) in Manhattan. Maybe more encrypted; only 60% here list.

4 3