- cypherpunks-legacy - lists.cpunks.org

No Subject
by nobody＠REPLAY.COM 17 Dec '03

17 Dec '03

Brief Background: In the last two months Australia (at this time under a so called conservative Liberal Government) has re-affirmed its anti-market controlled economy approach to economics with the establishment of an IT bureaucracy, forcing ISP's to 'join' the TIO and fund its operations, establishing the framework for a possible cencorship regime on the internet, proposed legislation for key escrow wrt VPN's and pursuing its favoured entrail reading approach to economics by yet again believing it can 'pick winners' in the market and allocate resources more efficiently than the market can; an approach any socialist or totalitarian would be proud to support. There is very little organised effort to oppose these measures. I expect that people elsewhere will soon be able to look to Australia as a testing ground for all the worst case scenarios long discussed on cypherpunks. Now the State has announced it's intention to forcefully mandate authentication on the internet by imposing yet another taxpayer funded bureaucracy and to hell with the market solutions already provided at no cost to citizens. Shame on you Australia. (Are politicians genetically selected on their ability to make precisely the wrong decision in any given circumstance? Actually wrt authentication there is no problem to solve. Doing nothing was the best thing to do. Of course what this is really about is limiting entry to markets, corruption and fraud on the public.) http://www.theage.com.au/daily/971015/news/news7.html Push to tie up loose ends on Internet By GERVASE GREENE, Canberra Online commerce may exceed $6 billion by 2001, but it will be of little use if customers and businesses cannot identify each other on the Net. Federal Cabinet yesterday approved steps to create a national system for online authentication. The Government will establish a body to oversee all authentication systems. The Communications Minister, Senator Richard Alston, said this would significantly boost electronic commerce. "With predictions that electronic commerce in Australia will increase more than four-fold to $6.3 billion by 2001, the Government is well aware that development of trust and confidence by businesses and consumers in the reliability and security of online transactions will be critical to the development of the information economy," he said. A group of industry and government experts will report by March next year on possible functions and powers of the watchdog. This will include determining the technical standards required before an identification system obtains certification. Several corporations have marketed safety systems to exploit concern about the safety of online transactions. Sophisticated encryption will also be necessary before certification is granted. Civil liberty groups have called for anonymous transactions to be possible, while law enforcement bodies have sought access to records and transactions that would amount to an effective exemption from privacy obligations.

1 0

Re: Encryption Program (fwd)
by Frank (Giff) Gifford 17 Dec '03

17 Dec '03

(I had only sent this to the 'other' mailing list and not here - my appologies to those who get this for a second time. -Giff) On Mon, 13 Oct 1997 semprini(a)theschool.com wrote: > Hello. I just posted an encryption program on the web. It uses a key- > generated pseudorandom stream of characters that get XORed with the > plaintext to produce the cyphertext. For decryption, the same stream > is run against the cyphertext. (Such is the nature of the XOR > operation.) You can download the program at: > > http://www.brigadoon.com/~semprini/3dmx > > I am interested in other people's views, comments, questions, etc. on > this program. Any questions, comments, etc. can be sent to me at > "semprini(a)theschool.com". > > Thanks, > > Dylan > I have downloaded the program and read over it's contents (the .frm files). It's Visual Basic, which I am familiar with. >From my reading of the code (assuming that the code I read was, in fact, the code which does the encrypting) - the key supplied is not used - or at least not directly. The user apparantly supplies three keys which are padded with 'random' stuff each to get them to 32 bytes in length. Then these are placed into a special array where each bit gets its own position and various scrambing is done 'randomly' on the data. This is dependent on the key values and what bits are on or off at a given time. During this process, the 'seed' for the RNG is reset to some unknown value (I believe the effective range for the seed is 0..65535) the entire time the bits are processed. Then, amazingly, those bits are not used again. >From the RNG, a 4 dimensional array (called a 'cube') is created with elements 0..15 for each of the four sides. The contents are filled from the RNG with a value 0..255. Then during the encryption process of a file, the program will choose four random numbers 0..15 to use as indexes into the cube. The number found there is XORed with the datafile byte to get the encrypted/decrypted answer. *whew* Hope you followed that, I'm trying to be complete and concise. The upshot seems to be (and I haven't written any code to try this out yet): This method fails to the chosen plaintext attack where I ask the opponent to encrypt a large file of (say) all zero bytes. The encrypted result I should then be able to XOR directly against the target file to get the original contents. A less efficient but more satisfing method is to simply try all seed values for the RNG. Even if I don't know the RNG process, if the seed values are only 0..65535 (as I believe they are), trying all possible decryptions by this manner will give me the correct answer. If I know something about the file (i.e. being English text) I should have no problem finding the right answer programmatically. If I am incorrect about my reading of the program or its operation, please let me know. -Giff

1 0

Equal rights for receivers
by Anonymous 17 Dec '03

17 Dec '03

Remind me again: Why was it OK when the SENDER could choose to encrypt to an additional key, but it's a threat to the free world if the RECEIVER is allowed to request the same thing?

2 2

"21 Days To Freedom"
by delta7＠onlinebiz.net 17 Dec '03

17 Dec '03

How do you feel about taxes? Every dollar you save in taxes is... MONEY IN YOUR POCKET. Do you want to learn how to legally save a FORTUNE in taxes...starting TODAY? We will show you how to BUILD WEALTH QUICKLY. And protect your assets. You will never worry about creditors, ex-spouses, or government intervention again. CREATE FREEDOM for yourself. NOW. This information is available to taxpayers in the United States, and also foreign countries. For an exciting FREE REPORT, please send any e-mail message to Strikegold(a)answerme.com. You will receive your FREE REPORT immediately.

1 0

Technical Description of PGP 5.5
by Bill Stewart 17 Dec '03

17 Dec '03

Jon Callas presented a technical description of PGP5.5 at this month's Bay Area Cypherpunks meeting, as well as flak catching on the politics discussion; Phil Zimmermann and other PGP folks also helped. This posting is an attempt to summarize the technical parts and leave the politics for other messages. Perhaps there's been some technical discussion on OpenPGP, but feel free to forward this there if not. 1) PGP 5.5 API Toolkit - It's the core of the PGP5.5 GUI and SMTP tools. It'll be out Real Soon Now. It's a major change from the PGP 5.0 Toolkit, which is based on ViaCrypt's older code. The toolkit knows about all the features in the message formats, so even if the application programs from PGP don't provide a given friendly or hostile feature, you can still write it yourself, and so can the Bad Guys. 2) PGP 5.* message format - unchanged - uses the multiple recipients, without any indication of or dependence on relationships between the recipients. The format is approximately Recipient Record 1 - KeyID1, E(sessionkey, PubKey1) .... Recipient Record N - KeyIDN, E(sessionkey, PubKeyN) Message - E(Message, sessionkey) KeyID is the 32-bit KeyID, rather than a fingerprint. I don't know if the format or the PGP 5.x software can generate or accept messages with recipient records for two different keys with the same keyid (or whether it matters if the keys are for DH*, RSA, or both.) * DH can be spelled "E L G A M A L" -- Blame Cylink :-) While 5.0 did introduce new data formats, they're not stealthy, and features like the SMTP filters depend on being able to know how many recipient-key records a message contains, where their boundaries are, and what their KeyIDs are. 3) PGP 5.* public key format - The 5.5 features are actually present in the 5.0 key record formats, but there wasn't any implementation that used the extra fields. The record for keys is about like this, though I may have some of the details wrong. The record for the RSA Keys uses the old format; this format is for newer keys. Key Record type KeyID UserName Algorithm ID - the interesting combo is ElGamal and DSA Encryption Key OptionalCMRK_1: (Mandatory/Optional flag1, Msg Recovery KeyID1) ..... OptionalCMRK_N: (Mandatory/Optional flagN, Msg Recovery KeyIDN) (Note: the format allows multiple records, PGP5.5 only generates one, though it might accept and use multiple. Nobody indicated whether more than one CMRK indicates that the sender should encrypt to all CMRKs, pick one, or do something interesting like secret-share.) (Note: the KeyID is a 32-bit KeyID, not the full fingerprint, which has amusing deadbeef attacks. (Unless I remembered wrong.)) Signature Key Self-Signature on (Encryption Key, Signature Key, UserName) (I don't know if the self-signature includes the CMRKs, but I think it includes the user names.) Optional_Signature_1: (Signature KeyID1, Signature1) ..... Optional_Signature_N: (Signature KeyIDN, SignatureN) (I don't remember if it's just the KeyID or the full fingerprint.) (Note: Signatures are only on the signature key, so you can change the encryption key and keep your collection of web of trust signatures; this is secure because the encryption key is signed with YOUR sig key, and your sig key is signed by your friends' sig keys.) The signature structure is interesting, since it lets you implement forward secrecy somewhat conveniently - just change your encryption key. I don't know if the 5.0 / 5.5 implementations can easily handle multiple records for the same KeyID, so there may be some transition issues, but that's an implementation question, not a data format question. The CMRK** is obviously the new and controversial feature. The key is attached to the recipient's key, not the sender's program, which has some implications in who has to participate in any message escrow activities and where they take place. To some extent this is planned, and to some extent it's just the consequences of what parts of the system you have control over and what you don't. This approach has the recipient publish a CMRK KeyID, and has the sender decide whether to use it, rather than having the sender's system specify who gets the CMR copy. - Since this is the data format, it doesn't have any control over what the sender really does; any enforcement is in the sender's or recipient's client or in the SMTP mail filters. - The format just contains the CMR KeyID, not the key itself; looking up the key is a separate job. (** Corporate Message Recovery Key? Cover My Rear Key?) NOT TALKED ABOUT, but possibly relevant: www.pgp.com says: "Using PGPs Administrative Wizard, for example, administrators can set key generation configurations; require encryption for all email messages sent by a set of users; enable corporate message recovery; and limit the ability of users to perform certain actions, such as key generation." I assume the parts about key generation are limitations on the client, either generating PGP Crippleware? It can't be that heavy a restriction, since users could use PGP5.0, or 2.6.2 if the rest of the company can accept RSA keys, but it's sounds disturbing and it would be nice to see documentation. Could it be limits in the keyserver instead? Also not talked about - CERTIFICATE SERVER, and CERTIFICATE SERVER REPLICATION ENGINE which has lots of cool LDAP directory lookup stuff. The web page didn't say anything about policy administration on the server, but it's another obvious hook, assuming people in a company use it (e.g. a key server could only store keys with CMRKey set to Mandatory, though I don't know if the initial PGP CS version does that sort of thing.) 4) PGP 5.5 Implementation and GUI - - When you generate a 5.5 DH key, you have the option of specifying a CMRK and setting the Mandatory/Optional flag. I don't remember if there's an option to force you to use the CMRK, or to set a default CMRK or default value for the Mandatory flag, but the PGP folks kept saying things about always asking you things and always letting you know when it's going to do things. - The PGP 5.5 implementation puts at most one CMRK in the record, though it doesn't choke on receiving multiples. - If you receive a key record containing CMRKs, PGP 5.5 stores them; I don't remember if it alerts the user at that point or only when the user uses the key later on. - If you encrypt a message using 5.0, it ignores the CMRK. - When you are encrypting a message, the GUI lets you pick what keys to encrypt to. If one of the keys has a CMRK, if the Mandatory flag is not set, it asks if you want to set the CMRK as a recipient. If the Mandatory flag is set, it puts the CMRK as a recipient. Either way, you can delete the recipient, and it doesn't enforce it, and it also makes the CMR keys show up in red etc. It will nag you if you delete a mandatory, but won't stop you. (I think I got those details right.....) Also, if there's a CMRK KeyID, and your keyring doesn't contain the key for that KeyID, it asks if you want to fetch it from the keyserver. - As far as I remember, if you have a CMRK Mandatory set on one of your keys, and you receive a message addressed to your key, it doesn't check if the message was also addressed to your CMRK. A Bad Guy could build an implementation that did this, but the messages are interoperable with PGP 5.0 and don't contain any indication that any recipients use or are CMRKs, so it's easy to work around if they do. And a Bad Guy could also build in Passphrase Leakage or other evil things anyway. Again, the CMRK belongs to the recipient, not the sender, and deciding to encrypt to it belongs to the recipient. The ViaCrypt BusinessGAK version had a feature that let you compile in a Message Recovery Key that the sender was forced to use (which was a clone of the Always-Encrypt-To-Self code.) This is #defined out in both 5.0 and 5.5; the PGP folks tried to see what happened if they #defined it in when compiling, and it nicely dumped core when they used it. 5) SMTP filters - PGP Policy Management Agent for SMTP is really separate programs for Incoming and Outgoing mail. None of the PGP 5.5 features do more than nag you about using them; they don't have an enforcement mechanism. The SMTP filters, on the other hand, are designed for enforcement, and some of the interesting security and control issues come from the interaction between the filters and the PGP5.5. The PGP folks said that their particular implementation was a quick and basic job using the toolkit - so even though it's not particularly draconian or intrusive, it's easy for people to write their own that are more hostile. Neither filter, for instance, saves copies or forwards copies of mail to an archive or corporate enforcers or runs scripts - all they do is pass or bounce the mail (with configurable message). But you could write one that did, if you were that type of company. Source is not provided ("Look, we have to have _something_ to sell"), but some of the toolkit example code will be fairly similar. The filters don't look inside encrypted packets (so they don't have to manage private keys or other dangerous things). This does mean that they can check for encryption or signatures, but can't check if there's a signature inside an encrypted message. 6) Incoming SMTP filter - Really simple Remember - CMRKs are attached to the recipient, not the sender; this is the only place you can enforce that for your employees. Incoming mail is checked to see if it's acceptable, and either passed to a "real" SMTP server or bounced with a message (typically includes a policy statement or URL and/or a pointer to a key server handling the CMRKs.) Note that all the filtering is based on KeyIDs - not email senders or email recipients or transport info. Messages can be rejected if they're unencrypted, or rejected if the encryption recipients don't include one of a set of keys. Unless I'm remembering wrong if the list of keys was not dependent on the recipients, so you can't do things like "If Recipient=PurchasingClerk Require PurchasingBoss", though you can require "One Recipient in set PurchasingBoss, SalesBoss, EngrBoss", etc. Unfortunately, this pushes the company toward using one CMRkey, since it's not very flexible, though it can easily handle multiples. There may have been an option to accept signed mail, or that may have only been in the Outgoing SMTP server. There wasn't an option to reject unencrypted mail. (You could probably fake this by accepting unencrypted messages while also requiring encrypted messages to include a recipient whose key is not published anywhere and not publishing that keyid so nobody runs a deadbeef attack on it. I haven't verified this...) There wasn't an option to email a copy to the archive; you could write your own, but presumably any site that wants to save copies of all encrypted messages is already saving copies of all unencrypted messages already. Or they're really only making sure there's a CMRKed copy of the session key so they can decrypt the message on the late recipient's disk after he gets hit by a bus or a subpoena. 7) Outgoing SMTP filter - more complex. IF Sender_IPaddr in LIST, Evaluate RULE (parameter KeyIDList) -> -> Accept (fwd to SMTP server) OR Reject with parameterized bouncemessage. You only get one list of IP addresses, and you can only accept/reject, but the rulesets are flexible, and you can chain multiple filters together (the filter can run on Port 25 but can also run on other ports, and can forward to an SMTP server on other ports, so you can stack a bunch of these on a single box and chain them together.) Note that this doesn't look at the sender's or recipients' email addresses, just the sender's IP address. This is sometimes limiting (consider mail servers with multiple users, or multi-user machines, or people who do multiple functions from one machine), but it's more secure than trusting easily forged information like the sender and sender's address. A fancier system would include these in filtering capability. That capability may have been left out on purpose, or it may just be limited development time. (I don't remember if you can use multiple rulesets, but you can stack.) I also don't remember all the possible rules, but this is close: - Require Encryption (yeah!) - Require Encryption to Key on KeyIDList -- remember that CMRKs are attached to recipients' keys, not to senders' keys or mail packages, so the senders have to include any required keys themselves unless the recipients' CMRK keys are administered jointly with the SMTP server. (Sending them enough bounce messages may give them a hint, but the sender's PGP5.5 system won't do it automatically.) Thus, it's easy for CompanyA BuildingA to make sure that messages to CompanyA BuildingB employees are encrypted to one of CompanyA's CMRKs, but it doesn't have a clue about CompanyB's CMRKs or RandomRecipient's CMRKs, though if the recipients put their keys and CMRKs on some public keyserver a more sophisticated (and slower) SMTP gateway could check. - Require Signature (Remember that it can't look inside encrypted messages, so it only does this for unencrypted signed messages.) - Require Signature from KeyIDList - since this ruleset is used along with IP address lists, you could require things like "All email from Purchasing's machines are signed by Purchasing" "All email from the PR department is signed by the Marketroid Key" "All email from PR users is also signed by someone technical" :-) "All email from technical people is signed by Corporate Security" :-( "All email from the company president's key is signed by PR and Legal" (Note that this doesn't let you say "All email purporting to be from the company president" since it doesn't read email headers.) "All mail from the company president's real key is signed by the company president or her secretary" - Block encrypted mail, block signed mail (I think both of these were there, and if they weren't, you could implement them by some combination of features.) - Clear Text - you can allow this or block it. Storage Keys vs. Signature Keys vs. Message Encryption Keys - As described above, PGP5.* does use separate keys & algorithms for signatures and encryption, except for the old RSA keys. Storage Keys are a different issue - the main distinctions between storage keys and message encryption keys are - storage keys are used by the owner, while message encryption keys are used by someone other than the owner for items that will be given to the owner. - storage keys are useful when you have the storage media, message encryption keys are useful when you have a copy of the message, either legitimate or eavesdropped. - message encryption cyphertext gets mailed; stored cyphertext just sits there :-) PGPdisk is a pure storage key system, and perhaps there would have been less political furor if PGP had done Corporate Storage Recovery Keys, but it's not a mainstream product for PGP Inc., and only runs on Macs. Doing the storage job right means integrating with backup servers (disk drives get crashed or scribbled far more often than employees get hit by trucks...) which isn't PGPInc's specialty. In reality, users often use PGP for storage, including for messages they've received (depending on their mail GUI) and for files on disks (encrypted to themselves.) File-by-file encryption is easier to back up securely than whole-disk encryption, which requires either dumping the whole disk to backup media or copying to the backup in the clear. The latter is especially useful if the backup server is also an encrypted storage system, but the copying may be a security risk, unless you do really fancy things, and there's the whole question of whether the backup storage is encrypted with the same keys as the primary (hit-by-truck risk) or with a different key (corporate message access equivalence risk.) Business environment and documentation - [Mostly non-technical] PGP is a real business. They've got deadlines, they've got accountants, they've got people beating them up to ship code by the end of the quarter so they can bill people, they've got customers telling them they won't buy stuff until they get Feature X added or removed, all the usual stuff. The design consultants who used to do their export controlled web site left them a maze of twisty little CGI scripts, all different, so getting actual technical documentation out has taken far more work than anybody had time to do before a release date. (Some documentation is claimed to exist :-) Their SMTP packages could have had far more features, but they felt this at least minimally met their requirements, and there was some thought toward extensibility. While 5.0 did introduce new data formats, they're not stealthy, because they haven't seen much (any?) paying-customer demand, and features like the SMTP filters depend on being able to know how many recipient-key records a message contains, where their boundaries are, and what their KeyIDs are. So they recommend that people who want stealth go work OpenPGP and build formats that work to pressure PGP Inc. into using it. One of Phil's goals had been to design a system that provided the business message recovery features their customers were asking for without providing access to users' private or signature keys, as a counter-argument to the GAK advocates who claim they need it. [ As might be expected, much heated discussion occurred on this issue. :-) ] Some things that time pressure makes it difficult to think about, or at least implement, beside stealth, are features like secret-sharing the session keys to CMRKs (it's not possible to do this cleanly, without affecting a bunch of other things), or making session key recovery a difficult and slow process so it doesn't get done often (e.g. zeroing the bottom N ~ 32-40 bits of session key so recovery requires some brute force as well as the keys.) Building in the ability to crack messages using a single master key is really bad (though at least it can be a different master key per user or per message); perhaps when 5.6 or 6.0 handles multiple CMRKs it will implement them by secret-sharing rather than making them each full recipients. - Customers - Some of the customers do want to "recover" all their users' traffic. Others wanted to make sure that mail to a customer service rep got encrypted to the other customer service reps also, or at least to the rep's boss, so someone could handle the business if the original recipient was away. One of the more obnoxious customers was implementing CAK by having the Corporate Security department generate keys and hand them to the users on floppies; this gives them a less obnoxious approach that they're willing to try. One of the customers was really paranoid about making sure their employees didn't leave their CAD drawings encrypted and then steal them or extort money from the company for decrypting the plaintext when they quit; apparently the idea of using a document management system like programmers use for source code control had never occurred to them.... Thanks! Bill Bill Stewart, stewarts(a)ix.netcom.com Regular Key PGP Fingerprint D454 E202 CBC8 40BF 3C85 B884 0ABE 4639

5 7

Trans World Specials e-mail confirmation
by twaweb＠inet2.twa.com 17 Dec '03

17 Dec '03

Thank you registering with the TWA Trans World Specials Electronic Faresale notification program. TWA posts faresales for the week on Tuesday mornings at http://www.twa.com/html/flights/faresale.html. If the routes you have selected in Trans World Specials match the faresale cities - then you will receive the faresale by e-mail. You can always update your profile and add or remove routes by returning to: http://www.twa.com/odpairs Thank you!

1 0

Personal use crypto export
by Jim Gillogly 17 Dec '03

17 Dec '03

I'm moved to repeat Matt Blaze's exercise of a couple of years ago, where he went through the rigamarole to get an Official Paper from Customs or State or whoever was in charge to take his laptop out of the country with crypto on it for his personal use overseas. His experiences finding the right person to talk to to get a form, then his inability to find a Customs official to look at it on the way back, were semi-hilarious. However, now that crypto exports in general have moved from ITAR to EAR and BXA is in charge of general crypto exports, I can't find out how to get the right form to take out a laptop with PGP (or anything else) on it. Can anybody give me a pointer to whoever thinks they're in charge of this stuff? Or have they given up on this phase? Thanks... -- Jim Gillogly 24 Winterfilth S.R. 1997, 18:38 12.19.4.10.12, 7 Eb 10 Yax, Fifth Lord of Night

6 5

Security flaws introduced by "other readers" in CMR
by Tim May 17 Dec '03

17 Dec '03

At 11:10 AM -0700 10/15/97, Eli Brandt wrote: >Non-technical point: the NSA (reportedly) has no intention of using >GAK for classified information. They know that it weakens security. > >Do the privacy of the nation's data and the security of its >information infrastructure deserve the same consideration as the >Pentagon's "Confidential" memos? When you're planning to build in a >single point of failure, this is a question you have to ask. This also applies to CMR as well. Whatever the perceived business reasons for CMR, the fact is that it introduces additional failure points. No longer will Alice and Bob be secure that at least there are no "other readers" in the channel between them (what they do with the plaintext after decryption is of course solvable by no technology). And, contrary to some of what we've been hearing, even corporations have continuing needs to know that a communication between Alice and Bob, within a corporation or crossing the corporate boundary, is not being listened to by any other person. Merger negotiations are one obvious example. (There are workarounds, I suppose. CMR could have a "override" switch to turn off the CMR to a second key. But who decides on this? Maybe a signed message from a suitable higher-up? Ah, the complexity. And executives wanting to bypass CMR can and will use other channels. So many of the goals of CMR are out of reach....) Instead of choosing an example where CMR apparently "works," such as Crispin's example of a corporation using CMR to detect (as if it weren't detectable in other ways!) that an employee is operating a porn ftp site from company computers, let me throw out some examples where CMR introduces flaws into a security system. * Andy Grove sends a PGP 5.5-encrypted message to T.J. Rodgers, CEO of Cypress Semiconductor, outlining the plans for Cypress to be acquired by Intel. However, Cypress has implemented CMR, and one of the "second readers" of Andy's message is the cryptically-named (no pun intended) "CCCP" (Corporate Crypto Compliance Police), staffed by security guards and personnel management droids. Major security flaw. (Sure, one can imagine various levels of "second readers." But I rather doubt that most of them will be _offices_, with changing staffs. While one could, for example, designate "Gordon Moore" to be the second reader of all files encrypted to Andy Grove's key, I rather doubt this is the way CMR will play out.) * Craig Livingstone, at whitehouse.gov, is the Key Compliance Officer for all communications entering or leaving the White House. Enough said? * Sheep-dipped cutouts in defense companies await their orders from DoD, but find that other readers in their companies are monitoring them. And so on. "Three can keep a secret if two of them are dead." (Ben Franklin) What will of course happen is that these "security flaws" will be plugged by subterfuge. People will stop using the corporate mail for many such tasks, and will use nonwork accounts. With some loss of efficiency, and even more opportunities for leaks. (If firewalls are in place, on outside net connections, employees can just dial out. Or use Metricom Ricochet modems, if conditions are favorable for reception. Or wait until they go home.) In fact, CMR will mostly just mean bland, interdepartmental messages get "recovered." As I said before, this is a pretty crude way to implement a kind of corporate archiving of information. Truly sensitive stuff--stuff about takeovers, foreign production plans, new products, etc.--will be encrypted with channels having no nosy security guards or Corporate Crypto Compliance Police silently listening in. Which means we're back to square one. So why does PGP, Inc. bother? And why should OpenPGP squander efforts worrying about this? --Tim May The Feds have shown their hand: they want a ban on domestic cryptography ---------:---------:---------:---------:---------:---------:---------:---- Timothy C. May | Crypto Anarchy: encryption, digital money, ComSec 3DES: 408-728-0152 | anonymous networks, digital pseudonyms, zero W.A.S.T.E.: Corralitos, CA | knowledge, reputations, information markets, Higher Power: 2^2,976,221 | black markets, collapse of governments. "National borders aren't even speed bumps on the information superhighway."

3 5

Rules of Engagement on Video
by Jim Burnes 17 Dec '03

17 Dec '03

I know this isn't directly cypher related, but oh well. An award winning film, "Waco: the rules of engagement" is now available on video. Previously running at Art Houses and Film Festivals it was produced by a few revolutionary media people. Somehow it occurred to them that all the right-wingers had beaten them to the punch making civil rights abuses known to the public. Can't have any of that now, can we? Why should *they* have all the fun? Anyway its been lauded as a very well balanced work. Not like those other people -- talking about evil, new world order conspiracies. ;-) Probably most noteworthy is the included FLIR FBI footage (Forward Looking InfraRed) which, under expert scrutiny, appears to show LEFs raining automatic fire down on citizen units trying to escape the final conflagration. Here expert scrutiny is defined as the head of research for the army night vision development group. Its definitely the cure for those times when GAK starts looking like reasonable, sensible and prudent alternative. I have absolutely no involvement or monetary connection to these people. I just wish they would have put it on video first. "Is your religion BATF approved?" ---------- Forwarded message ---------- Date: Wed, 15 Oct 1997 12:34:04 -0700 (PDT) From: SomFord Entertainment <somford(a)worldnet.att.net> To: somford(a)worldnet.att.net Subject: "Waco: The Rules of Engagement" Video Order Form Thanks for your interest in obtaining the video of "Waco: The Rules of Engagement". We are pleased to announce that it is finally available! Please check the website periodically for ongoing reviews, press, announcements and updates to the order form. http://www.waco93.com/ "Waco: The Rules of Engagement" Video Order Form Print, Complete, And Mail This Form With Check Or Money Order To: SomFord Entertainment, 8778 Sunset Bl., Los Angeles, CA 90069 Questions: 310-289-3900 1. E-Mail Address:............................................... 2. First Name:................................................... 3. Last Name:.................................................... 4. Street Address:............................................... 5. Apt. No., Other Info:......................................... 6. City:......................................................... 7. State/Province:............................................... 8. Country:...................................................... 9. Postal Code:.................................................. 10. Phone:....................................................... 11. "Waco: The Rules of Engagement" Video.........Quantity:...... $25.00 for 1 tape. $22.50 each for 5 tapes. $20.00 each for 10 tapes. Bookstores and Catalogues, Call for Bulk Order Info. All Prices Include Domestic Shipping and Handling. CA Residents Please Add 8.25% Sales Tax. 12. Total:....................................................... Make Check or Money Order Payable to: SomFord Entertainment. Comments Or Special Delivery Instructions:....................... Please allow three weeks for delivery. Thank you for your order

3 2

Re: CFV: comp.org.cauce moderated -- support privacy and anonymity
by Igor Chudov ＠ home 17 Dec '03

17 Dec '03

[This message has also been posted.] [I am objecting to a proposal that seeks to ban one-way anonymous remailers and other forms of unrepliable addresses such as spamblocked addresses]. In news.groups, WD Baseley <wbaseley(a)mindspring.com> wrote: * [my apologies to the net at large for replying sans *snecks* - I don't * know which group is read by the person to whom I'm replying.] * In article <3447bfd7.22958863(a)128.2.84.191>, phelix(a)vallnet.com * >On 14 Oct 1997 11:57:07 -0400, moz(a)server2.mich.com (John C. Mozena) wrote: * >>Igor Chudov @ home <ichudov(a)algebra.com> wrote: * >>>Vote AGAINST comp.org.cauce which wants to outlaw anonymity and * >>>use of spamblocked addresses. Go to news.groups and find the * >>>CFV for comp.org.cauce, with the ballot enclosed. * >> * >>Vote for comp.org.cauce, which protects the utility of a newsgroup and the * >>freedom of postmasters to not run anonymous posting services should they * >>not so desire. * > * >Well, I just started reading this, and I didn't really know which way to * >vote. But such an anti-anonymnity stance makes the choice clear: * > * >vote *NO*. * * Since you just started reading this, I think you need more background * before coming to a decision. I'm not trying to influence it one way * or another; I'm just trying to give you more complete information. * I'm posting and emailing, and I'm sure that if I get it wrong I'll be * jumped upon thoroughly in the newsgroups - feel free to look there and * see if that happened. By all means, as one of the opponents of the proposal and supporter of anonymity, I ask you to do so and also get your privacy-concerned friends to take a close look at the debate. For example, here's what the proponent said: Mozena>>But, what do you have against anonymity? Mozena> Mozena>Nothing. What right do you have, though, to force me and others to Mozena>inconvenience ourselves so you can post anonymously or protect yourself Mozena>from spam? * The RFD requires posters to use addresses which receive, and reply to, * email; in other words, no munged, faked, spamblocked, or other * bouncing or redirecting addresses. There is nothing that says you * must use your real name, or any other identifier, that tells who you * really are. If "the-return-of-zorro(a)example.com" receives and replies * to email, it can be used to post to the proposed group. "Anonymity", * the ability to post without anyone knowing your true identity, is not * really the issue. Even anonymous remailers will work if they forward * email in both directions. But mungs and spamblocks will not work. These are not anonymous remailers, they offer a much lower security, they are not very reliable by their very design, and the only *true* anonymity can come from a one-way remailer. The proposal, as it stands, seeks to outlaw the one-way anonymous remailers. * John Mozena's comment on anonymous posting services stems, I'm pretty * sure, from an alternative offered by several folks. The idea was: * posters would add an 'X-Real-Address' line to their posts; the * moderation bot would use that line for correspondence, but remove it * before making the post public. John Mozena and others at CAUCE were * unwilling to do this because of possible legal ramifications; John * likened it to running an anonymous posting service, and wondered what * the consequences would be should someone use it to post copyrighted or * sensitive information. Well, this is NOT true. John objected to it with the argument that he does not like unrepliable addresses appearing in newsgroups. Anyway, all this talk about the X-Real_Address: field is NOT related to true anonymity, by the very definition of the latter. -- - Igor. The average American spends a total of six (6) months in prison.

1 0