- cypherpunks-legacy - lists.cpunks.org

SEARCH> Social Security Death Index Search (fwd)
by anonymous-remailer＠shell.portal.com 17 Dec '03

17 Dec '03

---------- Forwarded message ---------- Date: Fri, 5 Jul 1996 12:41:15 -0300 (ADT) From: Todd Smith <tsmith(a)admin.fsu.edu> To: Multiple recipients of list <inet-news(a)nstn.ca> Subject: SEARCH> Social Security Death Index Search Social Security Death Index Search http://www.infobases.com/ssdi/query01.htm To search the Social Security Death Master File (a.k.a. Social Security Death Index or simply SSDI), fill in any or all of the fields below and press "Submit." A list of some Social Security Death Index information is available here. The SSDI search indexes are currently under development. Indexs are currently available for surnames beginning with the following letters: A B C D E . . . I J . . M N O P Q R . . U V . X Y Z Last Name: First Name: SSN: Location Issued: Birth Information Date: Month: Year: Death Information Date: Month: Year: Last Residence / Lump Sum Payment Information: City: County: State: Zip Code: ------------------------------

1 0

Re: Crypto-Activism & PGP
by William Knowles 17 Dec '03

17 Dec '03

Does anyone know how many languages PGP's help files and documentation has been translated into? A good start I would think would be translating PGP into Chinese? and mirroring it on sites around the world. William Knowles erehwon(a)c2.org -- William Knowles <erehwon(a)c2.org> PGP mail welcome & prefered / KeyID 1024/2C34BCF9 PGP Fingerprint 55 0C 78 3C C9 C4 44 DE 5A 3C B4 60 9C 00 FB BD Finger for public key --

1 0

Execution of signed scripts received by e-mail
by Matt Carpenter 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- This is a rough description of a perl script I'm working on to allow the automated execution of PGP signed scripts received by e-mail. I call it emscrypt. Right now it is in the volatile-ware stage. Hopefully I'll have it tested enough to post here shortly, if I feel i can pull myself away from my research for a few hours. But I thought I would post a description now to see if anyone can find any problems with the way I'm going about this or has any suggestions. I apologize for the possibly inscrutable descriptions; it's been a while since I last slept. Let me know if anything needs clarification. First, a basic description of the idea: 1. Write a script (perl, sh, etc.) to be executed on a remote machine. 2. Sign the script with PGP. It can also be encrypted using the public key for the emscrypt installation on the remote machine. 3. Mail the signed/encrypted script (a.k.a. emscrypted mail) to the address where emscrypt is installed. 4. The script is received and piped to emscrypt (using procmail or something similar). 5. Emscrypt checks the PGP signature on the message, and checks for replay attacks based on the time stamp from the signature. 6. Emscrypt executes the script, gets the results, encrypts them, and sends them back to you. The install procedure: Create a directory to hold the PGP keyrings and the emscript temporary files. Generate a secret/public key pair for the emscrypt software and place in the emscrypt directory. These need to be DIFFERENT for each installation of emscrypt. Otherwise you are subject to a "same play" attack. I suppose you could create two or more installations with the same key if you will ALWAYS be sending all the same scripts to every installation. Generate a public keyring in the emscrypt directory which has only the keys with which you want to be able to validate incoming scripts. Make them "trusted" by the emscrypt key. Update the PGPPASS, PGPPATH, and emscryptPath variables in the emscrypt script. This is very important since if the PGPPATH is pointing to your normal pubring ANYONE with a key in that ring would be able to run scripts on your system. Actually only the keys which are "trusted", but there may be lots of "trusted" keys which you wouldn't trust to run arbitrary scripts on your computer. Test the script to make sure it seems to work alright on your system. After that, you can set it up to be automatically called when you receive e-mail with the magic subject line of your choosing (or in some other way I suppose). I've been using something resembling the following procmail recipe: :0: * ^Subject.*SQUEAMISH OSSIFRAGE |/MY_PATH/emscrypt How emscrypt works: * Get input Get one input line at a time, and look for Reply-To: and From: headers to get a reply address. As we are slurping up lines, watch for '-----BEGIN PGP' lines. If it is for encryption or a signed message (i.e. as long as it is not for a key block), get all the lines up to and including the appropriate '-----END PGP' line, and save them to a temp file. Note that several scripts can be batched together in a single input file. Just generate the scripts and sign them separately and the combine all the PGP messages into a single file. Also, they may be signed with different keys. * Verify signature Run PGP on the temp file to verify/decrypt it. Save the stderr results from the PGP process in another temporary file. Get the verified(?)/decrypted output from a pipe, and save in memory. (QUESTION: is it possible to have stderr redirected to a separate input pipe and avoid writing to disk? How? (This is in Perl.) I was combining the the stderr and stdout from the PGP process into a single input pipe, but that may allow for leakage of PGP stderr output into the script we are verifying/decrypting if we aren't careful.) Search through the PGP process stderr output to look for important stuff like whether the signature was good, what the time stamp was, and what the key user string is. I'm not real happy with this method. Probably doesn't work well with versions other than 2.6.2 or non english language versions. I'm waiting for the signature code and such in the PGP library from Systemics (an announcement showed up here a couple days ago, http://www.systemics.com/software/ ) which will allow this to be much cleaner. (QUESTION: Any other ideas for handling this?) * Check for replay If the signature is good then we need to check for the dreaded replay attack. This is how I have it working: there is a separate file for each PGP public key which keeps track of the time stamp for the last executed script which was signed by that key. Right now the file names are generated from the key ID string for the pgp key. Mainly because we get that for free when we check the signature. Will probably run 'pgp -kv "ID string"' so that I can get the hex key ID, since that would probably make a more reasonable file name. Besides the value saved to disk, we store a separate time stamp for this "batch" of messages in an associative array by key ID. Each separate mail message is a batch, but we may have more than a single PGP signed script in each message. So the batch time stamp is the stamp we read from a time stamp file for a key ID when we process the first message in a batch for that specific key ID. The batch time stamp is then constant for the remainder of this run of the script. Anyway, we generate a file name based on the key ID, save it in an associative array by key ID for later use, and see if the file actually exists. If the file doesn't exist, create it and save the time stamp from the current signature to the file. Put a timestamp of 100000000000 in an associative array by key ID for later use (this is the batch time stamp: the time stamp is formatted as YYYYMMDDHHmm. I use 100000000000 here since I explicitly check the time stamp format each time to make sure it is composed of exactly 12 digits. Also, if the file doesn't exist, we need to use a batch time stamp that will be lower than that of any of the messages in the current batch for this key ID. I suppose it might be better to generate a time stamp something like (CURRENT_TIME - (some reasonable amount of time)) to limit what is accepted. I also plan to allow a limit for the amount of time which can elapse between the script being signed and being received by emscrypt for cases where the file does exist. If the file did exist on disk, read the time stamp from the file and save in the batch time stamp associative array by key ID. So now we have a replay prevention time stamp to compare to the time stamp from this PGP signed script. If the script stamp is more recent, then we can execute the script. But first, check to see if the script stamp is more recent then the stamp saved in the file. If it is, then replace the file time stamp with the script stamp, and update the associative array which keeps track of these values (this is the "most recent stamp" array, not the "batch stamp" array). * Execute the script Check the variable status to make sure that both the signature and time stamp were acceptable. If not, then generate an appropriate error message explaining why the script was rejected, include a copy of the script, encrypt the message using the submitter's public key, and mail it back. Then go back to the top of the loop to deal with the rest of the input. If it everything checks out, then prepare a file to receive the stderr output, save the script to a file, set the script to executable, and open (execute) it as an input pipe. Get the results from stdout. Open the stderr file, and get the stderr results. Combine the stdout, stderr, and the script (with separators so we can tell what is what), encrypt the whole bundle with the submitter's public key and mail it off. Repeat loop for rest of input. Problems? Suggestions? Let me know. Thanks, - --Matt - -- mcarpent(a)mailhost.tcs.tulane.edu Finger for PGP public key. -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQEVAwUBMedc/SjtJAMyBnp9AQF83wf+J9P1Lmr8sca12R89LUYcFxRms1gJro/9 E5Ni1kqivWKYJ+JP9geP+k7VLWbq5miby8RMfKemuz77BuK9UIQG1pd6bGNjlSg9 O+XkiB5dbHX6+hZ23wPABzeuu6+3klLfNnzQEuNZ4/jxeNwFIIY3ifYglhWIPoeG a3kpd2DXY1HVjO674TQNGBYn6bnDPi5wMzYSTxJLukKHBzlgaLt4nssv/8N2jhcg XHWqEEvHc2lY0UvBk+wuqJHigzI03NzpFkh7mgF6ll5gEuG0qGgvLIKb+ir4vF1Q k46mNHq03M+Vc5/loLjFfQzcuu24GdjlFY2pHEpHz7rhYG25ONJeDg== =Lm22 -----END PGP SIGNATURE-----

3 3

Internet Relay Chat
by nobody＠REPLAY.COM 17 Dec '03

17 Dec '03

Is it legal to hack IRC??? Just wondering..

3 2

Re: Can the inevitability of Software privacy be used to defeat the ITAR?
by jim bell 17 Dec '03

17 Dec '03

At 11:27 PM 7/12/96 -0700, Bill Frantz wrote: >At 9:21 PM 7/12/96 -0400, Michael Froomkin wrote: >>> could claim that MIT came very close to violating ITAR, but the same claim >> >>"The ITAR do not apply to books" > >I'm not sure the exact legalities apply here. I think it is more like the >mob pressuring business men for protection and punishing those who do not >comply. And that's what "our" government's coming to! Does anybody still think that they're not going to deserve what they get? Jim Bell jimbell(a)pacifier.com

1 0

Re: CDT Policy Post 2.27 - No New News on Crypto:
by jim bell 17 Dec '03

17 Dec '03

At 06:23 PM 7/12/96 -0400, Bob Palacios wrote: >----------------------------------------------------------------------------- > _____ _____ _______ > / ____| __ \__ __| ____ ___ ____ __ > | | | | | | | | / __ \____ / (_)______ __ / __ \____ _____/ /_ > | | | | | | | | / /_/ / __ \/ / / ___/ / / / / /_/ / __ \/ ___/ __/ > | |____| |__| | | | / ____/ /_/ / / / /__/ /_/ / / ____/ /_/ (__ ) /_ > \_____|_____/ |_| /_/ \____/_/_/\___/\__, / /_/ \____/____/\__/ > The Center for Democracy and Technology /____/ Volume 2, Number 27 >---------------------------------------------------------------------------- > A briefing on public policy issues affecting civil liberties online >---------------------------------------------------------------------------- > CDT POLICY POST Volume 2, Number 27 July 12, 1996 >(1) NO NEW NEWS ON ENCRYPTION - VP GORE REITERATES SUPPORT FOR KEY ESCROW > >Despite the growing pressure from Congress, privacy advocates, the computer >industry, and the public for the reform of US encryption policy, the >Administration continues to embrace its Clipper III key-escrow encryption >proposal. Bob, I think I'd feel a lot better about CDT if you'd explicitly withdraw any support for the Leahy encryption bill. Jim Bell jimbell(a)pacifier.com

1 0

SECURE + PGP
by Remo Pini 17 Dec '03

17 Dec '03

I played around with secure (eudora plugin) a little bit, but it seems to be unable to decrypt anything it encrypted. (eudora 16-bit on winnt 4.0) Any hints? Also, I wan't to write a mail-program (like eudora), with built-in PGP. Is the algorithm published anywhere (including the protocols)? ie.: key generation, signing, en- and de-crypting, u.s.w. I presume the algorithms are of the shelf (DES and IDEA), but what about the hash-algorithms and key-ring management? ----------< fate favors the prepared mind >---------- Remo Pini Fon 1: +41 1 350 28 82 mailto:rp@rpini.com Fon 2: +41 1 465 31 90 http://www.rpini.com/remopini/ Fax: +41 1 350 28 84 --------< words are what reality is made of >--------

2 1

Re: I@Week on crypto export loophole 6/24/96
by Will Rodger 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- At 01:03 PM 7/13/96 +0200, you wrote: >Will Rodger wrote: >> >> The odds the US would go after a foreign company would seem pretty remote, >> unless based in a country that strongly suppported US policy. > >Er, right ... Just like they don't go after the Swiss bankers who >choose to have dealings with Columbians, or German businessmen who >have dealings with Cubans ... > You're right. I should have be more specific: I was thinking the odds the US could successfully prosecute a non-US citizen for violating those laws seems pretty remote if that person was from a country not in agreement with US crypto policy. "Go after" is a bit vague. Shame on me. -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQEVAwUBMefTA0cByjT5n+LZAQFPIAgA1CePSpY1wJm8CCQEloxIZMQMXNuaOC3U Un6JpPtIIDY8X/uSFP7wg8Mgbt+bKBNp1Ehgx6dPMavs8JnMTQWZGGuSDlIdc+5Y 41sTEA6ig6iIls3NqnnVz+0F6JTRF20gKCR1KH++7EdG/zJKJJN833N9NU4QP3od vXQ8jkaNILWzawsh83d9ZngC3ublDFU9onDOx6XIJAoSFNUn39hN8198BCtixCSq FzIDsR2cuiWe4k1PcrUAtKCOlqRxjNqrgc/sy5Gf56qIdjbgJ/rfvO9Rf6JVFZ3i 6dIqw37OEZZ89+pm5hWnjjRQUj2O3oFgO6psBdLkfXkYF6w9ryVbAw== =+1IU -----END PGP SIGNATURE-----

1 0

e-mail spam solution by Bryce Re: ADMIN: Please ignore HLD publishing
by Bryce 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- [this is an e-mail reply to a Usenet post, carbon-copied to cypherpunks list.] In comp.os.linux.announce you, Lars Wirzenius <liw(a)iki.fi>, wrote: > >Meanwhile, I'm beginning to feel rather annoyed by the general spam >problem, especially e-mail spam. Me too. > During the worst days, about half of my non-mailing-list mail is spam. > I am in the process of installing a filter that will make it more > difficult to reach me via e-mail. I am going to require strangers to > use a password in the subject line to reach me (people I know will be > put onto a whitelist). It will be easy to get the password, but > I doubt that spammers will bother. This filtering is not in effect > yet. I'll inform you when it is. I have a great idea for an upgrade to your filter, for that fateful day when spammers start using your password: Have your filter reject any incoming mail which is not 1) from one of your white-listed friends or 2) accompanied by a one U.S. Dollar "good faith" deposit. Spammers will not find it worthwhile to send unwanted mail, because it costs them one dollar each time. But people who sincerely have interesting information for you, even if they are not people on your whitelist, can send the one dollar "good faith" deposit with a good chance that you will give the money back to them once you have read their letter. Just another example of how Ecash(tm) is going to improve the Net. Regards, Bryce -----BEGIN PGP SIGNATURE----- Version: 2.6.2 Comment: www.c2.net/~bryce -- 'BAP' Easy-PGP v1.1b2 iQCVAwUBMejncPWZSllhfG25AQEypAQAkiC1O4nab+aLMo6v3stbHUm/VLtHo+lC kIOD+UU+ckc4/vHEMLWgT4LfQ2EH338GxOkA7zgcBe9nhcBxIqvlqU5BurmLie/X j7xXFcQTzf+D+fIaD3xBjQrs/g2oOwqiGrCKCkEf3MWzYu1J7Bw1W458vjziizyu +Q8VBY6cVV0= =nRLB -----END PGP SIGNATURE-----

1 0

Re: ANNOUNCEMENT: PGPfone Beta 7 Now Available for Download
by Harry Hochheiser 17 Dec '03

17 Dec '03

On 12 Jul 96 at 21:31, Arun Mehta wrote: > At 23:38 10/07/96 -0700, Will Price wrote: > >ANNOUNCEMENT: PGPfone Beta 7 Now Available for Download > > Sorry if this has been discussed before (please point me in the > right direction if that is the case), but VSNL, my government-owned > ISP (which also has a monopoly on all international traffic) made me > sign that I will not use my Internet connection for voice traffic. > Is there any way they could find out if I were using PGPfone, or > rather, could I prevent them from finding out? Arun: I can't give you a definitive answer here, but I'll take a shot. Most Internet telephony systems use UDP packets to transfer speech, since the lower overhead of UDP (as opposed to TCP) allows for better throughput. I assume (but I'm not certain) that PGPfone works the same way. Unfortunately, most of your other TCP/IP communication will be based on TCP packets. Therefore, it's theoretically possible for your ISP to monitor your traffic, watching for large numbers of UDP packets. --------------- Harry Hochheiser harry(a)tigger.jvnc.net 08 3A B5 F6 47 7F C7 C4 28 B4 8D D2 2E DF F6 1E

4 3