December 2003 - cypherpunks-legacy

InfoWar Epilogue 2 (Part III of 'The True Story of the InterNet')
by TruthMonger 17 Dec '03

17 Dec '03

1 0

Key Lookup Optimizations (Was: Re: D-H Forward Secrecy for E-Mail?)
by William H. Geiger III 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- In <199710131652.RAA02526(a)server.test.net>, on 10/13/97 at 05, Adam Back <aba(a)dcs.ex.ac.uk> said: >> >I also personally prefer people to send me keys in email, because the pay >> >per second phone lines here at home mean that I tend want to avoid doing >> >too many online key lookups, so I think this would be an individually >> >useful feature. >> >> I do my keylookups automatically durning the msg filtering process which >> is done in parallel to the message Dl's. >A clever optimisation to be sure. >> The outbound message lookups are a little more time consuming but is >> compensated by fewer keys to look for both because fewer messages on >> the outbound side and the use of key caches on the client machine >> for the most used keys for sig verification and encryption. >I don't have a key cache, and my keyring is only 216k. But I'm curious >about your automated process .. are you also checking all signatures that >you can by downloading the keys and checking out the WoT for all received >mailing list traffic etc? This would cleary result in a much bigger key >ring. For the inbound processing of mail I have the following automated processes: - -- Messages is downloaded and checked to see if it is a PGP Message (This is handled by the mailers filters). - -- If the message is signed the keyid of signature is extracted from the sig-block and a lookup is performed on the index table for both the users pubring & sig_cache. - -- If the key is not found in either then the message is placed in a queue and a keylookup thread is spawned. - -- There is a setup for which servers and how many to try when doing the lookups. - -- If no key is found on the servers then a canned e-mail message is sent to the sender requesting his keys. The message is taken out of the queue, marked that no key was found and that a request had been sent out. - -- If a key is found it is added to the key cache (sig_cache.pgp). Then normal sig verification is performed. - -- After X amount of hits on a key in the cache the key is flagged as a commonly used key for the user so he can pursue authenticating the key (no sense in going through a lengthy authentication procedure for a key that is only used once). - -- Attached keys are detached from messages and stored in new.pgp keyring (auto adding of keys to ones keyring is a Badthing (TM) ). - -- Encrypted messages are decrypted. All PGP output is appended to the bottom of the message so the info is there when the user opens the message. If a message is in MIME format then the below is appended as MIME attachments using text/X-PGPCheck MIME type. A sample is provided below: - -------------------------------------------------------------------- MR/2 PGP Signature Check 13 Oct 1997 12:19:55 - -------------------------------------------------------------------- File has signature. Public key is required to check signature. Key matching expected Key ID 142DD151 not found in file 'd:\pgp\pgp263a\pubring.pgp'. WARNING: Can't find the right public key-- can't check signature integrity. Plaintext filename: WHGIII\34425839 - -------------------------------------------------------------------- MR/2 PGP Signature Check [Secondary Keyring] 13 Oct 1997 12:19:55 - -------------------------------------------------------------------- File has signature. Public key is required to check signature. . WARNING: Bad signature, doesn't match file contents! Bad signature from user "Ian Brown <Ian.Brown(a)ncl.ac.uk>". Signature made 1997/10/13 15:15 GMT using 1024-bit key, key ID 142DD151 WARNING: Because this public key is not certified with a trusted signature, it is not known with high confidence that this public key actually belongs to: "Ian Brown <Ian.Brown(a)ncl.ac.uk>". Plaintext filename: WHGIII\34425839 PGPRC=1 PGPRC2=1 >> Also logging of e-mail addresses that do not use PGP cuts down on >> the number of lookups needed >Good optimisation. It sounds really as if your OS/2 setup is more >advanced than a lot of other stuff around. - -- For the outbound messages the following procedures are in place: - -- All messages are signed with the user having an option of disabling this signature either on a per message basis (through the use of a message template at creation time) or default conditions can be set in the filter no to call the signing script (things like don't sign messages to majordomo, or messages going to remailers, ...ect) - -- Outbound messages can be flagged for encryption on a per message basis (through the use of a message template at creation time) or default conditions can be set in a special default.ndx file used by the encryption script. - -- The encryption script first extracts all the e-mail addresses from the To:, Cc:, & Bcc: lines. - -- It then does a lookup on the default.ndx table. This is where several issues are resolved. 1) No key for address. An address can be flagged as a no-encrypt address. This is mostly for mailing lists and receivers that do not use PGP. 2) Default key for address. An address can be flagged as encrypt and the keyid for that address is included in the entry for that address. This handles things like userid does not match the e-mail address for the person you are sending to (change of address, ect...). Also the issue of multiple keys having the same e-mail address are handled (their can be 5 keys all with the address john_doe(a)domain.com in the userid fields but only one is the real john_doe(a)domain.com that you are talking to). 3) Always encrypt flag. You can flag an address to alway encrypt too regardless of wether the message was flagged for encryption at creation time. (hmmmm starting to get into the realm of policy enforcement here <g>). - -- Unless an address is flagged as no-encrypt then a lookup on the keyring indexes for both the pubring and crypt_cache are performed. - -- If and address is not found then a keyring lookup is performed. A separate cache is kept for the encrypted keys and a similar process of flagging frequently used keys is in place as with the sig_cache. - -- now that all the addresses are processed 3 copies of the message are created: 1) Encrypted message. This message is sent to all the addresses where valid keys have been found. 2) Plain Text message. This message is sent to all addresses where they have been flagged no-encrypt in the default.ndx. 3) Error message. This message is returned to the message editor and the user is informed why the message could not be encrypted and then it is up to him to resolve the problem. Most common errors are no key found for the address and multiple keys with the same address found. Both these conditioned can be resolved by making the proper entries in the default.ndx file. 3A) There is a setting flag that tells the script not to split the message as above and error the complete message unless all addresses can be encrypted to. 3B) their is an exception option on 3A where a split message is not in error if the only addresses with no_keys are flagged as public distribution (mailing list, newsgroups, ...ect). 4) BCC messages. Bcc's create a unique problem to the encrypt to multiple recipients function. Because of the format of the encryption block the list of keys used to encrypt is known to all who care to look. This goes against the purpose of a BCC which is to hide a recipient from the rest. In this case I create a separate message for each BCC and encrypt that message with only the key for the BCC recipient. 5) All split messages contain a X-Distribution list containing all the e-mail addresses that the messages was sent to (minus the BCC's of course). I have allot more goodies implemented and/or working on but that should be enough for one message (direct keyring manipulation, remailer support, stamper support, PGP/MIME, balanced b-tree as keyring, ...ect). Much of the optimization work I have been doing is for server side processing useing very large keyrings (+20Mb) but that is another thread in itself. Plus I have a PGP GUI which has many other features for key management & WOT not practical for the automated processing code. >My setup is GNU emacs with Pat LoPresti's mailcrypt.el PGP and remailer >support lisp extension for emacs RMAIL and emacs GNUS (newsreader). I >love it to bits. It is totally excellent. It doesn't have a couple of >your optimisations, but other than that it's pretty good. When you send >messages, if you don't have the key it will fetch it for you by trying >keyservers, then finger user@domain. It can snarf keys out of mail >messages, paste keys into them, sign, encrypt, check signatures, use >remailers (type I and mixmaster). Sounds good except the retrieval of keys from the finger. This is a serious weakpoint in your security. Say you have Adam who wishes to communicate with Mary. He get's Mary's key from her .plan file via finger. Eve has control of the server and replaces Mary's key with her own. Now you encrypt message to Mary but you are using Eve's key. Eve decrypts the message re-encrypts with Mary's and neither of you are the wiser. This is also a weakness in the distributed key approach as it presents a single source of failure unless some type of redundancy is built in. I know that there are many issues involved in this and probably should be spun off into a separate thread if you are interested in pursuing it (too many disjointed subjects in one thread tends to become confusing). - -- - --------------------------------------------------------------- William H. Geiger III http://www.amaranth.com/~whgiii Geiger Consulting Cooking With Warp 4.0 Author of E-Secure - PGP Front End for MR/2 Ice PGP & MR/2 the only way for secure e-mail. OS/2 PGP 2.6.3a at: http://www.amaranth.com/~whgiii/pgpmr2.html - --------------------------------------------------------------- -----BEGIN PGP SIGNATURE----- Version: 2.6.3a Charset: cp850 Comment: Registered_User_E-Secure_v1.1b1_ES000000 iQCVAwUBNEKmhI9Co1n+aLhhAQGgfQP/ZnRMzHAFSgfREts8Op5P+JHfRJHG5khl pUexNZh+VmGpuEkKVMCcIVvYJrICWop7XSYtnI6W0mKd3E2TppVgOplpOvnsHVCv cp1hS8a9MfkBns+Jf7xGG4Z2V3crqGP5ZpcF/PR8Yj8o9wHwx5YoqSLYnF5VTzVM OevaTH+8vJE= =VZeI -----END PGP SIGNATURE-----

1 0

No Subject
by bureau42 Anonymous Remailer 17 Dec '03

17 Dec '03

Jim Choate <ravage(a)ssz.com> wrote: > Thought some of you might care to know that James A. Michner the Pulitzer > prize winning author who lives here in Austin, Tx. has decided to take > himself off the kidney dialysis machine that has been keeping him alive. The same organizations who seek to banish the Suicide Doctor Kevorkian are probably up in arms over this announcement. "This should be illegal!" "Keep him alive!" Suicide is illegal in most "democracies" for one reason - so that the State can confiscate the material goods of the deceased.

3 2

Hmm
by nobody＠REPLAY.COM 17 Dec '03

17 Dec '03

Mr-Anonymous-type-person wrote: > www.telcomtraining.com/downloads what's the l/p Mr. Anonymous?

1 0

None
by Anonymous 17 Dec '03

17 Dec '03

On terrorists, one of the Four Horsemen. IS THE ASSAULT ON NATIVE INTELLIGENCE & GOOD WILL WE CALL THE EVENING NEWS ANYTHING OTHER THAN AN ACT OF TERRIORISM? What was the Gulf War but terrorism wearing the death mask of order?-- One big car bomb it was the guys who drove it are dying now one by one--ignored! Is acid rain a form of terriorism? (Think for yourself.) Is GATT or NAFTA anything but a pact among brigands--the World Bank, the IMP their backup men? How long before they fight over the spoils? Who'll do the fighting for them?"

1 0

Canadian crypto export/re-export rules
by Steve Schear 17 Dec '03

17 Dec '03

Can anyone point me to a site with accurate and complete information? --Steve

1 0

Statists trying to outlaw anonymity and privacy
by ichudov＠Algebra.COM 17 Dec '03

17 Dec '03

Dear Friends, As many of you no doubt know, a new moderated group, comp.org.cauce, has been proposed. One of the main goals of moderators is to prevent users of one-way anonymous remailers and those who munge (alter) their addresses to avoid being spammed, from posting to the group. Their proposal would force users to reveal their Internet identities and expose them to spam. The proponents hope, apparently, that the more spam people get, the more will they support CAUCE's statist lobbying for more government regulations. During the discussion they have shown complete disregard and ignored all requests from users who attempted to help them accommodate anonymous posting. To get more YES votes, they removed the most controversial provisions from the charter, while IN THE SAME DAY promising that these provisions will still be enforced. As someone who defends privacy and anonymity on the Internet, I ask you to vote on this important matter. I will vote NO on this newsgroup. Feel free to repost this message to any fora you deem appropriate. To find the Call For Votes, go to news.groups newsgroup, and find article titled "CFV: comp.org.cauce moderated". You will find the charter and the instructions on how to vote. Thank you for your attention. - Igor.

3 2

RSADSI open RC2 encryption algorithm
by Nobuki Nakatuji 17 Dec '03

17 Dec '03

RSADSI open RC2 encryption algorithm. http://www.imc.org/draft-rivest-rc2desc ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com

1 0

proposal: commercial data recovery
by Adam Back 17 Dec '03

17 Dec '03

If we take the design goal of designing a commercial data recovery system which is not GAK compliant, we can most succinctly state this design goal as the task of ensuring that: - at no point will any data transferred over communications links be accessible to anyone other than the sender and recipient with out also obtaining data on the recipient and/or senders disks I think we can distill the design principles required to meet the design goal of a non-GAK compliant Corporate Data Recovery (CDR) down to ensuring that: 1. no keys used to secure communications in any part of the system are a-priori escrowed with third parties 2. second crypto recipients on encrypted communications are not used to allow access to third parties who are not messaging recipients manually selected by the sender 3. communications should be encrypted to the minimum number of recipients (typically one), and those keys should have as short a life time as is practically possible Included in 2) is the principle of not re-transmitting over communication channels keys or data re-encrypted to third parties after receipt -- that is just structuring -- and violates design principle 2. With these three principles you still have lots of flexibility because you can escrow storage keys, do secret splitting of storage keys, and store keys encrypted to second storage accessors on the local disk for stored data recovery purposes. As an additional bonus, principle 3 adds extra security against attackers gaining access to encrypted traffic after the fact -- the recipient no longer has the key -- this is a form of forward secrecy. Systems designed to the CDR design principles are of significantly less use to GAKkers than PGP Inc's GAK compliant Commercial Message Recovery (CMR) design. The CDR design significantly hinders the take up of GAK if widely deployed. Design principle 3 -- forward secrecy -- is inherently hostile to GAKkers, and is the strongest statement you can make against GAK: you are purposelly _destroying_ communications keys at the earliest possible moment to ensure that GAKkers can not obtain the keys by legal and extra-legal coercion, black mail, and rubber hose cryptanalysis. The whole system translates into the Feds having to come and physically take your disk to obtain information about you, which is much better than GACK, and not what the GAKkers are interested in at this point. The GAKkers would like to install themselves, and coerce companies into installing for them (via GAKker/USG/NSA/NIST organised efforts such as the 56 bit export permit for companies installing key escrow; and efforts such as the Key Recovery Parners Alliance (KRAP)). I fear that PGP Inc's CMR proposal inadvertently meets most of the NIST/NSA specified KRAP requirements. What the GACKers want is systems where they can perform routine key word scanning and fishing expeditions into your communications from the comfort of their offices, without your knowledge. This is push button Orwellian government snooping. Within the constraints imposed by the CDR design principles, there is plenty enough flexibility to acheive the commercial data recovery functionality to similarly weak levels of enforcability as achieved by the CMR design. Weak levels of enforceability are appropriate because there are other exceedingly easy bypass routes: super-encryption, and walking out of the office with a DAT tape. I would like to organise a collaborative effort to write a white paper discussing how to implement various functionalities using the CDR design principle. Then I would like to see discussion of which set of these functionalities which best acheive the user requirement for company data recovery. Lastly I would like to see a collaborative development effort to provide a example implementation of a CDR system which can be used as a discussion point for the OpenPGP standardisation process. I suppose the best place to discuss this process is the IETF forum for discussion of the OpenPGP standard, the OpenPGP mailing list (subscribe by sending message body "subscribe ietf-open-pgp" to "majordomo(a)imc.org"). I have already had people express in email to me their interest in doing this. Those people can speak up if they want to. Technical input is sought from people opposed to GAK compliant software, and from PGP Inc, and others defending PGP's GAK compliant CMR proposal. Adam -- Now officially an EAR violation... Have *you* exported RSA today? --> http://www.dcs.ex.ac.uk/~aba/rsa/ print pack"C*",split/\D+/,`echo "16iII*o\U@{$/=$z;[(pop,pop,unpack"H*",<> )]}\EsMsKsN0[lN*1lK[d2%Sa2/d0<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<J]dsJxp"|dc`

12 23

One Nation on-line working group
by Global Web Builders 17 Dec '03

17 Dec '03

If you did not request to be put on the One Nation mailing list please respond with "REMOVE" in the Subject line while leaving the message (below) intact. No email is sent without a request having first been received. GWB, Scott Balson, One Nation web site operator. ____________________________________________________________________________ __________ Dear One Nation supporters in NSW, Pauline Hanson's One Nation is now establishing an on-line working group of One Nation members. Conditions of involvement in this working group are: - being a bona-fide paid up member of One Nation. - the desire to be proactive in undertaking tasks and assisting One Nation where you can. This working group will play a very important support role for the party as we approach the next federal election. We do not want to say too much more until working group members have been selected. If you would like to enquire about joining this group please complete the information below: ______________________________________________________ Your Full Names: Your Full Address: Your Contact Phone no: Your Fax no: Your One Nation Membership number: One Nation branch (at which you are a member): _____________________________________________________ Thank you in anticipation of your valued support in this important area. Pauline Hanson

1 0