- cypherpunks-legacy - lists.cpunks.org

Re: POST:Gaining ISDN Privacy with data encryption
by andreas.elbert＠gmd.de 17 Dec '03

17 Dec '03

> >Making the public ISDN network private is possible though data encryption to >maintain security, say a pair of ISDN researchers whose organization is soon >to become and ISDN user. > They probably are right :-) A daughter of the german PTT has been offering ISDN-DES-phones for some years now. Welcome to the Club !

1 0

Zimmermann & Johnson at Sept. RMIUG
by adwestro＠ouray.Denver.Colorado.EDU 17 Dec '03

17 Dec '03

I have been told that noted Colorado crypto experts Phil Zimmermann and Mike Johnson, along with Phil's attorney, Phil Dubois, will be panelists at the September meeting of the Rocky Mountain Internet Users Group. The meeting will be on Tues. 9/13, 7-9 pm at NCAR in the Sovereign Republic of Boulder. Corrections/additional info gratefully accepted. Alan Westrope <awestrop(a)nyx.cs.du.edu> __________/|-, <adwestro(a)ouray.denver.colorado.edu> (_) \|-' PGP 2.6 public key: finger/servers PGP 0xB8359639: D6 89 74 03 77 C8 2D 43 7C CA 6D 57 29 25 69 23

1 0

number of 2-way radios
by Carl Ellison 17 Dec '03

17 Dec '03

Does anyone have rough figures on the number of cellular phones produced versus the number of military 2-way radios ever produced? I'd be willing to bet the former far exceeds the latter, but it would be nice to have real figures. - Carl

1 0

e$: Economic Development of the Caribbean
by rah＠shipwright.com 17 Dec '03

17 Dec '03

In article <CuIyqC.MHA(a)ecf.toronto.edu>, francis(a)ecf.toronto.edu (FRANCIS ALVIN CYRILLE) wrote: > What are the major factors hindering economic development in the Caribbean..? I've been interested in this for a long time. I've started to form some ideas about it, and here they are. 1. No effective public health system. (Not really socialized medicine, just sanitation, epidemiology, etc.) 2. No educational infrastructure. 3. Monopolistic control of political structures. 4. Monopolistic control of critical markets. The above are interrelated, thus the ranking is only superficial. As island states with few resources, the nations of the caribbean can't afford to have political and economic monoculture. Small islands with few resources (Singapore, Hong Kong, Japan and the British Isles) must trade or die. Uniparty states, with sweetheart deals to extract resources and ship them away, tend to make their people poorer, unless there's an extreme premium on the resource (oil, guano, etc). Brunei, where the sultan owns everything and is the country's the richest in the world anyway (per capita) is a great example of being able to "afford" monopolistic political and market control. They have enormous oil reserves with which to pay for all the eggregious excesses of the government/theocracy, and still have lots left over for education, public health, and universal health access. It's interesting to think that that's pretty much what Fidel did in Cuba. His "premium resource" was a strategic position 90 miles off of Florida that was very very valuable to the USSR. Life gets better someplace only as the life expectancy goes up. This is called the Demographic Transition, and it is marked by a sharp decline in population growth as life expectancy crosses 50 years. People won't have children as a substitute for retirement pensions when they can see that they will be healthy enough to take care of themselves for most of their whole life. Children become a want rather than a need, and population growth tapers off. Most of the USA's population growth comes from immigration. Singapore has state-sponsored latin dance classes to get their citizens interested in having families earlier. (Go figure) The quickest way to drive up life expectancy is through public health. If people won't die from malaria or typhus or cholera or diptheria, or river blindness, or whatever, because their water's clean, and their wastes don't get back into their food chain, then their life expectancy doubles overnight. I stayed in the Galleon House in downtown Charlotte Amalie for a week a few years ago, and the open sewers are still right there out on the street. I remember seeing a "creek" running through an alluvial plain of shacks just outside St. John in Antigua, and the water was purple-green with raw sewage. The reason that this hasn't changed is because the population hasn't demanded it, and the reason for that is that they're not given enough education. The reason for that is that the governments are filled with people who want to line their own pockets, and can do so because they hold generational political dynasties. This is usually because of some sweetheart deal with an extractive monopoly/oligopoly, which can "contribute" large piles of cash to whoever does them a favor. If there was more of a trading tradition in the caribbean it would help drive growth. There are a few places where that has happened before and can happen again. St. Thomas, unencumbered by US government subsidy and regulation might be one, if those if monoparty cronyism didn't kill it. It had been a huge shipping and trading port for centuries. Now its primary function seems to be shaking down tourists. Trade of a sort, I suppose. Which leads me directly to another reason I'm interested in the small island nations of the caribbean. The idea of internet commerce. There are people in some circles in the net who think that the internet provides a perfect opportunity for people to buy and sell software and information securely and even anonymously. To do this properly one would need to reduce restrictions on cash transactions, the transfer of capital, and the use of strong cryptography. Cryptography is the enabling technology for the transfer of assets and money in a secure fashion over unsecure networks. The first result is that people can work anywhere they want. Personally, I think Boston is nice, but I'd rather hang in Cruz Bay for most of the year if I could get away with it. We just had a discussion in soc.culture.caribbean about the lack of full-blown USVI internet access which talked about that. You could have a whole class of "lifestyle refugees" coming from the developed world to the caribbean because they can work anywhere they want. This literally foriegn trade, only now a nation is re-exporting intellectual property. Sort of like a fair-weather maquilladora with imported gold-collar workers. Think about the development of america in the 19th century. The railroads brought immigrants from europe, who then homesteaded land and sold the agricultural products they grew to people who processed them into goods which generated foriegn exchange, which paid for interest on bonds that J.P. Morgan & Co. sold to the european money centers. Some of those bonds were then used to build more railroads, which brought in more settlers, etc. The other neat thing about this process is that it automatically brings in foriegn exchange and development capital which is independent of monopolistic controls. These "refugees" have to buy things, but they buy them from local, distributed sources: shops, builders, tradesmen, etc. Those people automatically have an independent entrepreneurial outlook, which is reflected eventually in the political and economic structure of the nation. You get a quasi-Jeffesonian nation of shopkeepers, tradesmen, and as their children are educated, technical/information professionals who work on the net for a living. This is how a nation can build a trading tradition from the ground up. Finally, the electronic money (e$ for short) which enables this commerce has to be denominated in something, probably dollars. The entities (call them banks, for the time being) have to live somewhere. These entities are responsible for moving assets and money on and off the internet and make their money by either taking a small fee (called a spread) when converting money from one form to another, or from collecting the interest (called the float) on the dollars that were converted into e$, but haven't been converted back to other dollars yet. The cool thing is that some caribbean nations have figured out offshore banking already. The reason this kind of banking is valuable is the concept of regulatory arbitrage. Regulations impede the flow of money. The Netherlands Antilles have made a reasonable living domiciling corporations whose sole purpose is to keep money out of the american banking system and thus its tax mechanism. Money made offshore which stays offshore doesn't get taxed as easily by the IRS. Regulatory Arbitrage is also exemplified by the banking and insurance industries of the Bahamas, the Caymans, Bermuda, and to a lesser extent, Antigua and the EC (Eastern Caribbean) nations. In those cases, those nations have modeled bank secrecy laws like those of the swiss. In order for a nation to become an e$-center, they would have to allow the creation of e$, particular dollar-denominated e-cash on their shores. There are enourmous regulatory hurdles in the US, but with a sufficiently arbitrary and capricious political infrastructure, it could happen pretty soon in the caribbean, if it was worth someone's while... Ah, the ironies of economics... Cheers, Bob Hettinga -- Robert Hettinga (rah(a)shipwright.com) "There is no difference between Shipwright Development Corporation someone who eats too little 44 Farquhar Street and sees Heaven and someone Boston, MA 02331 USA who drinks too much and sees (617) 323-7923 snakes." -- Bertrand Russell

1 0

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

First Virtual
by L. Todd Masco 17 Dec '03

17 Dec '03

Does anybody know anything about a new company named "First Virtual"? I know they got NSB from BellCore and a couple of other researchers. -- L. Todd Masco | "Cowboy politicians sucking up to the aristocracy, not cactus(a)bb.com | even sure if they like democracy..." - TR-I

1 0

Re: First Virtual
by Jef Poskanzer 17 Dec '03

17 Dec '03

>Does anybody know anything about a new company named "First Virtual"? I > know they got NSB from BellCore and a couple of other researchers. % whois first | egrep -i virtual First Virtual Corporation (FVC-DOM) FVC.COM First Virtual Corporation (NET-FVC) FVC 199.181.72.0 First Virtual Holdings Inc. (NET-FV-NET) FV-NET 199.171.113.0 First Virtual Holdings, Inc. (FV-DOM) FV.COM First Virtual Holdings, Inc. (THECARD-DOM) THECARD.COM First Virtual Holdings, Inc. (CARD-DOM) CARD.COM % whois fvc.com First Virtual Corporation (FVC-DOM) 3393 Octavius Drive, Suite 102 Santa Clara, CA 95054 Domain Name: FVC.COM Administrative Contact, Technical Contact, Zone Contact: Gallmeister, Bill (BG43) postmaster(a)FVC.COM (408) 738-2220 Record last updated on 22-Apr-94. Domain servers in listed order: NS1.SVC.PORTAL.COM 156.151.6.20 UUCP-GW-1.PA.DEC.COM 16.1.0.18 UUCP-GW-2.PA.DEC.COM 16.1.0.19 % whois fv.com First Virtual Holdings, Inc. (FV-DOM) POB 3627 Rancho Santa Fe, CA 92067-3627 Domain Name: FV.COM Administrative Contact: Stein, Lee (LS48) leestein(a)SCRIPPS.EDU 1 619 759 9300 Technical Contact, Zone Contact: Rose, Marshall T. (MTR) mrose(a)DBC.MTVIEW.CA.US (415) 968-1052 Record last updated on 19-Mar-94. Domain servers in listed order: DBC.MTVIEW.CA.US 192.103.140.1 TRYSTERO.RADIO.COM 192.101.98.3

1 0

Re: cfs & remailers
by markh＠wimsey.bc.ca 17 Dec '03

17 Dec '03

> Another potential problem with sendmail->cfs interaction is that > CFS doesn't implement NFS file locking. This isn't much of an issue with > a single host and a single instance of CFS, but could be a problem if the > mailboxes are read and written by other machines or are remotely mounted > by the machine running sendmail. Some versions of sendmail support "dot locking", which effectively does away with this problem. Mark

1 0

Zimmermann debate with NSA on 8/25
by Philip Zimmermann 17 Dec '03

17 Dec '03

Subject: Zimmermann/NSA debate in California There will be a debate between Philip Zimmermann and Clinton Brooks of the National Security Agency, on Thursday, 25 August, at 5:45pm Pacific Time, in Thousand Oaks, California. The debate is organized by the World Affairs Council, and will be held at the Thousand Oaks Inn, at 75 Thousand Oaks Blvd. To get there, take Highway 101 north from LA to the Moorpark exit, turn right onto Moorpark, left at first light, one block down on right side. The debate will be on the issues of crime, terrorism, privacy and civil liberties on the information superhighway, and the role of cryptography in these issues. Philip Zimmermann is the creator of Pretty Good Privacy (PGP), the most widely used software in the world for E-mail encryption. Zimmermann is under criminal investigation for publishing free encryption software, resulting in its widespread use around the world, allegedly in violation of US export restrictions on encryption software. Clinton Brooks is assistant to the director of the NSA, and was instrumental in the creation of the controversial Clipper Chip and the Escrowed Encryption Standard. There will be cocktails and a light buffet at 5:45, and the program will start at 6:30. Admission is $15 if you preregister, or $25 at the door. Preregistration can be done by mailing a check, or by credit card via phone or fax, to: World Affairs Council 1051 Calle Yucca Thousand Oaks, CA 91360 or call 805 498-6312 or fax 805 532-1306 (include credit card number, expiration date, and event) This announcement may be widely distributed.

1 0

Re: Remailer ideas (Was: Re: Latency vs. Reordering)
by wcs＠anchor.ho.att.com 17 Dec '03

17 Dec '03

> > What I think is a better idea was proposed here last year, and I think > > someone was doing it for a while. It is for someone to volunteer to > > be the keeper of the remailer aliveness information. He runs scripts > > every day to ping the remailers, keeps lists of which remailers are > > currently active, and so on. > > This does seem like a better idea, except for one thing: > Everybody has got to trust the Keeper of the Aliveness Info. > I'm not sure how much of a problem this is, nor am I sure that > the newsgroup method neccesitates any less trust. A major problem with having a single-point aliveness-info source is that watching traffic to that source gives you some idea who's about to send anonymous messages - multiple sources mean there are N sources to wiretap to get the same information, which may be nearly as bad. On the other hand, a broadcast method like a usenet group has the advantage that you can read the newsgroup without being very obvious, except locally. A mailing list is somewhere in between. Similar problems occur with anonymous single remailers in the absence of good reordering; many new remailer users, or users of unreliable remailers precede their real anonymous messages with a ping of some sort, such as a message through the remailer chain pointing back to themselves. If you're using a news reader without NNTP, or with NNTP only for the local non-tapped LAN, you may be ok. Another alternative are mailing lists (NOT human-readable ones like cypherpunks) which reforward the remailer newsgroup information, preferably encrypted. Newsgroups are obviously easy to inject bogus information into, but that's the way it goes; any non-trusted system is, well, non-trusted.... Bill

1 0