July 1993 - cypherpunks-legacy

Re: forged mail
by hfinney＠shell.portal.com 25 Jul '93

25 Jul '93

From: Peter Breton <pbreton(a)cs.umb.edu> > Actually, forging mail at the machine you're on en route to the remailer > protects you against: > > 1) Anyone who can snoop the message headers on the way to the remailer > ("Tra la la. Let's keep a little list of everyone using those remailers...") > > 2) A corrupt remailer operator. It's not so much a matter of "corrupt" remailer operators. The remailer scripts on the cypherpunks FTP site are distributed with automatic logging of the text of ALL remailed messages by default. This is intended for debugging purposes, but some of the remailers still operate in this mode. This could perhaps provide some protection against liability for operators of remailers, because they can trace back the source of an abusive message that was sent through their remailers. However, it obviously seriously impairs user privacy. The only logs my remailers (on hfinney(a)shell.portal.com and hal(a)alumni.caltech.edu) keep are the date and time when they did an operation. No record is kept of any message header or content which would allow re- construction of sender information. The date/time stamps just give me a general idea of how much my remailer is used. However, Eric Hughes has pointed out that most Unix systems can be configured to keep logs of all incoming and outgoing mail. Such logs could be used to reconstruct input/output pairs, by observing that a particular message sent to me was followed by a particular outgoing message a few seconds later. I have not been able to determine whether such logs are kept on the machines I use (the directories which would hold them are protected) but it's safest to assume that they are. I think a better solution to the problem than trying forged mail is to use a chain of cypherpunks remailers, some of which are user-owned and -operated and which (I think) have policies of not keeping content logs. The monthly postings of remailer lists include information on which machines are user- owned, although no information is listed presently about logging. Since the whole point of a remailer is to lose incoming-to-outgoing correspondence, it seems to me that logging should be minimized, otherwise there is little point to running a remailer. Hal Finney hfinney(a)shell.portal.com

1 0

REMAIL: replying to cp-remailed messages
by hfinney＠shell.portal.com 25 Jul '93

25 Jul '93

I want to elaborate on Eric's comment about the "##" pasting token. The cypherpunks remailers are activated by mail header fields. They look for a header entry of the form "Request-Remailing-To:" among the Subject, From, To, etc. headers. Although it is traditional for user-defined extension header fields to start with "X-", Eric argued that since we hope to extend remailer availability to the point that it is a widespread and standard service, it was reasonable to choose a non-"X-" field name. Since some mailers don't allow users to insert header fields, Eric created the "::" incoming pasting token. If no header field is found matching the ones the remailer looks for, it then checks to see if the first non-blank line of the message is "::". If so, it copies all the following lines of the message into the header, up to the next blank line, and then restarts processing of the message. The "::" line is intended to be followed by the user-added header fields like "Request-Remailing-To". When the remailer does a remailing step, it strips all of the header fields except Subject. Keeping the Subject header impairs security somewhat because it would facilitate pairing up input and output messages, but it adds a lot of convenience for users. What is little known is that there is another step which can be done. Just before the remailer sends a message for which remailing has been requested, it again checks the first non-blank line, this time to see if it is the outgoing pasting token "##". If so, it again copies the following lines up to a blank line into the message header of the outgoing message. The message is then sent without further processing. This means that any header line can be added to an outgoing message by this means. In particular, as Eric pointed out, a Reply-To header could be added which would reveal the true sender of the message for those cases where that was wanted. Subject headers could also be added at this step as well as after the :: incoming pasting token. Hal Finney hfinney(a)shell.portal.com

1 0

No Subject
by UCX_SMTP＠crc.monroecc.edu 24 Jul '93

24 Jul '93

---- Transcript of session follows ---- 196608 %NONAME-W-NOMSG, Message number 00000000 -SYSTEM-S-NORMAL, normal successful completion ---- Unsent message follows ---- Received: from toad.com by relay2.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA00909; Thu, 22 Jul 93 21:41:38 -0400 Received: by toad.com id AA14078; Thu, 22 Jul 93 18:01:32 PDT Received: by toad.com id AA13842; Thu, 22 Jul 93 17:53:04 PDT Return-Path: <UCX_SMTP(a)crc.monroecc.edu> Received: from decwrl.UUCP by toad.com id AA13837; Thu, 22 Jul 93 17:53:03 PDT Received: by uucp-gw-2.pa.dec.com; id AA12960; Thu, 22 Jul 93 12:50:15 -0700 Received: from emory.UUCP by merlin.gatech.edu with UUCP id AA20089 (5.65c/IDA-1.4.4 for decvax!decwrl!hoptoad!CYPHERPUNKS); Thu, 22 Jul 1993 15:25:50 -0400 Received: from indigo.UUCP by emory.mathcs.emory.edu (5.65/Emory_mathcs.3.4.11) via UUCP id AA07594 ; Thu, 22 Jul 93 15:15:19 -0400 Resent-Message-Id: <9307221915.AA07594(a)emory.mathcs.emory.edu> Received: by indigo.mese.com (DECUS UUCP /2.0/2.0/2.0/); Thu, 22 Jul 93 14:38:30 EDT Resent-Date: Thu, 22 Jul 1993 14:27:57 EDT Resent-From: <cypherpunks(a)indigo.mese.com> Resent-To: <CYPHERPUNKS(a)toad.com> Received: by INDIGO.MESE.COM (MX V3.1) with UUCP; Thu, 22 Jul 1993 14:27:48 EDT Received: from orion.crc.monroecc.edu by emory.mathcs.emory.edu (5.65/Emory_mathcs.3.4.11) via SMTP id AA23297 ; Wed, 21 Jul 93 23:26:36 -0400 Date: Wed, 21 Jul 93 23:26:36 -0400 From: UCX_SMTP(a)crc.monroecc.edu Message-Id: <9307220326.AA23297(a)emory.mathcs.emory.edu> Apparently-To: <cypherpunks(a)indigo.mese.com> To: <cypherpunks(a)indigo.mese.com> ---- Transcript of session follows ---- 196608 %NONAME-W-NOMSG, Message number 00000000 -SYSTEM-S-NORMAL, normal successful completion ---- Unsent message follows ---- Received: from toad.com by relay2.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA06943; Wed, 21 Jul 93 23:22:44 -0400 Received: by toad.com id AA21927; Wed, 21 Jul 93 19:16:03 PDT Received: by toad.com id AA21680; Wed, 21 Jul 93 19:02:20 PDT Received: from decwrl.UUCP by toad.com id AA21676; Wed, 21 Jul 93 19:02:19 PDT Received: by uucp-gw-2.pa.dec.com; id AA18750; Wed, 21 Jul 93 19:00:31 -0700 Received: from emory.UUCP by merlin.gatech.edu with UUCP id AA03218 (5.65c/IDA-1.4.4 for decvax!decwrl!hoptoad!CYPHERPUNKS); Wed, 21 Jul 1993 21:36:21 -0400 Received: from indigo.UUCP by emory.mathcs.emory.edu (5.65/Emory_mathcs.3.4.11) via UUCP id AA16552 ; Wed, 21 Jul 93 21:27:59 -0400 Resent-Message-Id: <9307220127.AA16552(a)emory.mathcs.emory.edu> Received: by indigo.mese.com (DECUS UUCP /2.0/2.0/2.0/); Wed, 21 Jul 93 21:25:09 EDT Resent-Date: Wed, 21 Jul 1993 21:21:26 EDT Resent-From: <cypherpunks(a)indigo.mese.com> Resent-To: <CYPHERPUNKS(a)toad.com> Received: by INDIGO.MESE.COM (MX V3.1) with UUCP; Wed, 21 Jul 1993 21:21:18 EDT Received: from relay2.UU.NET by emory.mathcs.emory.edu (5.65/Emory_mathcs.3.4.11) via SMTP id AA12591 ; Wed, 21 Jul 93 20:34:47 -0400 Received: from toad.com by relay2.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA14330; Wed, 21 Jul 93 20:31:29 -0400 Received: by toad.com id AA18642; Wed, 21 Jul 93 16:09:44 PDT Received: by toad.com id AA18609; Wed, 21 Jul 93 16:07:26 PDT Return-Path: <lock60!snark!boojum!esr(a)gvls1.VFL.Paramax.COM> Received: from gvls1.VFL.Paramax.COM ([128.126.220.104]) by toad.com id AA18605; Wed, 21 Jul 93 16:07:15 PDT Received: from lock60.UUCP by gvls1.VFL.Paramax.COM (4.1/mls/4.0) id AA04653; Wed, 21 Jul 93 19:07:13 EDT X-Info: VFL.Paramax.COM is the new name for GVL.Unisys.COM Please change any mailing lists or aliases. Both the old and the new addresses will work for a short time. Received: by lock60.Canal.Org (smail2.5) id AA16551; 21 Jul 93 18:50:24 EDT (Wed) Received: by snark.thyrsus.com (/\==/\ Smail3.1.21.1 #21.19) id <m0oIjLP-00020KC(a)snark.thyrsus.com>; Wed, 21 Jul 93 14:56 EDT Received: by boojum.uucp (Smail3.1.28.1 #2) id m0oIiVK-000BQZC; Wed, 21 Jul 93 14:03 EDT Message-Id: <m0oIiVK-000BQZC(a)boojum.uucp> From: <boojum!esr(a)gvls1.VFL.Paramax.COM> Subject: FAQ, round 2 To: boojum!cypherpunks(a)uunet.uu.net Date: Wed, 21 Jul 93 14:03:02 EDT X-Mailer: ELM [version 2.3 PL11] I've written some more material for it. Criticisms and additions welcome. --- DRAFT VERSION ---- DRAFT VERSION ---- DRAFT VERSION ---- DRAFT VERSION --- From: esr(a)snark.thyrsus.com (Eric S. Raymond) Newsgroups: news.answers Followup-To: poster This is the Cypherpunks FAQ. It explains the projects and purposes of the Cypherpunks mailing list. It is also intended to serve as a general introduction to privacy and encryption issues. For details on the technical and theoretical aspects of computer cryptography, see the sci.crypt FAQ, available for FTP from rtfm.mit.edu (18.172.1.27) in the directory pub/usenet-by-group/sci.crypt. The cypherpunks archive is available for FTP at soda.berkeley.edu:pub/cypherpunks This site contains code, information, rants, and other miscellany, including the most up-to-date version of this FAQ. This FAQ is maintained by Eric S. Raymond <esr(a)snark.thyrsus.com>; send additions and corrections to that address. Sections contributed by others are credited to individual authors. We gratefully acknowledge, in addition, feedback and comments from David Mandl <dmandl(a)lehman.com> and Eric Hughes <hughes(a)soda.berkeley.edu>. Here is a table of contents for this FAQ: 1. Why cypherpunks? 2. What are the essentials of privacy software? a. Public-key cryptosystems for secure communication. b. Unforgeable electronic signatures for message authentication. c. DC-net or similar protocols to thwart spoofing. 3. What are the potential applications of good privacy software? a. Secure communications. b. Digital cash. c. Electronic voting. d. Electronic contracts. e. Secure anonymous remailers and posters. f. <more?> 4. What are the key algorithms, tools, and implementations for privacy software? a. RSA b. DES c. Clipper/Capstone/DSS d. PGP e. Possible non-RSA trapdoor functions. 5. What are the social and political implications of good privacy software? a. Drastically lower transaction costs for trade. b. Expansion of the counter-economy. c. Disempowerment of government. d. Anonymity for whistleblowers. 6. What are the legal, political, and technical obstacles? a. The Clipper/Capstone/DSS power grab. b. The RSA patent and the PGP/RSA fight. c. RSA's base problem may not be NP-complete. 7. What can I do to help? a. Work on cryptographic software. b. Agitate against the Clipper/Capstone/DES proposals. c. Promote the use of encrypted communication. To join the cypherpunks mailing list, send a request to: cypherpunks-request(a)toad.com Working with us could be your best shot at stopping Big Brother. So if you have skills to contribute, act now. The freedom you save could be your own. 1. Why cypherpunks? Because privacy is essential to freedom. If the government (or any other oppressor that behaves like one) can effectively monitor communications, it can control or suppress them. And it will do so, because the natural tendency of controllers is always to seek more control. The government cannot be relied on to protect your privacy rights. Nor can anyone else --- certainly not your employer, or the corporations that want to know all about you so they can sell you things. Given half the chance, governments and corporations will always push for security standards that protect *them*, but not *you*. Computer technology can help protect you against would-be snoopers, but only if somebody is sufficiently smart and dedicated to build the tools. The Cypherpunks list exists to build and propagate privacy software. Our aim is to give you the tools to keep your private information private, and to communicate with other people and computers in ways snoopers cannot tap. 2. What are the essentials of privacy software? a. Public-key cryptosystems for secure communication. A conventional cryptosystem consists of an encoding/decoding method and a single key. Two users who share a key can exchange private messages. A public-key cryptosystem uses a *pair* of keys; one private, one public. Anyone with either key can decode messages encoded with the other. For privacy, it must be impossible (or at least impractical) to deduce the private key from the public one. Public-key cryptosystems imply many exciting things --- unforgeable electronic signatures, digital cash, and secure electronic contracts are among them. The basic idea behind all of these is that, as long as your private key is secure, people can verify that an encoded message containg known text came from you by decoding with your public key. In the remainder of this FAQ we use `PKC' as an abbreviation for `Public Key Cryptosystem'. The best-known PKCs are the RSA system, the Federal Government's DES standard, and the government's Clipper proposal. We'll discuss these, and others, in more detail below. b. Unforgeable electronic signatures for message authentication. There are many circumstances in which you want to be able to check a public clear-text message for tampering. To do this, the message must contain a `digital signature' or `message digest code' or `message hash' derived from its clear text, which can be checked against the clear text by a receiver. For security, the message hash should have the property that no one knows how to modify a message in a way that preserves its hash. PKCs give you unforgeable signatures as a side-effect. Unfortunately, known PKCs are too slow to use practically for message hashing. Thus, there is a separate category of `Digital Signature Systems'. The three major DSS techniques are Snefru, MD5, and DSS. Snefru, invented by Ralph Merkle at Xerox PARC, is of historical interest only as it has been broken. MD5 is described in Internet RFC 1321, which also gives a reference implementation in C. As of July 1993 it is believed to be secure, but has not been *proved* to be secure. DSS is a Federal Government proposed standard associated with the Clipper proposal. <more needed here> c. DC-net or similar protocols to thwart spoofing. <more needed here> 3. What are the potential applications of good privacy software? a. Secure communications. With a PKC, you can send a message that no one but the intended receiver can decrypt by encoding it with the receiver's public key. If you encode it with *your* public key, the receiver can verify that it came from you. This means that it is possible to do secure communications even over public channels. Neither nosy neighbors, business competitors, nor the government or any (other) criminal gang can interfere with it. b. Digital cash. Unforgeable messages also imply digital cash. You could use a PKC to send to the receiver a code permitting them to draw a particular amount of money from your bank account. The bank, with access to both yours and the payee's public keys, can verify that the order is genuine. This means that it is possible to do trade over electronic links, without any part trusting any other party beyond the bounds of normal commercial risk. c. Electronic voting. Unforgeable messages also imply secure electronic voting. If you encode your voting form with a PKC, the vote-collecting authority can verify it with your public key. d. Electronic contracts. If two or more people encode known text with their private keys applied in succession, all their public keys will be required to decode it. This is an unforgeable contract. Furthermore, it is an unforgeable *private* contract. e. Secure anonymous remailers and posters. <more needed here> 4. What are the key algorithms, tools, and implementations for privacy software? a. RSA RSA stands for `Rivest-Shamir-Adelson', the names of the three computer scientists who developed the technique. RSA has withstood determined attacks for over a decade and is widely believed to be secure. It has been proposed as an Internet standard. The RSA technique is patented. The patents are held by RSA, Inc. <contact information should go here>. An implemenation in C called RSAREF is available for research and certain noncommercial uses. b. DES <more needed here> c. Clipper/Capstone/DSS <more needed here> d. PGP <more needed here> e. Possible non-RSA trapdoor functions. <more needed here> 5. What are the social and political implications of good privacy software? a. Drastically lower transaction costs for trade. <more needed here> b. Expansion of the counter-economy. <more needed here> c. Disempowerment of government. <more needed here> d. Anonymity for whistleblowers. <more needed here> 6. What are the legal, political, and technical obstacles? <more needed here> a. The Clipper/Capstone/DSS power grab. <more needed here> b. The RSA patent and the PGP/RSA fight. <more needed here> c. RSA's base problem may not be NP-complete. <more needed here> 7. What can I do to help? a. Work on cryptographic software. <list of current projects should go here> b. Agitate against the Clipper/Capstone/DES proposals. <more needed here> c. Promote the routine use of encrypted communication. <more needed here> You can help spread PGP and other appropriate tools far and wide (both to help get a better foothold to thwart the Clipper proposal and its ilk, and to work towards making crypto as commonplace as envelopes). --- DRAFT VERSION ---- DRAFT VERSION ---- DRAFT VERSION ---- DRAFT VERSION --- -- >>eric>>

1 0

RE: FAQ, round 2 (posting because of bounce)
by collins＠newton.apple.com 24 Jul '93

24 Jul '93

I tried to mail these comments directly to Eric Raymond, who posted his in progress FAQ. My mail bounced, so I am posting it in hopes that he will get it. I missed a lot of the FAQ commentary, so I apologize if this is all known. Scott Collins | "Few people realize what tremendous power there | is in one of these things." -- Willy Wonka ......................|................................................ BUSINESS. voice:408.862.0540 fax:974.6094 collins(a)newton.apple.com Apple Computer, Inc. 1 Infinite Loop, MS 301-2C Cupertino, CA 95014 ....................................................................... PERSONAL. voice/fax:408.257.1746 1024/669687 catalyst(a)netcom.com ..........bounced comments follow.......... Hi, Good work on the FAQ. I'ts not a rewarding job, I'm sure; I just wanted to personally express gratitude. Sorry I took so long to get these comments to you. > The best-known PKCs are [...] DES DES is a symmetric cypher, i.e. *not* a public key crypto-system. >`digital signature' or `message digest code' or `message hash' A message digest or hash is distinct from a digital signature. In particular, for a given input, everyone will derive the same digest or hash but a different signature. >The three major DSS techniques are Snefru, MD5, and DSS. Again, MD5 is not a signature algorigthm. It is only a (supposedly) cryptographically secure, i.e. one way, hash. Everyone who runs MD5 on the same input, will get the same output. If you meant that MD5 is used as a component of some signature algorithms (which is true), then I apologize, it wasn't clear to me. > DSS is [...] associated with the Clipper proposal. They both come from the government. They were both influenced by the NSA. They are not associated in any formal way. More cousins than brothers. >c. DC-net or similar protocols to thwart spoofing. DC-nets are anonymous voting mechanisms (at their heart). I don't see the direct relation to 'thwart spoofing'. > If two or more people encode known text with their private keys applied in >succession, all their public keys will be required to decode it. This is >an unforgeable contract. Yes, although more often digital signatures are what people want and mean when they discuss digital contracts. With individual digital signatures, i.e. a hash of the contract signed with your private key, each signature can be individually verified. > RSA stands for `Rivest-Shamir-Adelson', Adleman Keep up the good work, Scott Collins | "Few people realize what tremendous power there | is in one of these things." -- Willy Wonka ......................|................................................ BUSINESS. voice:408.862.0540 fax:974.6094 collins(a)newton.apple.com Apple Computer, Inc. 1 Infinite Loop, MS 301-2C Cupertino, CA 95014 ....................................................................... PERSONAL. voice/fax:408.257.1746 1024/669687 catalyst(a)netcom.com

1 0

Key Signing Policy.
by J. Michael Diehl 24 Jul '93

24 Jul '93

-----BEGIN PGP SIGNED MESSAGE----- Well, I got a lot of good discussion about when to sign someone's key. I have since come up with my own policy on when I will sign a key. Actually, I plagarized much of it from the many good responses I received. If anyone looks at my policy, recognizes their words and objects, please tell me. Otherwise, after about 10 days, I will make my statement a matter of public domain. Also, If you have any comments/questions/additions to my statement, please tell me I hope this will help clear up some of the confusion reguarding when to sign someone's key. Laters. BTW, what do you think of my new sig? ========================+==========================================+ J. Michael Diehl ;^) | Have you hugged a Hetero........Lately? | mdiehl(a)triton.unm.edu | "I'm just looking for the opportunity to | mike.diehl(a)fido.org help| be Politically Incorrect!" +=========+ al945(a)cwns9.ins.cwru.edu| Is Big Brother in your phone? | PGP KEY | (505) 299-2282 (voice) | If you don't know, ask me. |Available| ========================+================================+=========+ PGP Key = 7C06F1 = A6 27 E1 1D 5F B2 F2 F1 12 E7 53 2D 85 A2 10 5D This message is protected by 18 USC 2511 and 18 USC 2703. Monitoring by anyone other than the recipient is absolutely forbidden by US Law -----BEGIN PGP SIGNATURE----- Version: 2.2 iQCVAgUBLFDMSlWjzUwifAbxAQG3ngP/QXhforNMRIcDp8/alFhz5jMfXYH5+UTd xIs+hi6ocrSK2ZEtqfndto1agHaTdlNjAaJRgD8twmGrMUi+iEfRfsVtLwjBOTLV Ly0sJbnLbxR9K+2DweC6YsqDNEMvCxS3QHR3q5/sq8jLcPMEdC0wHuZ8lhMp8yCC VhFpls1Lv9Q= =Lgii -----END PGP SIGNATURE-----

2 1

FAQ corrections
by Matt Schroth 24 Jul '93

24 Jul '93

[I tried mailing this directly to Eric Raymond, but I got a bounce message a day later.] Eric, I have read some things I think are incorrect in the FAQ you're working on. I could be wrong, of course, but I wanted to point them out to you anyway: In the introduction to PKC, you say that "the Federal Government's DES standard" is a PKC. Is there some way to view DES as a public key system that I'm not aware of? I have only seen it used as a symmetric key system. In 3a, you state that "If you encode with *your* public key...". I think you meant "with your private key...", as anyone can encode something with a public key. In 4a, "RSA stands for 'Rivest-Shamir-Adelson'"...his name is Adleman. I saw a few "more needed here's". Are you soliciting help for these, or are you just not finished with those sections yourself? Good luck, Matt

1 0

Credit Reports and NS
by Dave Banisar 24 Jul '93

24 Jul '93

Credit Reports and NS Here is the letter opposing the provision to allow for easier access to credit reports. As you can guess, the Senate Intelligence Committee (which generally acts as the biggest supporter of the agencies on the Hill) did not address our concerns at all and approved the provision. I was unable to easily find the actualy text but will get it after I come back from vacation. Dave July 12, 1993 The Honorable Dennis Deconcini Chairman Senate Select Committee on Intelligence United States Senate SH-211 Hart Senate Office Building Washington, DC 20510-6475 Dear Chairman DeConcini; We are writing to voice our strong opposition to the Administration's legislative proposal to amend the Fair Credit Reporting Act (FCRA) to allow the Federal Bureau of Investigation (FBI) to obtain consumer credit reports in foreign counterintelligence cases. The FBI seeks a national security letter exemption to the FCRA to obtain personal information from consumer reporting agencies without a subpoena or court order. A national security letter gives the FBI the authority to obtain records without judicial approval and without providing notice to the individual that his or her records have been obtained by the Bureau. Similar FBT proposals were rejected in previous years after Congressional leaders expressed concern over the civil liberties issues raised. Although the current draft proposal is more comprehensive than those circulated in previous years, the changes and additions do not alter significantly the central character of the proposal. The Administration's 1993 proposal includes explicit limits to'dissemination of obtained information within the goverrment, penalties for violations including punitive damages, and reporting requirements. These provisions are positive changes from the legislation put forward in previous years, but they do not save the proposal from its intrinsic flaws. Therefore, the reasons for our fundamental opposition to the current proposal remain the same: 1) the FBI has not demonstrated a compelling need for access to consumer credit reports; and 2) legislation that implicates civil liberties should be addressed separately and not as part of the authorization process. There are only two instances in which Congress has authorized the FBI, in counterintelligence investigations, to obtain information about individuals pursuant to a national security letter but without a subpoena, search warrant or court order. First, the Electronic Communications Privacy Act (ECPA) of 1986 included a provision requiring common carriers to disclose subscriber information and long distance toll records to the FBI in response to a national security letter. Second, congress included in the 1987 Intelligence Authorization Act an amendment to the Right to Financial Privacy Act (RFPA) that requires banks to provide customer records to the FBI in response to a similar letter. In that case, the FBI presented to Congress its case for obtaining financial records in foreign counter- intelligence cases and the difficulty of obtaining those records without a court order. in both instances when congress has previously authorized the national security letter, Congress recognized that the procedure departs dramatically from the procedure necessary to obtain a court order. The FBI's current proposal seeks similar access to individuals' credit records held by consumer reporting companies. The FBI has yet to adequately justify its need to add such highly personal, sensitive information to the narrow category of records subject to the national security letter exemption. The Bureau claims obtaining credit reports will allow it to more easily determine where a subject of an investigation banks -- information the FBI claims will help them effectuate their ability to access bank records under the RFPA. We opposed the national security letter exemption in the RFPA and do not endorse the FBI's slippery slope approach to ensuring that they can more easily obtain financial information in foreign counterintelligence cases. This information can be and is routinely gained without credit reports. We do not believe convenience is a sufficient justification for this significant exception to the law. The FBI further argues that obtaining banking information through a credit report is preferred because it is actually leas intrusive than those investigative methods that would otherwise be used. While we too are frustrated that other information- gathering techniques are frequently too intrusive, our objections to the other techniques do not lead us to endorse yet another technique that is also intrusive and that weakens existing privacy law. Finally, we object to using the authorization process as the vehicle for pursuing this change. The national security latter exemption, because it diminishes the due process and privacy protections for individuals, must be given the most careful consideration. The FBI's proposal should be introduced as separate legislation on which public hearings can be held. only in this way can the Committee test thoroughly the FBI's case for the exemption and hear from witnesses who object to the change. We urge you to reject the FBI's proposal in its current form. We are available to work with you on this issue. Sincerely, Janiori Goldman Michelle Meier Privacy and Technology Project Consumers Union American civil Liberties Union Marc Rotenberg Evan Hendricks Computer Professionals for U.S. Privacy Council Social Responsibility cc: Members, Senate Select Committee on Intelligence The Honorable George J. Mitchell Senate Majority Leader The Honorable Donald W. Riegle, Jr., Chairman Senate Committee on Banking, Housing and Urban Affairs The Honorable Patrick J. Leahy, Chairman Subcommittee on Technology and the Law

2 1

Encrypted communications with phone and PC
by nowhere＠bsu-cs.bsu.edu 24 Jul '93

24 Jul '93

I am about 300 messages behind on the list because I'm dialing in long- distance right now, but I just happened to think of something because it is related directly to my work... I install and debug voice mail systems all the time that run on 286's, 386's or 486's and can run up to 24 telephone lines on a single computer *at full speed*. The analog signal gets digitized by the voice board, compressed, and stored on disk whenever a person leaves a message. What if an extra step were added where the information were encrypted before being written to disk and it took the receiver entering his PGP key on the PC before it would play the messages to him? Then, if this works, the user on each end could use a computer with a voice board in it and dial into one port while an encrypted/scrambled session is being transmitted on another port. Who knows how real-time it would be and I don't have the technical expertise to pull it off, but I see these things go out of our office every day with little security other than that of obscurity on them. One note, though, the voice boards that we use (high quality) cost anywhere from $800 for a repaired one to $1000 for the one I like the best to $1200 for a different brand that we also sell. Neither voice mail software vendor is willing to give us the super-secret security code that unlocks full system access, so I seriously doubt if I could scare any source out of them. Anyway, it is a thought and now that I have my own voice board to play with I might just try to piece together some interesting software. Chael -- Chael Hall nowhere(a)bsu-cs.bsu.edu, 00CCHALL(a)BSUVC.BSU.EDU, chall(a)bsu.edu (317) 776-4000 from 8 am - 5 pm CST

1 0

Macpgp 2.3
by deboni＠diego.llnl.gov 24 Jul '93

24 Jul '93

I just fetched macpgp 2.3 from soda, and wound up with a file ending in the suffix "gz". This is a new one on me, and I don't know how to decode it. Can anybody inform me? Inside whatever it is is a binhexed compactor file, and I can deal with those formats, but the outside wrapper defies every decompressing utility I've got. Tom DeBoni deboni(a)llnl.gov

4 3

Re: Macpgp 2.2
by fnerd＠smds.com 24 Jul '93

24 Jul '93

> However, I have the prog > available here at aql.gatech.edu /pub/cypherpunks/pgp/binaries in cpt.hqx > format. The source code for gzip is also available in /pub. > > Hope this helps. > > A N Paul S. Goggin (1993) | Cypher, Cyber, Chaos > E chaos(a)aql.gatech.edu | Carpe Diem: Stop the Clipper wiretap chip Thanks, but a) BINARIES? b) who are these binaries PGP-signed by? c) what program do I use to verify the signature(s)? I do mean the thanks. Just wondering. -fnerd quote me

2 1