From yanek at novavax.nova.edu Fri Jan 1 09:21:32 1993 From: yanek at novavax.nova.edu (Yanek Martinson) Date: Fri, 1 Jan 93 09:21:32 PST Subject: Random Number Generation references In-Reply-To: <9212310751.AA21888@cygnus.com> Message-ID: <9301011720.AA05280@novavax.nova.edu> Here's a list of references from the end of Rueppel's _Stream_Chiphers_ that seem to be relevant to random number generation: J. Bernasconi and C.G. Gunther, "Analysis of a nonlinear feedforward logic for binary sequence generators," BBC Tech. Rep., 1985 T. Beth and F. Piper, "The stop-and-go generator," in Lecture Notes in Computer Science 109; Advances in Cryptology: Proc. Eurocrypt '84, T. Beth, N. Cot, and I. Ingemarsson, Eds., Paris, France, April 9-11, 1984, pp. 88-92. Berlin: Springer-Verlag, 1985. M. Blum and S. Micali, "How to generate cryptographically strong sequences of pseudo-random bits," SIAM J. Comput., vol. 13, pp. 850-864, 1984 L. Blum, M. Blum , and M. Shub, "A simple unpredictable pseudo-random number generator," SIAM J. Comput., vol. 15, pp. 364-383, 1986. J.O. Bruer, "On pseudo random sequences as crypto generators," in Proc. Int Zurich Seminar on Digital communication, Switzerland, 1984. L. Brynielsson, "On the linear complexity of combined shift regiser sequences," in Lecture Notes in Computer Science 219; Advances in Cryptology: Proc. Eurocrypt '85, F. Pichler, Ed., Linz, Austria, April 1985, pp. 156-166. Berlin: Springer-Verlag, 1986. J. Gait, "A new nonlinear pseudorandom number generator," IEEE Trans. Software Eng., vols. S E3, no. 5, pp. 359-363, Sept. 1977. O. Goldreich, S. Goldwasser, and S. Micali, "How to construct random functions," J. ACM, vol. 33, no. 4, pp. 792-807, 1986. D. Gollman, "Pseudo random properties of cascade connections of clock controlled shift registers," in Lecture Notes in Computer Science 209; Advances in Cryptology: Proc. Eurocrypt '84, T. Beth, N. Cot, and I. Ingermasson, Eds., Paris, France, April 9-11, 1984, pp. 93-98. Berlin: Springer-Verlag, 1985. B. Kaliski, A pseudo random bit generator based on elliptic logarithms, M. Sc. thesis, Massachusetts Institute of Technology, 1987. E. L. Key, "An analysis of the structure and complexity of nonlinear binary sequence generators," IEEE Trans. Inform. Theory, vol. IT-22, no. 6, pp. 732-763, Nov. 1976. M. Luby and C. Rackoff, "How to construct pseudorandom permutations from pseudorandom functions," SIAM J. Comput. vol. 17, pp. 373-386, 1988. J.L. Massey, A. Gubser, A. Fischer, P. Hochstrasser, B. Huber, and R. Sutter, "A self-synchronizing digital scrambler for cryptographic protection of data," in Proceedings of International Zurich Seminar, March, 1984. J.L. Massey and R.A. Rueppel, "Linear ciphers and random sequence generators with multiple clocks," in Lecture Notes in Computer Science 209; Advances in Cryptology: Proc. Eurocrypt '84, T. Beth. N. Cot, and I. Ingermasson, Eds., Paris, France, April 9-11, 1984, pp. 74-87. Berlin: Springer-Verlag, 1985. U. Maurer and J. L. Massey, "Perfect local randomness in pseudo-random sequences," in Lecture Notes in Computer Science 435; Advances in Cryptology: Proc. Crypto'89, G. Brassard, Ed., Santa Barbara, CA, Aug. 20-24. 1989, pp. 110-112. Berlin: Springer-Verlag, 1990. U. Maurer, "A provable-secure strongly-randomized cipher," in Lecture Notes in Computer Science 473; Advances in Cryptology: Proc. Eurocrypt'90, I. Damgard, Ed., Aarhus, Denmark, May 21-24. 1990, pp. 361-373. Berlin: Springer-Verlag. S. Micali and C.P. Schnorr, "Efficient, perfect random number generators," preprint, Massachusetts Institute of Technology, University of Frankfurt, 1988. R.A. Rueppel and O. Stafflebach, "Products of sequences with maximum linear complexity," IEEE Trans. Inform. Theory, vol. IT-33, no.1, pp. 124-131, Jan. 1987. A. Shamir, "On the generation of cryptographically strong pseudo-random sequences," 8th Int. Colloquim on Automata, Languages, and Programming, Lecture Notes in Computer Science 62, Springer Verlag, 1981. Y. Zheng, T. Matsumoto, and H. Imai, "Impossibility and optimality results on constructing pseudorandom permutations," in Lecture Notes in Computer Science 434; Advances in Cryptology; PRoc. Eurocrypt'89, J.-J. Quisquater and J. Vandewalle, Eds., Houthalen, Belgium, April 10-23, 1989, pp. 412-422. Berlin: Springer-Verlag, 1990. -- Yanek Martinson mthvax.cs.miami.edu!safe0!yanek uunet!medexam!yanek this address preferred -->> yanek at novavax.nova.edu <<-- this address preferred Phone (305) 765-6300 daytime FAX: (305) 765-6708 1321 N 65 Way/Hollywood (305) 963-1931 evenings (305) 981-9812 Florida, 33024-5819 From edgar at spectrx.Saigon.COM Fri Jan 1 17:10:34 1993 From: edgar at spectrx.Saigon.COM (Edgar W. Swank) Date: Fri, 1 Jan 93 17:10:34 PST Subject: A solution remailer signature suppression Message-ID: <1k4PwB7w165w@spectrx.saigon.com> Hugh Daniels said here on Dec 28: There are very good reasons to build remailers (and all mail tools) to pass on all the bytes they can, trailing spaces and .sigs included. Hugh doesn't say what these reasons are. They are not obvious to me, so I must disagree. I've already stated what I think are good reasons at least for remailers whose purpose is anonymity to remove automatic sigs which are likley to destroy anonymity. I've said I would accept either a less ambiguous sig delimiter than "--" or a remailer option to remove the sig (default) or leave it in. Might I sugjest that we set up the remailers with a feature where it tests mail sent from its owner to make sure there is no "compromising" content and that the outer shell verifies correctly, if it fails either of these tests it is dumped in a file and a note returned to you saying someings not right. Hugh doesn't say what criteria we are to use to detect "compromising" content (short of genuine AI) or what the outer shell is supposed to verify to. Why limit this test to the remailers "owner"? This system I use doesn't allow me to run my own software, so I think this idea wouldn't work for me, in any case. -- edgar at spectrx.saigon.com (Edgar W. Swank) SPECTROX SYSTEMS +1.408.252.1005 Silicon Valley, Ca From shawnb at ecst.csuchico.edu Fri Jan 1 17:22:12 1993 From: shawnb at ecst.csuchico.edu (S.E. Brown) Date: Fri, 1 Jan 93 17:22:12 PST Subject: Unsubscribe Message-ID: <9301020122.AA09373@toad.com> Please unsubscribe me to the list. I am on vacation and am not able to clear my mailbox on a regular basis. Thanks Shawn From 74076.1041 at CompuServe.COM Fri Jan 1 22:23:32 1993 From: 74076.1041 at CompuServe.COM (Hal) Date: Fri, 1 Jan 93 22:23:32 PST Subject: Remailer .sig suppressio Message-ID: <930102062025_74076.1041_DHJ24-1@CompuServe.COM> -----BEGIN PGP SIGNED MESSAGE----- From: edgar at spectrx.Saigon.COM (Edgar W. Swank) > Hugh Daniels said here on Dec 28: > > There are very good reasons to build remailers (and all mail > tools) to pass on all the bytes they can, trailing spaces and > .sigs included. > > Hugh doesn't say what these reasons are. They are not obvious to me, > so I must disagree. I've already stated what I think are good reasons > at least for remailers whose purpose is anonymity to remove automatic > sigs which are likley to destroy anonymity. > > I've said I would accept either a less ambiguous sig delimiter than > "--" or a remailer option to remove the sig (default) or leave it in. I'll just relate one story that happened to me today. I wanted to try an experiment in which I would use two non-cypherpunks remailers to set up a chained anonymous address. One is anon.penet.fi, which doesn't do any encryption, but which will allow you to specify an arbitrary destination address. The other is pax.tpa.com.au, which does PGP decryption (but you can't encrypt the remailer destination address like you can with our remailers). The Pax remailer lets you send them a PGP key which it saves. Then, any future messages to you are encrypted by the remailer using that key. That way message contents are always protected between Pax and you. I wanted to send Pax a key via the Penet remailer so that Pax wouldn't know who I really was. I tried this, and got a message back from Pax saying: Error: you didn't include a public key for us ! So we can't assign an alias or send you our public key. But I _had_ sent them a public key. After some head-scratching I figured out the answer. My public key had started with the string: "-----BEGIN PGP MESSAGE-----". But the Penet remailer strips sigs, which it considers to be any line starting with "--". It thought my PGP key was a signature! It had stripped it, so that Pax received only a blank message. I haven't thought of a way around this problem yet. Now, Edgar may take as the moral of the story that remailers should have smarter sig recognition. But I take the moral to be that munging mail messages may cause problems when people try to use it for something which you didn't anticipate. Hal -----BEGIN PGP SIGNATURE----- Version: 2.1 iQCVAgUBK0UJOqgTA69YIUw3AQHusQP/YuzvntMZ8XPpfLwwE5YElLjwfKGF0Q2e Cjk1PMmvtcn/bjSCB49lagOs0cEjm9Vt4gsEkTxwVlOya0+WOTeY/zzZAYlf3z4R 9QY7uRSyPQYJlPH6rosifEREMNWksRMCNMlISp8PDh1duJf3BvdwY3nyXk/PABpS LTp6NAFaFi4= =j0Wl -----END PGP SIGNATURE----- Distribution: CYPHERPUNKS >INTERNET:CYPHERPUNKS at TOAD.COM From gnu Fri Jan 1 23:10:10 1993 From: gnu (John Gilmore) Date: Fri, 1 Jan 93 23:10:10 PST Subject: Why mailers should not touch the body In-Reply-To: <1k4PwB7w165w@spectrx.saigon.com> Message-ID: <9301020710.AA15980@toad.com> > There are very good reasons to build remailers (and all mail > tools) to pass on all the bytes they can, trailing spaces and > .sigs included. > Hugh doesn't say what these reasons are. They are not obvious to me, A fair question (though not phrased as one). The reason to build mailers that faithfully pass on the entire body of the message, without any kind of alteration, is that it permits you to send ANY body through that mailer and rely on its faithful arrival at the destination. If there are no exceptions to the "ANY body" rule, programs can assume that the mail system is a black box (you put info in here, it comes out over there -- you don't care about its guts). If there are exceptions, then it becomes more complicated for programs (and humans!) to use the mail system to pass arbitrary information. One of the great things about adding checksums to messages is that mail and news paths which alter messages will be detected and corrected. I think that if PGP is told that something it signs is text, it should canonicalize line endings from the local storage format (whether newlines are CR, LF, or CRLF) and that's it. If a message passes through a system that expands all tabs to spaces, the messages is corrupted and its signature SHOULD not match. Systems which cannot represent strings of ASCII/ISO-Latin-1 text characters separated by line-endings (such as IBM mainframes which assume EBCDIC 80-column records padded out with trailing blanks) cannot be used "in the obvious way" to move signed textual email. The email will have to be encoded to pass through such non-transparent mail systems -- which will be sufficiently painful that eventually the mail systems will be fixed. It's already a pain that most Internet email won't handle a body consisting of arbitrary 8-bit bytes. If they fix that throughout 80% of the Internet, the other 20% will be forced to go along, or forced to receive an endless stream of corrupted binaries, uncheckable signatures, etc, from the fully capable part of the net. John Gilmore PS: I note that my own mailer, MH, inserts an extra newline at the beginning of many messages, and probably to the end as well. A proper body checksum would detect that and report an error. From gnu Fri Jan 1 23:13:51 1993 From: gnu (John Gilmore) Date: Fri, 1 Jan 93 23:13:51 PST Subject: Why remailers shouldn't suppress signatures In-Reply-To: <1k4PwB7w165w@spectrx.saigon.com> Message-ID: <9301020713.AA16058@toad.com> A further issue relates to stripping signatures. Let's be clear here. ==> IF YOU ARE PRESENTING YOURSELF AS MULTIPLE IDENTITIES, AND EXPECT THEM NOT TO BE LINKED, AVOIDING AUTOMATIC .SIGNATURE FILES IS THE LEAST OF YOUR WORRIES! <== Remove the file ".signature" from your home directory and you'll be done with *that* hassle. John PS: An extra credit note for the differently clued among us: Suppose you wanted to have a *different* signature for each of your multiple identities? I guess the remailers had better not strip off signatures, eh? From gnu Fri Jan 1 23:17:23 1993 From: gnu (John Gilmore) Date: Fri, 1 Jan 93 23:17:23 PST Subject: Initial Release of Privacy Enhanced Mail Message-ID: <9301020717.AA16145@toad.com> Forwarded from the PEM-DEV mailing list. Message-Id: <9212301932.AA07388 at TIS.COM> From: James M Galvin To: pem-dev at TIS.COM Cc: rsaref-users at rsa.com Subject: Initial Release of Privacy Enhanced Mail Date: Wed, 30 Dec 92 14:32:08 -0500 -----BEGIN PRIVACY-ENHANCED MESSAGE----- Proc-Type: 4,MIC-CLEAR Content-Domain: RFC822 Originator-ID-Asymmetric: MEYxCzAJBgNVBAYTAlVTMSQwIgYDVQQKExtUcnV zdGVkIEluZm9ybWF0aW9uIFN5c3RlbXMxETAPBgNVBAsTCEdsZW53b29k,02 MIC-Info: RSA-MD5,RSA,mHp3q4Av7Axil1BTXaaii+9NIdfm7doy00d/aw6TYEj y/eCt6CLpjbJzXHZt0kavc9ygC0eRNxOmAHiXmFC0Qg== Trusted Information Systems Incorporated (TIS), under DARPA sponsorship, in cooperation with RSA Data Security Incorporated (RSADSI), is preparing to release a reference implementation of Privacy Enhanced Mail (TIS/PEM) to the Internet community. TIS/PEM is a UNIX-based implementation that has been integrated with Rand MH 6.7.2 and is easily integrated into other mail user agents. TIS/PEM will be distributed in source form with RSADSI BSAFE object code. It will be widely available within the United States and Canada for non-commercial use (not for resale) with the stipulation that users join the Internet certification hierarchy. You are invited to participate in the testing of the initial release of TIS/PEM. Organizations and individuals must meet the following criteria to be accepted as a tester of the initial release of TIS/PEM. 1. You must be a United States or Canadian organization, or a United States or Canadian citizen residing in the United States or Canada. 2. You must have available the computing resources necessary to run the software and either be responsible for the administration of the resources or be able to delegate the responsibility. 3. You must have FTP access in order to be able to retrieve the software. With this release of TIS/PEM and an Internet certificate, you will be able to send and receive authenticated and confidential electronic mail messages, subject to the constraints of your local security policy. Attached is a field test agreement form. Please review it. If you agree to the terms and wish to participate, reply to this message and we will provide an ftp account for you to retrieve the file. The main features of this agreement are the following: o This test period will last a few months, probably until the end of March. When the test period is complete, we will release this code for general Internet distribution. o There is no charge for the use of this code, but it may only be used by you or within your own organization within the United States or Canada. It may not be given to others outside your organization or sold. (If you have a multinational organization, contact us for further discussion.) o When the system is released for regular use, users must obtain certificates through the regular certificate issuing channels and pay whatever fees are required. During the test period, there is no charge for certificates. When a regular certificate issuing mechanism is in place you will be informed. o We intend for this version of the code to be usable for real traffic. Although new versions of the software will be issued, the messages and certificates generated by this system and the databases maintained by this system should be compatible with future distributions. o We will undoubtedly issue changes, updates, bug fixes, etc. during this period. When we issue updates or new releases, you are obligated to install these changes. o You are free to drop out at any time. Thank you very much for your time. TIS/PEM Beta Test Site Agreement Trusted Information Systems (TIS) in cooperation with RSA Data Security Incorporated (RSADSI) is preparing to release TIS/PEM, a reference implementation of Privacy Enhanced Mail, to the Internet community. The purpose of beta testing is to evaluate TIS/PEM according to the criteria specified below. This agreement protects the interests of the beta testers, TIS, and RSADSI during the beta test period. By accepting a distribution of TIS/PEM during the beta test period, a beta test site agrees to the following: 1. You will acquire no ownership interest in any software, documentation, or other pieces of TIS/PEM as a result of their being distributed to you by Trusted Information Systems during the beta test period. Except as necessary to install and operate the software throughout your organization within the United States, TIS/PEM may not be distributed to others. (If you have a multinational organization, contact us for further discussion.) 2. TIS/PEM is to be used only with certificates issued under a Certification Authority which is itself registered under a permanent or temporary Policy Certification Authority (PCA). TIS is operating a PCA and will supply PCA services without charge during the beta test period. 3. At the conclusion of the beta test period, the beta test site may keep the software and continue to use it provided the site registers with a PCA and pays the appropriate fees. 4. Evaluations, comments, and suggestions about TIS/PEM should be communicated to Trusted Information Systems and may be communicated to other beta testers. 5. A technically competent systems administrator and programmer, someone capable of installing a software system comprising more than 50,000 lines of C source code, is expected to be assigned responsibility for TIS/PEM. All technical communication with a beta test site will be coordinated with this technical point of contact. 6. Upgrades will be installed and evaluated according to the criteria specified below in a timely fashion. Obsolete versions of the system must be taken out of service as quickly as possible. 7. If the site elects to drop out of beta testing, all software, documentation, and other pieces of TIS/PEM as may be distributed during the beta test period must be returned to Trusted Information Systems. During the beta test period, TIS agrees to the following: 1. One copy of all software, documentation, and other pieces of TIS/PEM as may be necessary to its correct and proper operation will be supplied to each beta test site for use during the beta test period. 2. Evaluations, comments, suggestions, bug fixes, and improvements of TIS/PEM will be acknowledged and incorporated into TIS/PEM according to an internal TIS review process. 3. During normal business hours, telephone and electronic mail technical support will be provided to the technical point of contact at each beta test site assigned responsibility for TIS/PEM. 4. One copy of upgrades to TIS/PEM incorporating evaluations, comments, suggestions, bug fixes, and improvements will be supplied to each beta test sites for use during the beta test period. 5. Beta test sites will be informed of the completion of beta testing and may be asked to return all software, documentation, and other pieces of TIS/PEM as may have been distributed during the beta test period. TIS/PEM Evaluation Criteria Beta test sites are requested to evaluation TIS/PEM according to the following criteria. The results of the evaluation must be returned to TIS in order for changes to be incorporated in the next release of TIS/PEM. There are 5 areas of particular interest, but any and all comments are hereby solicited. Beta test sites are asked to evaluate how well we achieve the objectives stated for each area. 1. Installability TIS/PEM is expected to operate on most BSD and SYS5 derived UNIXs. With respect to installability we want to achieve the following objectives: a. TIS/PEM should install smoothly on as many different "flavors" of UNIX as possible. b. TIS/PEM should install smoothly on as many different hardware platforms as possible. c. The installation process should be as simple as possible, but not simpler. Beta test sites are encouraged to port TIS/PEM to as many different software and hardware environments as possible. If possible, enhancements to get TIS/PEM to install smoothly on other versions of UNIX that are returned to TIS will be incorporated into a future distribution of TIS/PEM. 2. Usability TIS/PEM is provided with a command line oriented interface. In particular, it is integrated with the Rand MH Message Handling user agent. This interface was chosen because of the ease with which TIS/PEM could be integrated and because it is in the public domain. For each site, a certificate administrator must be designated who will be responsible for the administration of TIS/PEM. In particular, there is some site specific initialization to be completed. In addition, there is some initialization required to be executed by every user before they can make use of the TIS/PEM enhancements to MH. Depending on local conventions, users may be required to request the initialization of their certificate administrator or they may be able to execute the initialization individually. With respect to usability we want to achieve the following objectives: a. For users familiar with MH, the integration of TIS/PEM and MH should appear to be a natural extension of the MH model. b. The initialization process should be as simple as possible. Users will need to be familiar with MH or be prepared to learn about it. The MH source tree includes a tutorial of the minimal set of commands. In the future it is expected that others will contribute additional user interface software. Beta test sites are encouraged to enhance local user interfaces to include TIS/PEM. If possible, these enhancements will be included in future distributions of TIS/PEM. 3. Performance The performance of TIS/PEM is dominated by the processing time for certificates and cryptography. We have attempted to minimize the impact of these factors but we encourage beta test sites to investigate the operation of the system and identify bottlenecks for which they have suggestions for improvement. With respect to performance we want to achieve the following objective: o The design and model of TIS/PEM, and its integration with various applications, should be such that it will perform as well as it can. Obviously, performance is a subjective criteria. Different architectures will influence performance as much as the overall design of the system. Beta test sites are encouraged to empirically observe the performance of TIS/PEM under various operating conditions and report those results. 4. Interoperability With respect to interoperability we want to achieve the following objectives: a. TIS/PEM should interoperate with other implementations of PEM. b. Future versions of TIS/PEM should be backward compatible with previous versions. 5. Documentation On-line manual pages are provided for all TIS/PEM programs and those programs we have changed as a result of our integration with MH. In addition, we will provide an installation manual, an administrator's manual, and a user's manual. With respect to documentation we want to achieve the following objectives o All documentation should completely and accurately describe TIS/PEM. o All documentation should be easy to understand and easy to use. Beta test sites are encouraged to thoroughly review all documentation and provide feedback to be incorporated in future versions. -----END PRIVACY-ENHANCED MESSAGE----- From gnu Sat Jan 2 02:28:03 1993 From: gnu (John Gilmore) Date: Sat, 2 Jan 93 02:28:03 PST Subject: FYI: New report on public public-key infrastructure available Message-ID: <9301021028.AA22146@toad.com> ------- Forwarded Message To: John Gilmore Subject: FYI: New report on public public-key infrastructure available Date: Tue, 01 Dec 92 19:37:12 +0000 From: Mike Roe In Europe, an EC-funded project called PASSWORD (`Piloting Authentication and Security Services Within OSI Research and Development') aims to deploy an initial pilot service of privacy and integrity enhanced mail (and several more exotic applications) between academic and industrial organisations throughout Europe. The plans for how we intend to do certificate-based key management are described in a report entitled ``PASSWORD R2.5: Certification Authority Requirements''. Version 1.0 of this report is available by anonymous FTP from: ftp.cl.cam.ac.uk (128.232.0.56) reports/mrr-passwords.dvi.Z I realise that you're probably far too busy with other matters right now, but if you have any comments to make we'd be delighted to hear them. Yours sincerely, Michael Roe Cambridge University Computer Lab Computer Security Group ------- End of Forwarded Message John here. I have pulled this file down and translated it to PostScript (which I haven't tried to read yet). It's in cygnus.com:/pub/mrr-passwords.ps. The "DVI" format he provided is sort of like object files output by TeX; I have no idea why he didn't just provide us the TeX source, or the printable PostScript. John From jordan at imsi.com Sat Jan 2 12:19:21 1993 From: jordan at imsi.com (Jordan Hayes) Date: Sat, 2 Jan 93 12:19:21 PST Subject: Why mailers should not touch the body Message-ID: <9301021504.AA28104@IMSI.COM> All the more reason why the signature should be in the envelope (i.e. one of the headers in 822-land, in the p1? part for X.400, etc), not the body. Where did this convention of signing at the bottom come from anyway? /jordan From tribble at xanadu.com Sat Jan 2 19:57:51 1993 From: tribble at xanadu.com (E. Dean Tribble) Date: Sat, 2 Jan 93 19:57:51 PST Subject: remailer architecture (and signatures) Message-ID: <9301030327.AA13331@xanadu.xanadu.com> First a brief description of the new (read not-yet-available) remailer architecture, then what's this means to signatures, etc. The new remailer design comes from the realization that mail systems are missing configurability on both sides of message delivery: when you receive mail, and when you send it. Most of the 'remailer' is just the infrastructure to allow programmatic modification to messages in those two phases of delivery. With this infrastructure, remailers are trivial to construct. There will be an Incoming Mail Rewriting Agent (IMRA) and on Outgoing Mail Rewriting Agent. The behavior of these agents is specified by production/rewrite rules (match a pattern and take corresponding action, possibly recurring) on the mail message they are processing. The incoming agent is much like the existing framework for remailers. It is invoked through .forward and handles mail before it gets to yout mailbox. The outgoing agent is invoked when you send mail to do any rewriting necessary then (such as encryption, signture, etc.). Note that .signature handling is a grody hack in existing mail systems that directly implements a rather uninteresting piece of outgoing mail rewriting (I had fun writing that :-). It should just be junked for the more general scheme, which can support real crypto signatures (and .sig files, of course) for pseudonyms, outgoing encryption, automatic remailer routing (a header: 'Hops: 3' that would route the mail through 3 remailers to the eventual destination), etc. It of course won't be junked immediately, but the default behavior of remailers should certainly not be to strip anything that looks like sigs. Can we guarantee that all the tools that produce ascii encodings like uuencode will never produce the trivial pattern that the remailers thinks means 'signature.' For example, hypertalk comments start with '--', just like signatures. From 74076.1041 at CompuServe.COM Sat Jan 2 21:32:49 1993 From: 74076.1041 at CompuServe.COM (Hal) Date: Sat, 2 Jan 93 21:32:49 PST Subject: New remailers... Message-ID: <930103052525_74076.1041_DHJ38-1@CompuServe.COM> -----BEGIN PGP SIGNED MESSAGE----- From: tribble at xanadu.com (E. Dean Tribble) > First a brief description of the new (read not-yet-available) remailer > architecture, then what's this means to signatures, etc. > [...] This is neat. It sounds like the plan is to provide a convenient mail filtering tool which provides remailer capability as a SIDE EFFECT! What a great way to spread remailers! Not to mention, the same tools can provide automatic encryption and decryption - the long-sought integration of PGP (or RIPEM, etc.) with mail in an easy-to-use way. I'm really looking forward to seeing more about this idea. Speaking of integrating encryption into email, does anybody here have access to the announced beta-test of PEM from TIS? It would be interesting to see the documentation about how they've handled the user-interface issue. I gather that it only works with the MH package but presumably they've had to face some of the problems we're talking about here. Hal 74076.1041 at compuserve.com -----BEGIN PGP SIGNATURE----- Version: 2.1 iQCVAgUBK0ZOFqgTA69YIUw3AQHQkwP/VjXxDvQWqpx+owL4re1YVtMTobydqcD4 myGTAyT9VVmB5R/DEQdatwyc+mXuvGAx7YTEX+o3MPuZE/5VXFG+FgZZb21PZqWS UFae9YFY1AY6RHJi0APM5G5S8x6LHJJXtKo1wFgeKd8BjUeHS1l73qFpKeNzdN3g SCzCS/BGslE= =xw7Q -----END PGP SIGNATURE----- Distribution: CYPHERPUNKS >INTERNET:CYPHERPUNKS at TOAD.COM From jordan at imsi.com Sun Jan 3 08:08:38 1993 From: jordan at imsi.com (Jordan Hayes) Date: Sun, 3 Jan 93 08:08:38 PST Subject: Why mailers should not touch the body Message-ID: <9301031512.AA05222@IMSI.COM> I got lots of mail telling me that signing messages in the body of the message came about because "various mailers" munge header lines. Now it's true that for gateway processing, To: and From: lines need to get translated, but I've never seen a mailer change or remove a header that doesn't have to do with addressing before. Can someone provide an example? My claim is that a signature belongs on the envelope and not in the body. ----- To be clear, I'm talking about (e.g.) a PGP signature, not a .signature with a cute saying in it. /jordan From ghsvax!hal at uunet.UU.NET Sun Jan 3 17:28:45 1993 From: ghsvax!hal at uunet.UU.NET (Hal Finney) Date: Sun, 3 Jan 93 17:28:45 PST Subject: Anonymous discussion on Pax Message-ID: <9301040105.AA26178@nano.noname> There has been some discussion on the Pax mailing list (mail to anon.subscribe at pax.tpa.com.au to subscribe) about anonymous posting and mail. Here is an excerpt from one posting that I thought was interesting. From: mjr at netcom.com (Matthew Rapaport) > >anonymous posting is just another noise source. Very little is riding > >on who "wins" arguments on Usenet. > > True, so I'll try something more serious. Suppose you were trying to > convince some small group of vulnerable people to commit some crime, or > aid in one directly or indirectly (perhaps for political reasons). > He/she/they might resist one provacateur, but all *10* of *you* assure > him/her/them that you've all done it (for which reason you must > naturally hide your identities), it must be done, etc. > > ******* > > >The idea of positive reputations is designed to help with the problem > >that anonymity could lower the quality of postings by reducing > >accountability. > > The WELL tried a completely anonymous conference once. It quickly became > a mire of flaming viciousness, lying, trickery and backstabbing. It was > unbelievable to see how fast it got nasty, and in an otherwise > reasonably well behaved user population. Does anyone here have information on this experiment on the WELL? That sounds like an interesting data point. Presumably they did not try to press on with some kind of rating or reputation system. Hal 74076.1041 at compuserve.com From rchilder at us.oracle.com Sun Jan 3 20:28:18 1993 From: rchilder at us.oracle.com (Richard Childers) Date: Sun, 3 Jan 93 20:28:18 PST Subject: A solution remailer signature suppression Message-ID: <9301040426.AA10757@rchilder.us.oracle.com> "Hugh Daniels said here on Dec 28: There are very good reasons to build remailers (and all mail tools) to pass on all the bytes they can, trailing spaces and .sigs included." "Hugh doesn't say what these reasons are. They are not obvious to me, so I must disagree. I've already stated what I think are good reasons at least for remailers whose purpose is anonymity to remove automatic sigs which are likley to destroy anonymity." I can think of a few ... (1) it's a bad precedent to rewrite contents. one program's apparent signature could be another program's data or instruction. (2) it is unnecessary complexity and falls under KISS, IE, 'Keep It Simple, Simon'. (-: (3) It is less robust and portable as a result of having this additional complexity. ( I use 'portable' not in the conventional compiler- specific manner, but more to apply to a given application's usability for future, yet-to-be- known applications, IE, flexibility. ) In this respect it fails to conform to requirements for a good software 'tool'. It is the user's job to hide his or her identity, but it should not be the programmer's responsibility to anticipate the user's failure to think at all. Someone who uses these tools without understanding the principles upon which they are founded - such as people whom accept keys from individuals whom are only electronically known - will quickly founder upon their own, um, state of stupor, and one should not undertake to protect them from this, as what you are pro- -tecting them from, in reality, is the opportunity to learn from their mistakes. "I've said I would accept either a less ambiguous sig delimiter than "--" or a remailer option to remove the sig (default) or leave it in." Until there is a convention, IE, an RFC or ANSI standard for signatures, it would be unwise to build in any assumption. I just realized an excellent example. For years, I've been signing myself ... -- richard ... such that everything after my name - IE, contact data - would be trimmed off. Not well thought out ... I have actually seen this in the case of a few mail servers that rewrite contents ( such as the elec- -tric vehicles digest, EV-L ). -- richard ===== -- richard childers rchilder at us.oracle.com 1 415 506 2411 oracle data center -- unix systems & network administration "If Life is a drama, then, surely, the hardest parts go to the most skillful." From julf at penet.FI Mon Jan 4 07:39:52 1993 From: julf at penet.FI (Johan Helsingius) Date: Mon, 4 Jan 93 07:39:52 PST Subject: A solution remailer signature suppression In-Reply-To: <9301040426.AA10757@rchilder.us.oracle.com> Message-ID: <9301041652.aa07015@penet.penet.FI> Richard Childers writes: > It is the user's job to hide his or her identity, but it should not > be the programmer's responsibility to anticipate the user's failure > to think at all. Someone who uses these tools without understanding > the principles upon which they are founded - such as people whom > accept keys from individuals whom are only electronically known - > will quickly founder upon their own, um, state of stupor, and one > should not undertake to protect them from this, as what you are pro- > -tecting them from, in reality, is the opportunity to learn from > their mistakes. Well, in principle I agree. And if I would start from a clean slate, I would *gladly* leave out the sig stripper. But people in groups such as alt.sexual.abuse.recovery have come to rely on the behaviour of previous servers, and are *not* very computer- or e-mail-literate. Julf (admin at anon.penet.fi) From ASTMWILL%STETSON.bitnet at CUNYVM.CUNY.EDU Mon Jan 4 09:51:02 1993 From: ASTMWILL%STETSON.bitnet at CUNYVM.CUNY.EDU (Matt Willis) Date: Mon, 4 Jan 93 09:51:02 PST Subject: Acceptance of Keys Message-ID: <01GT4DS9PKZ40000QP@stetson.bitnet> Richard Childers writes: > >> It is the user's job to hide his or her identity, but it should not >> be the programmer's responsibility to anticipate the user's failure >> to think at all. Someone who uses these tools without understanding >> the principles upon which they are founded - such as people whom >> accept keys from individuals whom are only electronically known - >> will quickly founder upon their own, um, state of stupor, and one >> should not undertake to protect them from this, as what you are pro- >> -tecting them from, in reality, is the opportunity to learn from >> their mistakes. As wary as I am of expressing my ignorance, I'll give it a shot... I'm new to the Cypherpunks list and I'm just curious, is it going against the principles of PGP to "accept keys from individuals whom are only electronically known"? (if so, I guess I'm in a state of stupor) Most of my dealings on the internet are internet-exclusive, that is, I never meet the people with whom I communicate. With the exception of some locals, computer social life in FL, USA is pretty non-existant. I wish my communications to be secure and I believe that PGP is the best way and I will never have the opportunity to meet the people I talk to in Kansas or in New York (both places, I hope I never visit). If meat-relations are the only secure way I'm supposed to communicate, then I guess I'll have to use carrier pigeons. :) DISCLAIMER: Of course, I could be taking this TOTALLY out of context, and in that case this message should read: Hey, I really like this list... It's intellectually stimulating and a clearly positive influence on my life. How's the weather in Europe? I'm not trying to be argumentative, I just have serious questions about the keeping of public keys... here's another one... couldn't we assign one at birth... it'd be better than a social security number (dunno what you use in Europe), but a whole lot harder to remember... ALSO: We Mac users are wondering when MacPGP 2.1 will be out? Anyone have any contact info? thanks for reading my words. +-------Matt-Willis--------------------------------+ | Matt Willis ASTMWILL at STETSON.BITNET | elsewhere: | Matt Willis Head of the Underground | mwill at mindvox.phantom.com | Matt Willis Robotech PBM List | +-------Matt-Willis--------------------------------+ "Absolutely alone in awareness of the mechanism." -Agrippa by WG From hughes at toad.com Mon Jan 4 12:01:08 1993 From: hughes at toad.com (Eric Hughes) Date: Mon, 4 Jan 93 12:01:08 PST Subject: The Need for Positive Repuations Message-ID: <9301031713.AA21649@toad.com> --------------------------- Original Message --------------------------- You sent this to cypherpunks-request and not to cypherpunks. Eric ----------------------------------------------------------------------------- Return-Path: <@YaleVM.YCC.Yale.Edu:KL62 at MARISTB.BITNET> Date: Fri, 18 Dec 92 15:18:35 EST From: "Ryan, Edmund J" To: Subject: Re: The Need for Positive Repuations In-Reply-To: In reply to your message of FRI 18 DEC 1992 11:45:55 EST > Indeed, in the long run, when there are billions of people in the nets, > even UseNet newsgroups devoted to people who use musical instruments as > sex toys would have thousands of posts a day because given billions of > possible subscribers, finding a few tens of thousands with a particularly > obscure interest wouldn't be hard. Thus, in the long run, the nets will move > to "closed" newsgroups and mailing lists in which to be a subscriber one > will have to be explicitly subscribed to a list and will only be able to > read with one's private key and post by digitally signing messages. In such > an environment, anonymous abusers will simply be incapable of annoying people. Well there won't be a complete movement in that direction. The set up of the list may differ. Some lists may be open to all to read but open only to subscribers to post. Some lists may be the other way around. (Can't think of an example, but there may be one out there.) By the way, I've never really seen too many abusive postings on the Usenet groups I frequent.It doesn't seem to be a problem. Just my opinion. > A weak version of this exists already in the Extropians mailing list, which > considers itself to be a closed list. The list is governed by a privately > produced legal code (its in some ways a test of anarchocapitalist legal theory > and since the adoption of the code, we've had a reduction of flaming by > a large factor even though we've seen a three fold increase in list size. > The content is improving because people know that sanctions will be applied > for flaming and that they can actually be kicked off the list, and that being > kicked off is meaningful. In the long run, all serious discussion groups > will likely evolve in this direction, with the lists being closed to explicit > subscribers and with meaningful sanctions like ostracism being applied to > people that behave in an antisocial manner. Such lists have little reason > to fear people hiding behind cloaks of anonymity. With digital signatures, > even the anonymous can develop meaningful reputations and can be sanctioned > for failing to live up to those reputations. > > Perry Again, there will always be the fun of watching people flame. Virtually, Edmund J. Ryan ------------------------------------------------------------------------ - Edmund J. Ryan C.I.S. Major Extropian - - KL62 at MARISTB C.S. Minor Libertarian - - "Insert your snappy quote of the day." - ------------------------------------------------------------------------ ------------------------------------------------------------------------ - Edmund J. Ryan Major: Computer Information Systems - - KL62 at MARISTB Minor: Computer Science/Business - - Marist College Political philosophy: Libertarian - - Poughkeepsie, NY Extropian - - - - "Replace taxpayers with shareholders, - - regulators with customers: privatize!" - ------------------------------------------------------------------------ From barrus at tree.egr.uh.edu Mon Jan 4 12:04:01 1993 From: barrus at tree.egr.uh.edu (Karl L. Barrus) Date: Mon, 4 Jan 93 12:04:01 PST Subject: Acceptance of Keys In-Reply-To: <01GT4DS9PKZ40000QP@stetson.bitnet> Message-ID: <9301042003.AA13849@tree.egr.uh.edu> Matt, You posted some very good questions. The reason why it is "unacceptable" to accept keys electronically is that you may be vulnerable to spoofing. Okay, in reality, you have to realize that attacking cryptographic protocols is a paranoid view of things, and that you may not be attacked, but... if you send your public key to somebody, it could be possible for someone to eavesdrop, grab your key, substitute their own, and send that one along. Then when someone responds to "you", the eavesdropper could read the message, re-encrypt it with the public key they stole, and send it along to you. Then, you don't even know you are the victim of eavesdropping. Anyway, it all boils down to validating the keys you receive. Which makes it tough unless you can meet people face to face. However, the latest version of pgp contains an option which computes the md5 hash of your public key - which allows you to call someone, and read each others hashes, thus completing the verification over the phone. Of course, now you have to worry about receiving their correct phone number... :-) /-----------------------------------\ | Karl L. Barrus | | barrus at tree.egr.uh.edu (NeXTMail) | | elee9sf at menudo.uh.edu | \-----------------------------------/ From edgar at spectrx.Saigon.COM Mon Jan 4 17:02:47 1993 From: edgar at spectrx.Saigon.COM (Edgar W. Swank) Date: Mon, 4 Jan 93 17:02:47 PST Subject: Return addresses Message-ID: Hal Finney wrote here on Dec 30: Chaum's idea was that the message contents would be encrypted at each step, as Eric suggests, but Chaum would have the encryption key be part of the anonymous address, created by the same person who made the anonymous address. The idea would be, after decrypting the incoming message, the remailer would see something like: Anon-To: Encrypt-With: It would then encrypt the message "contents" (but not the "envelope", as Eric points out) using the specified key. When the owner of the anonymous address received the message, he would decrypt it using the chain of "Encrypt-With" keys that he put into the anonymous address. I'd like to point out that the "-ca" function of PGP could be used to perform this function if Encrypt-With: specified a PGP pass-phrase rather than a direct key. I'd also like to suggest that the message- body to be encrypted require heading and trailing delimiters such as: -----BEGIN MESSAGE BODY----- -----END MESSAGE BODY----- Note delimiters would not be part of message body and would not be encrypted. -- edgar at spectrx.saigon.com (Edgar W. Swank) SPECTROX SYSTEMS +1.408.252.1005 Silicon Valley, Ca From 74076.1041 at CompuServe.COM Mon Jan 4 23:41:21 1993 From: 74076.1041 at CompuServe.COM (Hal) Date: Mon, 4 Jan 93 23:41:21 PST Subject: Remail addresses... Message-ID: <930105070855_74076.1041_DHJ43-1@CompuServe.COM> -----BEGIN PGP SIGNED MESSAGE----- From: edgar at spectrx.Saigon.COM (Edgar W. Swank) > > Anon-To: > Encrypt-With: > > I'd like to point out that the "-ca" function of PGP could be used > to perform this function if Encrypt-With: specified a PGP pass-phrase > rather than a direct key. This sounds like a good idea. The user would have to have some scripts to decrypt incoming anonymous-address messages using this pass phrase (or some sequence of pass phrases if more than one remailer was used for the anonymous address). > I'd also like to suggest that the message- > body to be encrypted require heading and trailing delimiters such as: > > -----BEGIN MESSAGE BODY----- > -----END MESSAGE BODY----- > > Note delimiters would not be part of message body and would not > be encrypted. These anonymous addresses do need a distinction between the "message address" (or "envelope") and the message body. The anonymous address gets decrypted at each step, and the message body gets encrypted at each step using the scheme above. But Eric Hughes pointed out that we already have such a distinction in the RFC822 message headers vs body. We should use that existing structure rather than try to create our own. That means that anonymous addresses should be designed to fit into mail headers. Unfortunately many mail agents make this difficult or inconvenient right now, but perhaps that is an area where we could make some improvements. In this model, we would not need message body delimiters, since mail already has its message body delimited distinct from its headers. If we do process the message body with encryption at each stage, I do have an idea which could be useful. If the body which is being encrypted is already in the format of an ASCII-encoded message using the standard RFC822 encryption used in PGP, RIPEM and PEM, then rather than just encrypting it it could be de-ASCII'd, then encrypted, then re-ASCII'd. This would keep it from increasing in size by a factor of 4/3 at each encryption step. Hal -----BEGIN PGP SIGNATURE----- Version: 2.1 iQCVAgUBK0kHvKgTA69YIUw3AQHBuwP/ekp1feh06tLHwxws49DE3wVxnu/36Yg7 oW2l43n3llgRJC+r/KYJ2+5LTG0/f1Ib/R8c4qxUJzZeCj7zABSdJ6KSwIlwmfP6 Djz0vOBnife6CvhQRi+T/8NuFqFIzlxO1vK+7tG9KWshxP+7AMayGOLuY0pOTREX 7brcJHnn7Mg= =9Uss -----END PGP SIGNATURE----- Distribution: CYPHERPUNKS >INTERNET:CYPHERPUNKS at TOAD.COM From eric at parallax.com Tue Jan 5 01:01:56 1993 From: eric at parallax.com (Eric Messick) Date: Tue, 5 Jan 93 01:01:56 PST Subject: RFC-822 header processing in perl Message-ID: <9301050049.AA07963@parallax.com> I've written a perl script to parse RFC-822 style headers. It was a good deal harder than I had thought it would be. Since it's over 300 lines (with comments) I won't post it, but will mail it to anyone who wants to play with it. It has the following features: Doesn't touch anything unless you ask it to. Leaves the ordering and whitespace/folding of header lines unchanged. Allows you to replace any header line (which appears only once) with an arbitrary value, which is appropriatly folded on output. Allows you to delete any header line, or add a header line to the end of the header. These are special cases of replacing a header line. Allows you to access the value (stuff after the :) of any header line. Given a list of addresses, returns an array of canonicalized addresses. The last item is the hard part. It correctly parses the sample addresses in the RFC-822 paper, as well as some really gnarly looking junk that I threw at it. It correctly handles the various types of quoted strings, and backslash quoting, not splitting addresses at quoted commas. It removes nested comments from addresses. It deletes the group name from a list of addresses without screwing up quoted colons. It should be useful as a first step in alias processing. That's what I'll be adding next, when I figure out exactly how I want to do it. -- eric messick eric at toad.com From pbreton at cs.umb.edu Tue Jan 5 07:26:50 1993 From: pbreton at cs.umb.edu (Peter Breton) Date: Tue, 5 Jan 93 07:26:50 PST Subject: purloined letter In-Reply-To: <9301050049.AA07963@parallax.com> Message-ID: Hi, I'm fairly new here and not sure if this topic has come up before, but I'll offer it anyway: In using encrypted communications, how does one avoid the problem of calling attention to the message BECAUSE it is encrypted? "If he went to the trouble of coding it, there MUST be something in there!!" Granted that if everyone begins encrypting, this problem will vanish... are there practical solutions in the meantime? (eg, Codes that look like plaintext?) Peter From ASTMWILL%STETSON.bitnet at CUNYVM.CUNY.EDU Tue Jan 5 08:26:21 1993 From: ASTMWILL%STETSON.bitnet at CUNYVM.CUNY.EDU (Matt Willis) Date: Tue, 5 Jan 93 08:26:21 PST Subject: Hiding PGP code Message-ID: <01GT5P4IHYCG000224@stetson.bitnet> Peter Breton writes: > In using encrypted communications, how does one avoid the problem of >calling attention to the message BECAUSE it is encrypted? "If he went to >the trouble of coding it, there MUST be something in there!!" Granted that >if everyone begins encrypting, this problem will vanish... are there >practical solutions in the meantime? (eg, Codes that look like plaintext?) Here's an interesting solution... You can program a message filter to add extract letters to each PGP character to make it a word. I'm sure you could find any database of words and have it randomly make first letters... it'd be pretty simple... and then the receiver would just take every letter followed by a space... and if you wanted to be ultra-sneaky (who, us) you could have null words that change conditions in the letter... like switching to the second letter in the word, or skipping the next word altogether... but what to do with no-letter PGP codes... ok, the first TWO letters of the word indicate a character... sort of like a byte... hey, I think I might just write this sucker... Code will follow! carpe crypto +-------Matt-Willis--------------------------------+ | Matt Willis ASTMWILL at STETSON.BITNET | elsewhere: | Matt Willis Head of the Underground | mwill at mindvox.phantom.com | Matt Willis Robotech PBM List | +-------Matt-Willis--------------------------------+ "Absolutely alone in awareness of the mechanism." -Agrippa by WG From ASTMWILL%STETSON.bitnet at CUNYVM.CUNY.EDU Tue Jan 5 08:44:58 1993 From: ASTMWILL%STETSON.bitnet at CUNYVM.CUNY.EDU (Matt Willis) Date: Tue, 5 Jan 93 08:44:58 PST Subject: Acceptance of Keys Message-ID: <01GT5PQFUPTG000224@stetson.bitnet> From: "Karl L. Barrus" writes: > You posted some very good questions. The reason why it is >"unacceptable" to accept keys electronically is that you may be >vulnerable to spoofing. Okay, in reality, you have to realize that >attacking cryptographic protocols is a paranoid view of things, and >that you may not be attacked, but... if you send your public key to >somebody, it could be possible for someone to eavesdrop, grab your >key, substitute their own, and send that one along. Then when someone >responds to "you", the eavesdropper could read the message, re-encrypt >it with the public key they stole, and send it along to you. Then, >you don't even know you are the victim of eavesdropping. But we both call the same system (at least the people I x-change keys with) usually mindvox or a private system with a respected name... and in the case of Minvox, we do a DCC on IRC... straight person-to-person... to be eavesdropping... one, they'd have to tap my line, heavy equipment needed to tap a 16.8k HST v.42bis connection, seeing as I pretty much max out a phone line and HST's are really picky... or two, they'd intercept a DCC on the IRC at berkeley... but that's a 57.6k connection... however, that does seem possible... does anyone have any suggestions on how to make e-transfers of keys more secure, because, besides snail-mail (which would please the feds a lot) I have no other way of getting my key to them... > Anyway, it all boils down to validating the keys you receive. >Which makes it tough unless you can meet people face to face. >However, the latest version of pgp contains an option which computes >the md5 hash of your public key - which allows you to call someone, >and read each others hashes, thus completing the verification over the >phone. Of course, now you have to worry about receiving their correct >phone number... :-) geez, I didn't know it was this complicated... if someone screws with the key, it just doesn't decode, correct? nowadays, with MNP and ARQ-retries and all of our little .bis buddies, not to mention the CRC's in transfer protos, wouldn't that make an error in transfer EXTREMELY remote... so the only other way'd be tampering and even then it just wouldn't decode, so what... you get the key again... but I oversimplify the situation, I guess... Oh, and I know this is going to make me sound like a complete idiot in front of my peers, but I've always did straight tranfers of keys... how do you put ascii keys into your keyring? I can't seem to make MacPGP do it... sniffle... and if ihe reason I can't decode the key is due to an error in transmission, forget this entire message... +-------Matt-Willis--------------------------------+ | Matt Willis ASTMWILL at STETSON.BITNET | elsewhere: | Matt Willis Head of the Underground | mwill at mindvox.phantom.com | Matt Willis Robotech PBM List | +-------Matt-Willis--------------------------------+ "Absolutely alone in awareness of the mechanism." -Agrippa by WG From eab at msc.edu Tue Jan 5 09:21:50 1993 From: eab at msc.edu (Edward Bertsch) Date: Tue, 5 Jan 93 09:21:50 PST Subject: purloined letter In-Reply-To: Message-ID: <9301051721.AA16197@uh.msc.edu> ->calling attention to the message BECAUSE it is encrypted? "If he went to ->the trouble of coding it, there MUST be something in there!!" Granted that ->if everyone begins encrypting, this problem will vanish... are there ->practical solutions in the meantime? (eg, Codes that look like plaintext?) a good point indeed. I know of no software that works the way it seems you would like. The best would be encryption software that makes your 'secret' message look like the kind of message that you would actually be sending to the recipient. Some kind of message that (when read by a human) makes sense, and seems innocuous. This sounds like a VERY difficult problem, and one that is not likely to be solved any time soon (in the sense of having this be done 100% by software). Another option would be to have the message fit the letter-frequency, letter-pair frequency, etc... that 'normal' messages have. The idea here is that messages may be scanned for unusual (i.e. non-english text) properties in this regard, and then scanned further by humans and/or computers in the order of their 'interestingness'. So to defeat this kind of scanning, your 'secret' message should 'appear' to be a 'ordinary' message. -- Edward A. Bertsch (eab at msc.edu) Minnesota Supercomputer Center, Inc. Operations/User Services 1200 Washington Avenue South (612) 626-1888 work Minneapolis, Minnesota 55415 (612) 645-0168 voice mail From uri at watson.ibm.com Tue Jan 5 09:55:48 1993 From: uri at watson.ibm.com (uri at watson.ibm.com) Date: Tue, 5 Jan 93 09:55:48 PST Subject: purloined letter In-Reply-To: <9301051721.AA16197@uh.msc.edu> Message-ID: <9301051754.AA20090@buoy.watson.ibm.com> Edward Bertsch says: > > ->calling attention to the message BECAUSE it is encrypted? "If he went to > ->the trouble of coding it, there MUST be something in there!!" Granted that > ->if everyone begins encrypting, this problem will vanish... are there > ->practical solutions in the meantime? (eg, Codes that look like plaintext?) Well, my opinion is - the only way to go is to SHORTEN the transition period. Switch to all-encrypted e-mail ASAP. > a good point indeed. I know of no software that works the way it seems > you would like. > ............................................This sounds like a VERY > difficult problem, and one that is not likely to be solved any time soon > (in the sense of having this be done 100% by software). Agreed. Theoretically possible - practically infeasible. Plus imagine message size... Plus it depends on how clever a scanner-program can be - if eavesdroppers have enough CPU power, they could check for the "validity" as well, i.e. right word sequences, not just amount... > Another option would be to have the message fit the letter-frequency, > letter-pair frequency, etc... that 'normal' messages have. The idea > here is that messages may be scanned for unusual (i.e. non-english text) > properties in this regard, and then scanned further by humans and/or > computers in the order of their 'interestingness'. So to defeat this > kind of scanning, your 'secret' message should 'appear' to be a 'ordinary' > message. Again, it will, or will not work, depending on how smart the scanning program is. There's no reason why it can't detect, that your letters don't form valid English (German, Swedish, Arabic, whatever) words, *or* the words don't form valid sentences... I repeat - the surest way is to get over the hump sooner. -- Regards, Uri uri at watson.ibm.com scifi!angmar!uri N2RIU ----------- >From cypherpunks-request Tue Jan 5 10:49:28 1993 From tcmay at netcom.com Tue Jan 5 09:56:19 1993 From: tcmay at netcom.com (Timothy C. May) Date: Tue, 5 Jan 93 09:56:19 PST Subject: purloined letter In-Reply-To: Message-ID: <9301051753.AA25648@netcom.netcom.com> Peter Breton writes: > In using encrypted communications, how does one avoid the problem of > calling attention to the message BECAUSE it is encrypted? "If he went to > the trouble of coding it, there MUST be something in there!!" Granted that > if everyone begins encrypting, this problem will vanish... are there > practical solutions in the meantime? (eg, Codes that look like plaintext?) The study of how to hide the _existence_ of an encrypted message is called _steganography_. Messages have traditionally been: -placed on microdots and hidden inside letters, under stamps, etc. -transformed into innocuous-looking messages ("Hello, Peter! Things are going very well on this January morn.")...typically used with book codes -deposited in physical "dead drops," such as in tin cans by the side of the road, in the branches of trees, etc. (all agreed-upon in advance, of course) The cypherspace domain offers new degrees of freedom for hiding such messages: -messages may be packed into the "least signficant bits" (LSBs) of digital images, GIFs and TIFFs, sound samples, etc. As these bits are at the "noise floor" for modern recording technology, message bits can be easily made indistinguishable from "real" bits. A simple GIF image, such as those posted worldwide in the various "pictures" groups, can easily hold 50K bytes or more just in the LSBs (of each of the colors). A standard 2-hour digital audio tape (DAT) can carry 80 M bytes in the LSBs alone! (Imagine the Customs Department trying to stop someone from carrying out the blueprints to the Aurora spy plane packed into the LSBs of their favorite tape!) -similar systems can be used to pack bits into the "ragged right" margins of messages like this one, where the precise word spacing carries some bits. Not very many, of course. And the spacing is susceptable to munging. -raw data, such as weather reports and sports scores, can be used. Used since the dawn of espionage, and featured as a plot device in the French thriller "Soft War," this method is certainly still possible to use. As the amount of bits moving around increases dramatically, so, too, will the avenues for sending encrypted messages. -Tim May -- .......................................................................... Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay at netcom.com | anonymous networks, digital pseudonyms, zero 408-688-5409 | knowledge, reputations, information markets, W.A.S.T.E.: Aptos, CA | black markets, collapse of governments. Higher Power: 2^756839 | PGP Public Key: by arrangement. From karn at qualcomm.com Tue Jan 5 10:03:47 1993 From: karn at qualcomm.com (Phil Karn) Date: Tue, 5 Jan 93 10:03:47 PST Subject: purloined letter Message-ID: <9301051802.AA17738@servo> A couple of years ago somebody posted some clever programs to sci.crypt that hid arbitrary (cipher)text in seemingly innocuous "plaintext". You had two options: plaintext that looked like a running commentary on a baseball game (with the ciphertext encoded in the choices of names of players at bat, the sequence of balls and strikes, etc) or plaintext that looked like the writings of a particular legal scholar (I think). I don't remember his name, but he was chosen because Senator Joseph Biden of Delaware plagairized his works during law school, and Biden had recently introduced S.266 with the now-infamous "resolution" against cryptography. A nice touch. :-) Another approach to this problem is this: if you can't make the needles inconspicuous by themselves, generate some big haystacks to hide them in. I.e., write a program that produces bogus PGP "messages" and execute it frequently to produce background traffic. I wrote a first-order bogus PGP message generator and posted it to sci.crypt two weeks ago. I say "first order" because it looks like a PGP message to the naked eye, but is clearly invalid when fed to PGP - I didn't bother generating correct checksums on the ciphertext. The ideal bogus message generator would produce a message indistinguishable from a real PGP message encrypted with an unknown public key, or perhaps with a known public key chosen at random. Anybody want to write this? Phil From mch at sqwest.wimsey.bc.ca Tue Jan 5 10:27:47 1993 From: mch at sqwest.wimsey.bc.ca (Mark C. Henderson) Date: Tue, 5 Jan 93 10:27:47 PST Subject: purloined letter In-Reply-To: Message-ID: <9301051019.ZM15222@west.sq.com> On Jan 5, 10:19, Peter Breton wrote: > Subject: purloined letter > > Hi, > > I'm fairly new here and not sure if this topic has come up before, but > I'll offer it anyway: > > In using encrypted communications, how does one avoid the problem of > calling attention to the message BECAUSE it is encrypted? "If he went to > the trouble of coding it, there MUST be something in there!!" Granted that > if everyone begins encrypting, this problem will vanish... are there > practical solutions in the meantime? (eg, Codes that look like plaintext?) The best way to prevent this type of traffic analysis is to encrypt everything. As a second best, encrypt all correspondence with a specific person. Mark -- Mark Henderson, SoftQuad Inc, 108-10070 King George Hwy, Surrey, B.C. V3T 2W4 Internet: markh at wimsey.bc.ca, mch at sqwest.wimsey.bc.ca, mch at holonet.net UUCP: {van-bc,sq}!sqwest!mch Telephone: +1 604 585 8394 Fax: +1 604 585 1926 RIPEM public key available by Email/finger mch at holonet.net/keyserver From wcs at anchor.ho.att.com Tue Jan 5 10:48:32 1993 From: wcs at anchor.ho.att.com (Bill_StewartHOY0021305) Date: Tue, 5 Jan 93 10:48:32 PST Subject: purloined letter Message-ID: <9301051843.AA15785@anchor.ho.att.com> The hiding-data-in-bogus-text system that Phil referred to is Peter Wayner's Mimic functions, which let you represent data using a Huffman code or context-free-grammar set of productions that matches innocuous text. The examples in the paper used baseball game radio narration (hiding a message "Paul is dead" :-) and political speeches by Mr. Neil Kinnock, the raving Labour Party honcho whose speeches were plagiarized by Joe Biden. (Biden, btw, was a nice guy when he was elected to the Senate at age just-under-30, but he's apparently gone Big Brotherish as he's aged. I'm not bothered by one politician borrowing another's speeches, but stooping to Neil Kinnock's syrupy ranting is a bit much :-) The papers on the mimic functions are in ftp.cs.cornell.ecu, under /pub/wayner/Mimic. There are also a couple of papers on building a highly parallel des-cracker out of content-addressable memory, Until encryption becomes widely used, if yuo want to hide encrypted data, mimic functions or low-bits-of-gifs are good ways to go. Bill Stewart From whitaker at eternity.demon.co.uk Tue Jan 5 12:08:24 1993 From: whitaker at eternity.demon.co.uk (Russell E. Whitaker) Date: Tue, 5 Jan 93 12:08:24 PST Subject: MEETING: Cypherpunks UK (2nd; last announcement) Message-ID: <8326@eternity.demon.co.uk> -----BEGIN PGP SIGNED MESSAGE----- 2nd Meeting, Cypherpunks UK - --------------------------- Chris Tame, of FOREST and the Libertarian Alliance, has generously offered the use of the meeting room at his offices for our gathering, Sunday, 10 January 1993, from 1300 onwards, at: FOREST 4th Floor 2 Grosvenor Gardens London SW1W 0DH 071-823-6550 This is just around the corner from Victoria Station, at the end of the mansion block near Hobart Place. There's a dark green cabbie shelter across the street from the entrance, and some British Telecom payphones. Can't miss it, really. However, if you have trouble, call the telephone number above, or call my pager, on 081-812-2661. If it helps, we're in the direction of Buckingham Palace, which is (very) partially visible from our windows. If you wish to attend, you should bring a 3.5" DOS-formatted diskette (sorry! My UN*X machine is an Intergraph workstation, and I can't use it for crypto) with a copy of your PGP 2.0+ public key. I'll sign it there. Mac users: if you don't have Apple File Exchange (what!?), I'll be extra nice and take your keys anyway ( ;-)) for AFE conversion on my IIcx. Not to fear. It might not be a bad idea to copy your public key on each of several diskettes, so you've got a copy to distribute to each of the others. Don't trust me to copy *your* key to others! As a matter of fact, as there are plenty of power points in the meeting room, you should bring your laptop, and/or a desktop PC: when someone hands you a disk-with-key, you can sign her key, and hand her back her diskette, with your own pubkey added. [Note to the novice: don't hand another person your secret key... the one named secring.pgp. Read the documentation.] This should be a lively meeting. Among the topics likely to be discussed are: o The proliferation of public key cryptography in the U.K. o The local development of anonymous remailers and a proposed automated public key repository at Demon Internet Systems o Electronic networking/email security for the novice o Pro-active proliferation of PGP 2.1+ to interesting European, African, and Asian sites - ftp placement - BBS distribution - sneakernet across borders o The use of HPACK in securing local file installations .. and much more! Mark Turner, from Demon Internet Systems, is likely to be on hand to demo DIS for non-DIS users. We've set up our own local, high-quality newsgroups: demon.security demon.security.keys and established the /pub/pgp and /pub/ibmpc/pgp archives on gate.demon.co.uk (expanding recently to include all versions of PGP, and interesting related files). Hope to see you there! Semper vigilans, -----BEGIN PGP SIGNATURE----- Version: 2.1 iQCVAgUBK0lmwYTj7/vxxWtPAQFtVQQAna8vfz6LqC5J5fhlgE1FB+m4GpkvU4o9 HrpFd5NKTc+JrKZEuv/sEDbJvXScc5N38n9KCyIEKdPEUxsjSA58CffcLLEW4xnb w3zAIMyr3wdsD0sxw0gqSi3sx6MbGP5fXwbUb+LyNJzCvpzt3MLYA5tYWZkvIbl9 ONV1PIPtB60= =8qA3 -----END PGP SIGNATURE----- Russell Earl Whitaker whitaker at eternity.demon.co.uk Communications Editor 71750.2413 at compuserve.com EXTROPY: The Journal of Transhumanist Thought AMiX: RWHITAKER Board member, Extropy Institute (ExI) ================ PGP 2.0 public key available ======================= From whitaker at eternity.demon.co.uk Tue Jan 5 12:10:16 1993 From: whitaker at eternity.demon.co.uk (Russell E. Whitaker) Date: Tue, 5 Jan 93 12:10:16 PST Subject: Anonymous thanks ;-) Message-ID: <8333@eternity.demon.co.uk> -----BEGIN PGP SIGNED MESSAGE----- Some kind U.S. cypherpunk sent me a copy of his public keyring last week. Unfortunately - mea culpa! - after having integrated his keyring, I deleted his original message from my mailbase, and thus lost his contact info. I wish to thank this person for sending the keyring, whoever you are... my memory is faulty: so much email to catch up on! In the meantime, Mark Turner (mt at kram.org) is hard at work 1.) porting PGP to 386BSD and 2.) developing a telnettable PGP Key Server. Details as they happen. -----BEGIN PGP SIGNATURE----- Version: 2.1 iQCVAgUBK0lqRITj7/vxxWtPAQGKeQQAo45IcgvBRON49bxyRtPSyHEpi4InsXQA oNxAE+iN+mGTRYRov8a9twgPXp+i7YHv+Xx+A8+c0ZilJV/954uPFy22xAqxl+4P kpUaITTt+oo/3no7g2cBPC2JhOZS7QTkokBvILhoofjNzRZJ+qTUScpyZ4QVlRvP smkZ8WWQg6o= =uvOA -----END PGP SIGNATURE----- Russell Earl Whitaker whitaker at eternity.demon.co.uk Communications Editor 71750.2413 at compuserve.com EXTROPY: The Journal of Transhumanist Thought AMiX: RWHITAKER Board member, Extropy Institute (ExI) ================ PGP 2.0 public key available ======================= From mt at kram.org Tue Jan 5 13:19:58 1993 From: mt at kram.org (Mark Turner) Date: Tue, 5 Jan 93 13:19:58 PST Subject: Anonymous thanks ;-) Message-ID: <9301052119.AA04308@toad.com> -----BEGIN PGP SIGNED MESSAGE----- On Tue, 05 Jan 93 11:00:49 BST, "Russell E. Whitaker" wrote: > In the meantime, Mark Turner (mt at kram.org) is hard at work 1.) > porting PGP to 386BSD and 2.) developing a telnettable PGP Key > Server. Details as they happen. I was beaten too it with the port by Graham Toal (gtoal at gtoal.com) and Adrian Hall (adrian at rachel.ibmpcug.co.uk). It's available for anon ftp from rachel.ibmpcug.co.uk:/usr/local/src/pgp. Regards, Mark. p.s. I'll announce the PGP server here once it's fully operational. It will also have a mail server. -----BEGIN PGP SIGNATURE----- Version: 2.1 iQCVAgUBK0n6NUER4WTv6d3nAQHorAP/ekT7fQYOSBBuS3vcBXJ7FG7RtwoID8QP NxspuGGrXcFSkKR4pCIzAArhWpxN3/gIqELiMQuEF2oGkzVomZBxmnyXvQxOjTtl e1x42EISp06qgMplwx4xu1FyPtF00BYI+WLlzeELvJ4DEvej8A5o+WVqQyjn8Ah7 /fAWIx4JSaE= =/ja0 -----END PGP SIGNATURE----- -- /\/\ark Turner Demon Systems / Demon Internet Office: mark at demon.co.uk (+44 81 349 0063) 42 Hendon Lane, London Home: mt at kram.org (+44 831 823 212) N3 1TT, England ------------------ PGP version 2.1 Public Key available ------------------- *** IP level dial-up connectivity to the Internet for a tenner a month! *** From wcs at anchor.ho.att.com Tue Jan 5 13:50:00 1993 From: wcs at anchor.ho.att.com (Bill_StewartHOY0021305) Date: Tue, 5 Jan 93 13:50:00 PST Subject: purloined letter -- mimic functions Message-ID: <9301052145.AA17381@anchor.ho.att.com> Peter Wayner sent along the following note about mimic functions: ------- cut here ------ Original-From: wayner at cs.cornell.edu (Peter Wayner) Cool. I'm not a member of the mailing list. You can tell them if they want a copy of the code they should send me a note. They can get it in either C or Pascal. The C comes with tar wrapping paper for the faux industrial tech look. (I can't wait until Crate and Barrel start mining the Civil Defencse era for new retro-trendy styles. ) -Peter ------ cut here ------- At the risk of sounding like Peter G Neumann, I should comment that the combination of mimic functions and Mime mail could lead to lots of silliness and hand-waving .... Bill From yanek at novavax.nova.edu Wed Jan 6 05:53:09 1993 From: yanek at novavax.nova.edu (Yanek Martinson) Date: Wed, 6 Jan 93 05:53:09 PST Subject: RSAREF now available via anonymous FTP (fwd)) Message-ID: <9301061352.AA03071@novavax.nova.edu> In case someone's interested: Forwarded message: > Date: Tue, 5 Jan 93 17:15:58 PST > Message-Id: <9301060115.AA18302 at RSA.COM> > To: rsaref-users at RSA.COM > From: burt at RSA.COM > Subject: RSAREF now available via anonymous FTP > Sender: rsaref-users-request at RSA.COM > > Dear RSAREF user -- > > RSAREF is now available via anonymous FTP to 'rsa.com'. Along with > RSAREF you can get RIPEM, Mark Riordan's RSAREF-based privacy-enhanced > mail application, and an Emacs command interface to RIPEM. See the > file 'README' in the FTP directory 'rsaref' for more information. > > -- Burt Kaliski > RSA Laboratories > -- Yanek Martinson mthvax.cs.miami.edu!safe0!yanek uunet!medexam!yanek this address preferred -->> yanek at novavax.nova.edu <<-- this address preferred Phone (305) 765-6300 daytime FAX: (305) 765-6708 1321 N 65 Way/Hollywood (305) 963-1931 evenings (305) 981-9812 Florida, 33024-5819 From honey at citi.umich.edu Wed Jan 6 08:48:52 1993 From: honey at citi.umich.edu (peter honeyman) Date: Wed, 6 Jan 93 08:48:52 PST Subject: A solution remailer signature suppression In-Reply-To: <1k4PwB7w165w@spectrx.saigon.com> Message-ID: <9301061648.AA16517@toad.com> count me on the side of those folks who feel that remailers (and mailers, for that matter) should keep their hands off the body of the message. furthermore, any editor that changes a file without being told to (e.g., by stripping blanks) is (imho) broken. edgar, you say: > This system I use doesn't allow me to run my own software, so I > think this idea wouldn't work for me, in any case. that is probably not the sort of system you want to use if you are interested in the privacy and integrity of your work. peter From edgar at spectrx.Saigon.COM Wed Jan 6 10:12:35 1993 From: edgar at spectrx.Saigon.COM (Edgar W. Swank) Date: Wed, 6 Jan 93 10:12:35 PST Subject: Remailer .sig suppressio Message-ID: -----BEGIN PGP SIGNED MESSAGE----- I was glad to read Hal's comments of Jan 2 about sig suppression and his anecdote about trying to chain the penet and pax remailers. I was not aware til now that the penet sig test was any line which *starts with* "--". A more appropriate test would be any line *consisting of only* "--" (exactly two dashes). Do you know if the pax sig test is the same as penet's? I can't imagine any solution to your problem which does not involve changing either the remailer (tighter sig test) or PGP (recognize either ----- or - --- as starting a PGP message or key delimiter). The best solution so far appears to be Miron Cuperman's remailer which is similar to (based on) the cypherpunks remailer, but *requires* encrypted input and does not remail any unencrypted text which might preceed or follow the encrypted text. But some modification of Miron's remailer to process trailing plaintext seems to be necessary for ARA. I hope it will include some recognition of a well-defined unambiguous text delimiter such as - -----END OF MESSAGE BODY----- which will screen out any following text. John Gilmore commented on my request for sig suppression: Remove the file ".signature" from your home directory and you'll be done with *that* hassle. Well, my home directory doesn't *have" a ".signature" file! This is an MS-DOS based WAFFLE BBS. All the sigs on this system look the same so I suspect that they are made up from the user directory and some file outside my home directory. I am led to believe from the user doc that if I *create* a file "sig" or "mailsig" (no dots) in my home directory this may affect the auto sig produced, but I haven't had a chance to try it yet. My fear is that if I produce a null sig file that the "--" will still appear, making it obvious that the auto sig is nulled. If this "--" appears at the same time on both my regular and anonymous messages, people who see both may put two and two together. John: PS: An extra credit note for the differently clued among us: Suppose you wanted to have a *different* signature for each of your multiple identities? I guess the remailers had better not strip off signatures, eh? Since I make up my outgoing mail offline, I would prefer to copy in the correct sig corresponding to each message identity. That way I can see that the correct sig is matched with the correct msg in each case. I can easily avoid remailer stripping by using a delimiter like "**" instead of "--". As I said in a previous msg, the problem with auto sigs is reliably switching them as you send out (with an automatic script) messages from your different ID's. Since getting the wrong sig on the wrong msg could result in jail, under some circumstances, I consider this a serious problem. An "anonymous" remailer which allows a user to lose his anonymity through a simple lapse (forgetting about the auto sig) is one too dangerous for me to use. In another msg, John Gilmore delivers a long harangue about "Why mailers should not touch the body". I agree with the above phrase if we differentiate "mailers", which are necessary for the generation and forwarding of all mail, from "anonymous remailers", which have to be specifically requested by the message sender, and whose only purpose is to obscure the message origin. Since the automatic signature often reveals the message origin, it's quite compatible with the mission of an anonymous remailer to remove it. John doesn't want PGP changed to eliminate trailing blanks on signed plaintext. (Which I think would fix about 90+% of current problems verifying sigs). He wants us all to suffer until all the mailers in the world are fixed to pass 8-bit binary. Well, I won't hold my breath for that. I think UUENCODE and PGP armored form are going to be around a long time. I prefer a more pragmatic approach that will give more immediate relief. -----BEGIN PGP SIGNATURE----- Version: 2.1 iQCVAgUBK0rOvt4nNf3ah8DHAQGBrQP+I9DKzknWE6sNTmYeSga3tQWv2IrHQPyc hnqgXXqwq6GRvOUvGXqHdig9jfXbatYh7uYuMqn61xP9409JXnNJZ7QQuB9vSNdz K5gvCKksPKjJoxAb5miDJvf61bS3N/bavl8gHM80DaRxv0n5UlzymLAvurZrL2qR ZxgCWhz9P3o= =CAUz -----END PGP SIGNATURE----- -- edgar at spectrx.saigon.com (Edgar W. Swank) SPECTROX SYSTEMS +1.408.252.1005 Silicon Valley, Ca From tytso at ATHENA.MIT.EDU Wed Jan 6 13:24:09 1993 From: tytso at ATHENA.MIT.EDU (Theodore Ts'o) Date: Wed, 6 Jan 93 13:24:09 PST Subject: A solution remailer signature suppression In-Reply-To: <9301061648.AA16517@toad.com> Message-ID: <9301062123.AA17503@tsx-11.MIT.EDU> I also agree that any sort of mailers should pass a message body UNTOUCHED. Next thing you know, people will be advocating that remailers have AI capabilities for stripping out incriminating statements made inside the body. If your mail system is broken enough that it inserts signatures without your permission, and you have no way to controlling it, it's broken. End of statement. Fix it or ditch it. - Ted From shipley at merde.dis.org Wed Jan 6 20:25:15 1993 From: shipley at merde.dis.org (shipley at merde.dis.org) Date: Wed, 6 Jan 93 20:25:15 PST Subject: mh wrapper Message-ID: <9301070203.AA25280@merde.dis.org> -----BEGIN PGP SIGNED MESSAGE----- here is my first pass (a 7min hack) at a wrapper for a pgp<->mh use. the next verion will me a replacement for the editor to automaticly sign the body of a file (while leaving the header alone. ===== CUT HERE ==== #!/bin/sh #pgpcomp - pgp compose # Peter M. Shipley (Wed Jan 6 17:58:41 PST 1993) umask 7077 TEMP=${TEMP-/tmp} EDITOR=${EDITOR-/usr/ucb/vi} whatnow=/usr/local/mh-6.7/bin/whatnow export TEMP EDITOR tempfile=$TEMP/pgp$$ /bin/cat << EEOOFF > $tempfile To: cc: Fcc: +drafts Subject: Precedence: special-delivery - -------- EEOOFF $EDITOR $tempfile /bin/sed "/^--------/,$ d" < $tempfile > ${tempfile}.head /bin/sed "1,/^--------/d" < $tempfile > ${tempfile}.body /usr/local/bin/pgp -sta +clearsig=on $tempfile.body -o $tempfile.signed /bin/mv ${tempfile}.head ${tempfile} /bin/cat << EEOOFF >> ${tempfile} - -------- EEOOFF /bin/cat < $tempfile.signed.asc >> ${tempfile} /bin/rm -f ${tempfile}.* exec $whatnow -prom "pgpsend> " $tempfile ===== CUT HERE ==== -----BEGIN PGP SIGNATURE----- Version: 2.1 iQBFAgUBK0uPgMhmn7GUWLLFAQH7MAF9EuCX3ZAauG771viwGmnyk4YaiNDFhpmr ann0Qvd6hVhTOnbSZNKet3Z9i0FUnDDu =40PL -----END PGP SIGNATURE----- From karn at qualcomm.com Wed Jan 6 21:54:47 1993 From: karn at qualcomm.com (Phil Karn) Date: Wed, 6 Jan 93 21:54:47 PST Subject: Russian analysis of PGP Message-ID: <9301070552.AA22839@servo> Anybody familiar with the internals of PGP care to comment on this item that just showed up on sci.crypt? It's amazing to think that the famous "kremvax" joke was only a decade ago. Now the Russians are openly reviewing our cryptosystems for us. May you live in interesting times. Phil From mkagalen at lynx.dac.northeastern.edu Wed Jan 6 16:28:20 1993 From: mkagalen at lynx.dac.northeastern.edu (michael kagalenko) Date: Thu, 7 Jan 1993 00:28:20 GMT Subject: discussion desired Message-ID: <1993Jan7.002820.3579@lynx.dac.northeastern.edu> I'd appreciate greately your enlightened opinions on the following article. (disclaimer : I have no qualification in the Great Science of Cryptology(tm) ; I'm just posting someone's e-mail) About using the electronic signature for protection of commercial information: The analysis of PGP ver.2.0 program. --------------------------------------------------------------------- THE MOSCOW STATE UNIVERSITY named after m.V. Lomonosov ______________________________________________________________ THE MATHEMATICAL CRYPTOGRAPHY PROBLEMS LABORATORY The MSU mathematical cryptography problems laboratory employeers with some addition specialists were executed the preliminary analysis of PGP ver.2.0 program. The preliminary study of working and program source code analysis result in following PGP features and problems: 1. The common character problems - the sequence of random numbers has strong prevalences on bytes (up to 0.05 ... 0.1 on material of 10000 byte) and strong correlation dependence between contiguous bytes; - the program doesn't check it's own integrity, so it can be infected by "virus" which intercept confidential keys and passwords used for their protection and save them onto magnetic carriers; - the program has not optimal exponentiation algorithm in GF(P) field, when P - prime number, which result in low performance; 2. The RSA algorithm realization problems - the prime numbers reception using in this program (R and q in RSA algorithm) permits not less than on two order to reduce the labour-intensiveness of factorization; with 256 bit blocks of data lenght it is possible to execute the cryptanalysis in real time; - before using RSA the program executes compression and block encryption that positively affects on the common stability encryption. 3. The electronic signature problems - for signature calculation the program originally executes hashing of file into number of given length (256, 512 or 1024 bit), but hashing function does not corresponds the ISO recommendations; - when considering the hashing function as the automatic device without output, it is enough simply possible to construct the image of reverse automatic device and with using the blanks in text files (or free fields in some standard formats as in DBF), to compensate the hashing function at changed file to former significance. Thus, it is possible to forge the electronic signature without analysis of RSA algorithm. 4. The block encryption algorithm problems - when executing analysis on plaintext and ciphertext the linear correlation dependences with encryption key were founded (0.01 and more degree); - also the effective method of decreasing security which reduces the order of time necessery to key definition in two times in comparison with exhaustive search of all keys (i.e. algorithm has the labour-intensiveness which is equal the root square from labour-intensiveness of the exhaustive search algorithm) have been found. The conclusions: It is recommended to use encryption with 1024 bit key length. The using of electronic signature is not recommended and requires the additional study. The block encryption algorithm has temporary stability. The hashing function should be reduce in conformity with ISO recommendations. The using of PGP program in actual version is undesired. The MSU mathematical cryptography problems Laboratory Manager Academician Dr. Sidelnikov V.M. ==END From barrus at tree.egr.uh.edu Thu Jan 7 11:10:50 1993 From: barrus at tree.egr.uh.edu (Karl L. Barrus) Date: Thu, 7 Jan 93 11:10:50 PST Subject: double anonymity via pax and penet Message-ID: <9301071910.AA04605@tree.egr.uh.edu> Cypherpunks, I've been toying lately with "tying" the remailers at pax and penet together. Briefly, the anonymous service at anon.penet.fi supports anonymous remailing (but you must register your id), anonymous posting, and anonymous forwarding. The remailer at pax.tpa.com.au support anonymous remailing (runs pgp, must register your key for encryption service) and anonymous posting. For more info, get the help files by mailing to help at anon.penet.fi and anon.info at pax.tpa.com.au. Anyway, my idea is as follows: somehow get one of these services to establish an id on the other one, and also establish a path back to you. Then, you should be able to receive mail by having it sent to an anonymous id on one of the services, which will then forward it to another anonymous id on the other service, which will then forward to you. Of course, as cypherpunks, we have several of our own cryptographically protected remailers, but I thought I'd explore using these others ones also. If you don't have an id already established on either service, you can get one by simple trying to use it (for example, posting a message). Since the remailer at anon.penet.fi allows anonymous forwarding (using the % notation), I established a double system as follows: (for convenience I shall reveal the anonymous id's I was assigned by this test procedure; @penet shall mean @anon.penet.fi and @pax shall mean @pax.tpa.com.au) I mailed to anon.post.alt.test%pax.tpa.com.au at anon.penet.fi from barrus at tree.egr.uh.edu. This went to anon.penet.fi, where I was allocated an anonymous id for barrus at tree. The id I was given for barrus at tree was an5022 at penet. Then, penet forwarded to anon.post.alt.test at pax.tpa.com.au (because of the % notation), which resulted in two things: a post to alt.test, and the establishing of an id on pax for the anonymous id on penet - anon.435 at pax. After a few minutes, I recieved acknowledgment of my post to alt.test, sent from penet. So pax sent the acknowledgement to the anonymous id at penet, which then sent it to me - barrus at tree. I also watched for my post to alt.test to appear, which it did. So now, mail sent to anon.435 at pax gets forwarded to me via penet. Then, I tried the process in reverse. I sent to the anonymous pax allocated from my other account (elee9sf at menudo.uh.edu). I sent from the other account because I already have an anonymous id for that one, and I wanted to keep new account allocation to a minimum, but as it turns out I think I messed up. Anyway, the mail I sent made it to barrus at tree (via pax and penet), but I was allocated another anonymous id from penet (an5030 at penet), and the notice came to elee9sf! After thinking about it some more, I realized that what that acknowledgement must be. When I mailed to anon.435 at pax from elee9sf, I wasn't allocated an anonymous id because I have one. So pax sent the message to an5022 at penet. But penet hadn't seen a message from anon.435 at pax, so it allocated another id, and sent to acknowledgement back to anon.435 at pax. But for some reason, the remailer at pax didn't send this to an5022 at penet - it jumped it and responded to my account elee9sf at menudo.uh.edu. So the pax service seems fairly intelligent. Or there is a bug :-) Then, I tried to mail to anon.435 at pax from barrus at tree. I thought I would be assigned an anonymous id at pax for barrus at tree, but I wasn't. Actually, for some reason, I was mailed the acknowledgement of yet another anonymous id, an5047 at penet! But, my original goal was to establish an anonymous id on pax which would forward to an anonymous id on penet (and vice versa), and I succeeded: mail sent to anon.435 at pax goes to barrus at tree via penet mail sent to an5030 at penet goes to elee9sf at menudo via pax as an unplanned effect: mail sent to anon.437 at pax goes to elee9sf at menudo via penet mail sent to an5047 at penet goes to barrus at tree via pax These are the anonymous id's I beleive I've generated because of this procedure: an5022 at penet, an5030 at penet, an5047 at penet (I don't understand this one), anon.435 at pax, anon.437 at pax (I don't understand this one either). I figured I would use four id's: one from penet for barrus at tree, one from pax for barrus at tree, one from penet for pax, and one from pax for penet. For some reason, when I mail to anon.437 at pax or an5047 at penet from barrus at tree, the mail doesn't arrive in either of my accounts. So I'm still trying to sort out this mess before I mail to the administrators at both sites, explain what happened, and have these various id's deleted. Anybody with an id already established on pax or penet is welcome to mail to me at anon.208 at pax or an5030 at penet to help me figure out if it worked (I've run out of accounts to test this from and I don't want to involve elee7h5 at rosebud where I'm running a remailer). I think the step I may have erred was mailing to anon.435 at pax from elee9sf, where I have an id. Maybe by mailing from barrus at tree I would have been assigned an id, and recieved acknowledgement of an id from penet for the id at pax, and possibly an5047 at penet wouldn't have been generated. Some uses of this I can think of are of course mailing via cypherpunk remailers to the first link in the pax/penet remailers chain. This would hide our remailers from others, since pax and penet are well known anonymous services. I haven't thought of a way to send messages (other than posting to usenet) via pax/penet. So I could post a message, as described above, and collect responses via a double anonymous reply. Anyway, what do you think?? Any ideas or suggestions? /-----------------------------------\ | Karl L. Barrus | | barrus at tree.egr.uh.edu (NeXTMail) | | elee9sf at menudo.uh.edu | \-----------------------------------/ From 74076.1041 at CompuServe.COM Thu Jan 7 13:04:27 1993 From: 74076.1041 at CompuServe.COM (Hal) Date: Thu, 7 Jan 93 13:04:27 PST Subject: Chaining remailers. Message-ID: <930107205520_74076.1041_DHJ47-1@CompuServe.COM> -----BEGIN PGP SIGNED MESSAGE----- It was interesting to see Karl Barrus's efforts to chain the Pax and Penet remailers. I think one of his problems is this: If I reply to one of Karl's double-remailed aliases, I will get assigned two anonymous aliases - one from each of pax and penet. The first machine I send to will assign me an anonymous alias, and forward my mail on, with a "From:" indicating that same new alias. The second machine will then see mail coming in from that new alias, assign me an alias for that, and send it back to me (via the first machine). That's why Karl got an extra alias in some of his tests that he wasn't expecting. It also means that the fact that he is using a double remailing alias will be revealed to anyone who chooses to send to him. I think the lesson is that this process of automatic alias assignment may not be the best way to handle things. It sounds attractive and simple, but look at all the problems Karl ran into. And if you're using a chain of remailers for an anonymous address, you really don't want everyone who sends to you to find out exactly what chain you are using. I still lean towards the idea of a "constructed" anonymous address, where I decide ahead of time which remailers I'll use, and in what order. Then, I need some way to put that address into the return field of my mail that I send. If this were possible, then person A could post a message, with his headers set so that replies will go to this anonymous address. And if person B wanted to send to A, he could, using A's anonymous address, and B could arrange it so that B's own anonymous address would go into the outgoing headers. A and B could then communicate using two completely different paths, both anonymously. A could go from pax to penet to B, and B could go from menudo to rebma to A. Each user would establish his anonymous address in the way he preferred. I think this is probably a better system than all this automatic assignment of anonymous aliases. It seems simpler and it should still be easy to use. The automatic systems tend to get out of hand. Hal Finney 74076.1041 at compuserve.com -----BEGIN PGP SIGNATURE----- Version: 2.1 iQCVAgUBK0xuQagTA69YIUw3AQEGXAP/XxoWGmnMOm7E0d70uRGuwqHpG8KPzopk uERMjltmE1Xug7auzmFYKEV1I24DZyd3ClaDyoZQWpI79dTLQfnEPOHqhgXD8Ul4 PgYo5Gyf2yKIv5kbsmetWnAB23oDeyuE6HR9X5vl/MNWq38exbRlt8I303FtXQCi foIUiShHcaA= =0k6V -----END PGP SIGNATURE----- Distribution: CYPHERPUNKS >INTERNET:CYPHERPUNKS at TOAD.COM From barrus at tree.egr.uh.edu Thu Jan 7 13:53:49 1993 From: barrus at tree.egr.uh.edu (Karl L. Barrus) Date: Thu, 7 Jan 93 13:53:49 PST Subject: chaining remailers... Message-ID: <9301072153.AA05530@tree.egr.uh.edu> Geez, I can't beleive I forgot to consider that responding to me will result in a steady stream of anonymous id allocations. Guess I was caught sleeping on that one! Back to the better cryptographically protected cypherpunk remailers and Hal's "constructed" anonymous addresses...and I better ask the administrators at pax and penet to wipe out some allocated id's :-) /-----------------------------------\ | Karl L. Barrus | | barrus at tree.egr.uh.edu (NeXTMail) | | elee9sf at menudo.uh.edu | \-----------------------------------/ From julf at penet.FI Thu Jan 7 15:20:26 1993 From: julf at penet.FI (Johan Helsingius) Date: Thu, 7 Jan 93 15:20:26 PST Subject: double anonymity via pax and penet In-Reply-To: <9301071910.AA04605@tree.egr.uh.edu> Message-ID: <9301072254.aa08873@penet.penet.FI> > I've been toying lately with "tying" the remailers at pax and > penet together. Briefly, the anonymous service at anon.penet.fi > supports anonymous remailing (but you must register your id), > anonymous posting, and anonymous forwarding. The remailer at > pax.tpa.com.au support anonymous remailing (runs pgp, must register > your key for encryption service) and anonymous posting. For more > info, get the help files by mailing to help at anon.penet.fi and > anon.info at pax.tpa.com.au. Well, let's start by saying that fo%bar at blach addresses are pretty error prone, as there are a lot of brain-damaged mailers out there. Much safer to use the X-Anon-To: header for this kind of stuff. See the help file from help at anon.penet.fi for more info. Secondly, currently anon.penet.fi strips off PGP messages and signature blocks. I am going to fix the .sig stripper Real Soon Now.... Thirdly, I notice a lot of mailers get "From:" and "Sender:" (or envelope) addresses screwed up. Anon.penet.fi puts the anon id in the "From:" field, but makes "Sender:" point to the anon admin, to catch mail bounces that might reveal the true identity of an anon id. I don't know how pax.tpa.com.au handles this.... > These are the anonymous id's I beleive I've generated because > of this procedure: an5022 at penet, an5030 at penet, an5047 at penet (I don't > understand this one), anon.435 at pax, anon.437 at pax (I don't understand > this one either). I figured I would use four id's: one from penet for > barrus at tree, one from pax for barrus at tree, one from penet for pax, and > one from pax for penet. > For some reason, when I mail to anon.437 at pax or an5047 at penet > from barrus at tree, the mail doesn't arrive in either of my accounts. > So I'm still trying to sort out this mess before I mail to the > administrators at both sites, explain what happened, and have these > various id's deleted. Anybody with an id already established on pax > or penet is welcome to mail to me at anon.208 at pax or an5030 at penet to > help me figure out if it worked (I've run out of accounts to test this > from and I don't want to involve elee7h5 at rosebud where I'm running a > remailer). > I think the step I may have erred was mailing to anon.435 at pax > from elee9sf, where I have an id. Maybe by mailing from barrus at tree I > would have been assigned an id, and recieved acknowledgement of an id > from penet for the id at pax, and possibly an5047 at penet wouldn't have > been generated. I'll check on those id's tomorrow. It's 11pm out here, and I have a specification to finish for a meeting tomorrow morning.... Julf (an0 at anon.penet.fi) From nowhere at bsu-cs.bsu.edu Fri Jan 8 17:49:57 1993 From: nowhere at bsu-cs.bsu.edu (Chael Hall) Date: Fri, 8 Jan 93 17:49:57 PST Subject: New Remailer Message-ID: <9301090147.AA03071@bsu-cs.bsu.edu> Fellow Cypherpunks: I am working on a program in C that will provide both anonymous remailing capabilities and mail server operations. In order to better test the software I have installed it on my account through my .forward and .maildelivery files so that all messages received with a header line "X-Anon-To" or "Request-Remailing-To" will be remailed to the appropriate address. If you cannot add your own header lines with your mailer, set the subject to contain "Request Remailing" and use the following format: :: Request-Remailing-To: user at host Subject: Anything you choose :: Any of the following fields can be placed within the "::" delimiters: Request-Remailing-To: X-Anon-To: Subject: The remailer is case insensitive and you can place the "::" lines anywhere within the message. Signature stripping is NOT supported, however a "kill line" will be implemented soon so that you can halt message processing beyond a certain point. Message body processors are supported as an add-on feature. PGP support would work as a message processor. On my end, I can define a "start processing" line and a "stop processing" line. Only text between (and including) those lines will be passed to the message processor. Unfortunately, PGP is not installed on this system, so support will have to wait. I will post full specifications later. Plesae let me know of any ambiguities. Please also note that I am keeping detailed logs of the use of this software for testing purposes, but I would rather delete all logs than provide them to authorities. The remailer is run on a multi-user system for which I do not have a privileged account. Chael Hall Chael Hall | Campus Phone Number nowhere at bsu-cs.bsu.edu | (317) 285-3648 00CCHALL at bsuvax1.bitnet | 00CCHALL at LEO.BSUVC.BSU.EDU | "I hate it when that happens!" From nowhere at bsu-cs.bsu.edu Fri Jan 8 18:02:48 1993 From: nowhere at bsu-cs.bsu.edu (Chael Hall) Date: Fri, 8 Jan 93 18:02:48 PST Subject: New Remailer (more) Message-ID: <9301090200.AA03698@bsu-cs.bsu.edu> I forgot to add: If you are chaining remailers, you can use the sequence "+::+" at the beginning of the line to pass the remaining characters on that line through the remailer untouched. For example: Message sent to this remailer: ----------v :: X-Anon-To: anon at anon.penet.fi :: +::+:: X-Anon-To: nowhere at bsu-cs.bsu.edu +::+:: beginning of text... ----------^ Message sent to anon.penet.fi: ----------v :: X-Anon-To: nowhere at bsu-cs.bsu.edu :: beginning of text... ----------^ Chael Hall Chael Hall | Campus Phone Number nowhere at bsu-cs.bsu.edu | (317) 285-3648 00CCHALL at bsuvax1.bitnet | 00CCHALL at LEO.BSUVC.BSU.EDU | "I hate it when that happens!" From mjr at netcom.com Fri Jan 8 19:57:22 1993 From: mjr at netcom.com (Matthew Rapaport) Date: Fri, 8 Jan 93 19:57:22 PST Subject: Alias cascades Message-ID: <9301090357.AA07830@netcom2.netcom.com> ****** Hal <74076.1041 at CompuServe.COM> ****** >I think the lesson is that this process of automatic alias assignment >may not be the best way to handle things... look at all the problems >Karl ran into. If I understand Karl right, he got this cascade of aliases because he tried to talk to HIMSELF through different accounts/aliases at alternate ends of the chain. Since no one would want to do that (other than to test things) normally, this wouldn't be a problem. >I still lean towards the idea of a "constructed" anonymous address, >where I decide ahead of time which remailers I'll use, and in what >order. But I already *do* control the order of use for MY mail, that means stuff I send out and stuff people send to me in DIRECT reply to my stuff. There is nothing to stop someone from sending to my id on pax say through a first remailer of their own choice, provided they originate the mail (i.e. a REPLY is not equivalent to ORIGINAL mail in this case). As for picking my own alias, this sounds appealing but is actually much weaker then a randomly assigned one. Besides that, it could be an administrative nightmare for the sysadmins on the aliasing systems. matthew rapaport Philosopher/Programmer At Large KD6KVH mjr at netcom.com 70371.255 at compuserve.com From 74076.1041 at CompuServe.COM Fri Jan 8 23:43:08 1993 From: 74076.1041 at CompuServe.COM (Hal) Date: Fri, 8 Jan 93 23:43:08 PST Subject: New remailer in C. Message-ID: <930109073836_74076.1041_DHJ43-1@CompuServe.COM> -----BEGIN PGP SIGNED MESSAGE----- From: nowhere at bsu-cs.bsu.edu (Chael Hall) > Fellow Cypherpunks: > > I am working on a program in C that will provide both anonymous > remailing capabilities and mail server operations. It's good to see more people working on remailers. The cypherpunks remailers have been written in Perl, which facilitates experimenting and testing of new interfaces. The idea might be to migrate them to C eventually for efficiency, but during this experimental phase we may want to try out new ideas, and it's easier to modify a Perl script than a C program. > If you cannot add your own header lines with your mailer, set > the subject to contain "Request Remailing" and use the following format: > > :: > Request-Remailing-To: user at host > Subject: Anything you choose > :: > > Any of the following fields can be placed within the "::" delimiters: > > Request-Remailing-To: > X-Anon-To: > Subject: > > The remailer is case insensitive and you can place the "::" lines > anywhere within the message. This is somewhat similar to the cypherpunks remailers; however, they accept the :: only at the beginning of the message, allow any fields to be put there that the user desires (not just those three), and terminate the block by a blank line. Does your alternate system have some advantages? > I forgot to add: If you are chaining remailers, you can use the > sequence "+::+" at the beginning of the line to pass the remaining characters > on that line through the remailer untouched. I do find the use of this string to produce rather complicated looking commands. The cypherpunks remailers get the same effect by just putting in blocks starting with :: and separated by blank lines: :: Anon-To: anon at anon.penet.fi :: Anon-To: nowhere at bsu-cs.bsu.edu This looks simpler to me. Hal Finney 74076.1041 at compuserve.com -----BEGIN PGP SIGNATURE----- Version: 2.1 iQCVAgUBK05WUagTA69YIUw3AQGpaAP+LxpocNUI1/Zw3DAwwAxeKBtdj0sSyx8p 05xnI3FmklosxapVpcF/aVkDKL/FjzwBZ9ML5wt2m7UvqS1iX9UILQByPNAxTOKF TIuFKkjt2wT5ykvHRGLl6ZAB6w6PzkNiclHNJw4FFEaFzoxmnz3bQXatKBFFgGFd IjIMFF0d0Ig= =ztz0 -----END PGP SIGNATURE----- Distribution: CYPHERPUNKS >INTERNET:CYPHERPUNKS at TOAD.COM From 74076.1041 at CompuServe.COM Fri Jan 8 23:47:53 1993 From: 74076.1041 at CompuServe.COM (Hal) Date: Fri, 8 Jan 93 23:47:53 PST Subject: Chaining addresses... Message-ID: <930109073904_74076.1041_DHJ43-2@CompuServe.COM> -----BEGIN PGP SIGNED MESSAGE----- From: mjr at netcom.com (Matthew Rapaport) > >I think the lesson is that this process of automatic alias assignment > >may not be the best way to handle things... look at all the problems > >Karl ran into. > > If I understand Karl right, he got this cascade of aliases because he > tried to talk to HIMSELF through different accounts/aliases at alternate > ends of the chain. Since no one would want to do that (other than to > test things) normally, this wouldn't be a problem. My understanding was that everyone who tried to talk to him would get two aliases assigned automatically. Karl made the problem worse by talking to himself from two different addresses, but you're still talking about a lot of aliases. > >I still lean towards the idea of a "constructed" anonymous address, > >where I decide ahead of time which remailers I'll use, and in what > >order. > > But I already *do* control the order of use for MY mail, that means > stuff I send out and stuff people send to me in DIRECT reply to my > stuff. There is nothing to stop someone from sending to my id on pax say > through a first remailer of their own choice, provided they originate > the mail (i.e. a REPLY is not equivalent to ORIGINAL mail in this case). OK, so you can set up an anonymous address which, say, goes through pax and then penet and then to you. If someone replies to that address, they will be anonymous to you, by default; their anonymous address will go through penet and then pax. But if they didn't want that anonymous address, they could use one of their own (say, rebma to soda to themselves) first, then go to your address. Now when you reply to them, I guess your message will go through penet, then pax, then rebma, then soda, then to them. My feeling was it would be better if they could put a Reply-To: into the message that just meant to go to rebma then to soda to themselves, and get that Reply-To: to go through the pax-to-penet chain to you. Also, they would not get anonymous ID's assigned by penet and pax, ideally. Instead, you would reply to them using this Reply-To address and go through just rebma and soda to get to them. This will be simpler and faster than having all messages go through the union of both communicant's anonymous address chains. > As for picking my own alias, this sounds appealing but is actually much > weaker then a randomly assigned one. Besides that, it could be an > administrative nightmare for the sysadmins on the aliasing systems. I wasn't really talking about picking my own alias. It is more a matter of having a straightforward way to construct an anonymous address that goes through the specific chain of systems that I choose. Hal Finney 74076.1041 at compuserve.com -----BEGIN PGP SIGNATURE----- Version: 2.1 iQCVAgUBK05Wa6gTA69YIUw3AQFy+QP/RAepMQETJWqM7szQ9ID0TAgrIvQc8ArH MX6S14lzb492skAIathLYllfyhN2TTO/gN+lCC4lvnzs9UOLJ2rlNzFxT8geV1yx MxKKzIZ39tMmyCXHx2cnH7ySHMoEVzp5TqXqQhEbmqn0k6c7hoL+sz6l43/g6rPL g++F+kRs2nQ= =0OfU -----END PGP SIGNATURE----- Distribution: CYPHERPUNKS >INTERNET:CYPHERPUNKS at TOAD.COM From eab at msc.edu Sat Jan 9 05:49:38 1993 From: eab at msc.edu (Edward Bertsch) Date: Sat, 9 Jan 93 05:49:38 PST Subject: Russian analysis of PGP In-Reply-To: <9301070552.AA22839@servo> Message-ID: <9301091348.AA01342@wc.msc.edu> -> The conclusions: -> It is recommended to use encryption with 1024 bit key length. -> The using of electronic signature is not recommended and -> requires the additional study. -> The block encryption algorithm has temporary stability. -> The hashing function should be reduce in conformity with ISO -> recommendations. -> The using of PGP program in actual version is undesired. -> The MSU mathematical cryptography -> problems Laboratory Manager -> Academician -> Dr. Sidelnikov V.M. these are serious claims. What do the authors of the software have to say about them? Others? -- Edward A. Bertsch (eab at msc.edu) Minnesota Supercomputer Center, Inc. Operations/User Services 1200 Washington Avenue South (612) 626-1888 work Minneapolis, Minnesota 55415 (612) 645-0168 voice mail From tytso at ATHENA.MIT.EDU Sat Jan 9 08:52:30 1993 From: tytso at ATHENA.MIT.EDU (Theodore Ts'o) Date: Sat, 9 Jan 93 08:52:30 PST Subject: Russian analysis of PGP In-Reply-To: <9301091348.AA01342@wc.msc.edu> Message-ID: <9301091651.AA21070@tsx-11.MIT.EDU> From: eab at msc.edu (Edward Bertsch) Date: Sat, 9 Jan 93 7:48:46 CST these are serious claims. What do the authors of the software have to say about them? Others? "Dr. Sidelnikov" has presented some very serious claims, indeed, but has not produced one shred of evidence to back them up. Some of his claims, to wit his assertion that PGP's hashing function is breakable, he could have very simply demonstrated, without using a lot of clumsy english. (All he would have needed to do is to produce, two strings, X and Y, where X != Y and MD5(X) == MD5(Y) --- or better yet, given message digest Z which someone else picks, such as the test values in RFC-1321, produce a string X such that MD5(Z) == X. Some of his other claims, such as his complaint that PGP doesn't contain any self-checking code to protect against "killer viruses", on the surface seem to indicate a very shallow analysis of the problem. Something else to consider is that the source of his posting is somewhat suspect. The person who posted it got it from a friend, who got it from some other net where supposedly Dr. Sidelnikov posted it. At the moment, its source sounds like an awful lot of urban legend stories which many of us have heard before. An equivalent statement to his posting might be: "I heard from a friend who heard from an Eminent MIT Professor: Don't use XXX, since it uses DES which could be broken." While I might have a lot of respect for MIT and its professors, I would want to see a demonstration of this fact before I would take that kind of report very seriously. The same standards should be held to Dr. Sidelnikov. - Ted P.S. Note that I am not completely ruling out Dr. Sidelnikov's claims; but we should keep in mind that up to this point, we have not one shred of evidence that he is (a) who he claims to be, or (b) his statements are true. I would expect that most academics, when publishing something of this magnitude, would include some sort of evidence to back their claims up. P.P.S. Also note that if his claim about MD5 is true, then we are in a lot more trouble than just PGP being insecure. There are an awful lot of other protocols that use MD5, including Privacy Enhanced Email (PEM). From mjr at netcom.com Sat Jan 9 09:20:46 1993 From: mjr at netcom.com (Matthew Rapaport) Date: Sat, 9 Jan 93 09:20:46 PST Subject: Cascading Aliases Message-ID: <9301091720.AA17521@netcom2.netcom.com> ****** Hal <74076.1041 at CompuServe.COM> ***** >My understanding was that everyone who tried to talk to him would get >two aliases assigned automatically. Yes I suppose, but I can ignore them. Let's see if I got this right. In the following scenario, I will represent alias servers and their aliases in the following way: A-123 where 'A' is the server, and '123' is the alias. I receive a message from Z-999. I have no idea how many servers this has gone through. I *originate* a message back to this person, but I sent it first through *my* preferred alias chain, so the message goes from me through A-123 -> B-456 -> Z-999 and then somewhere else (perhaps) before reaching its final destination. Now the Z server has never seen a message from B-456, so it automatically generates a NEW alias (Z-111) for that ID. Now machine Z bounces that new alias back along the chain B-456 -> A-123 and thence to me, informing me that an alias has been established on machine Z for my ID on machine B. It also uses that alias to send the message along to the next machine on the chain (if there is one) which also creates a new alias (never having seen a message from Z-111), and bounces it back, etc. I see that this is where I get to detect the alias path my recipient is using, but there is an easy solution (see below). So one or more new aliases will be generated (you are correct) in response to my original mail, BUT, I can ignore those aliases (once I receive them in the reflected mail) and never need think about them again because the link between B-456 and Z-111 is now established. Further translation will take place automatically with no further bounce backs in any future correspondence between the two parties *if* they both use their own chosen mail paths consistently. If in my next mail, however, I REPLY to Z-999 (i.e. I don't generate original mail), then another alias will be generated on the Z machine for mjr at netcom.com and I will also be informed of that, etc. Once again, however, I don't have to care about that. From the recipients viewpoint, however, mail has now been received from two different aliases that represent the same person (one for my original mail, and one for my REPLIES) There are two possible solutions while still generating automatic aliases: 1) Don't alias someone who hasn't specifically requested it (e.g. with a ping or something). This is probably not a good idea. I like the fact that these Aservers take a "most conservative approach" automatically assuming that someone wants to be aliased if they are originating/replying to an aliased ID. 2) Stop the alias-information-bounce-back unless someone specifically requests it (e.g. with a ping). This might do the trick. I don't have to KNOW what my alias number is even on the machine that does the first outbound and last inbound conversion. All the conversions along the chain are automatic, so why should I care what my alias numbers are? matthew rapaport Philosopher/Programmer At Large KD6KVH mjr at netcom.com 70371.255 at compuserve.com From julf at penet.FI Sat Jan 9 10:56:27 1993 From: julf at penet.FI (Johan Helsingius) Date: Sat, 9 Jan 93 10:56:27 PST Subject: New remailer in C. In-Reply-To: <930109073836_74076.1041_DHJ43-1@CompuServe.COM> Message-ID: <9301092030.aa10557@penet.penet.FI> > > I am working on a program in C that will provide both anonymous > > remailing capabilities and mail server operations. > > It's good to see more people working on remailers. The cypherpunks > remailers have been written in Perl, which facilitates experimenting > and testing of new interfaces. The idea might be to migrate them > to C eventually for efficiency, but during this experimental phase > we may want to try out new ideas, and it's easier to modify a Perl > script than a C program. I do appreciate the cypherpunks stuff, but perl is still not a very widely used standard tool, and not everyone of us want to learn the ins and outs of yet another language... So I do applaud the C version... And please, I am *not* trying to start any religious wars... Julf (an0 at anon.penet.fi) From mjr at netcom.com Sat Jan 9 12:49:59 1993 From: mjr at netcom.com (Matthew Rapaport) Date: Sat, 9 Jan 93 12:49:59 PST Subject: Cascading Aliases Message-ID: <9301092049.AA03501@netcom2.netcom.com> The discussion just above between Karl, Hal, Johan, and myself, has made me realize that the standard "bounce back" behavior of all the alias servers I've used so far actually defeates the purpose of remailer chains no matter how one embeds the forwarding information. When any person *first* replies to or originates mail across a remailer chain, a new alias is generated at each hop (however many). So far, that is good, a "most conservative assumption" approach, and it provides easily for reply channel maintenance. The problem is that each machine also reflects its new alias back along the chain to the message originator thereby revealing the entire chain to the message originator, something that might not be desirable to the party on the other side. The solution is very simple, just stop bouncing the new alias information back along the chain. This can not HURT anyone using the alias/remailer system because you never need to know what your aliases are as the conversion and forwarding process is automatic. If someone needs, for some reason to KNOW his alias for a given system (or all of them) on *his/her* chain, he/she can easily arrange to ping the server at the appropriate level. Besides not hurting any current operations, Stopping the *automatic* reply to sender about a new alias helps to secure everything a great deal more because it hides the "other guy's" chain, something that both parties might reasonably expect. matthew rapaport Philosopher/Programmer At Large KD6KVH mjr at netcom.com 70371.255 at compuserve.com From edgar at spectrx.Saigon.COM Sat Jan 9 14:58:45 1993 From: edgar at spectrx.Saigon.COM (Edgar W. Swank) Date: Sat, 9 Jan 93 14:58:45 PST Subject: Trailing blanks in signed plaintext Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Distribution: Cypherpunks Branko Lankester I noticed something about PGP signed plaintext the last time used that feature to send a message to Cypherpunks. Apparently PGP takes any line beginning with 5 dashes ("-----") and adds "- " (dash blank) to it. I guess the purpose for this is to avoid confusion if the plaintext message should contain a PGP delimiter like -----BEGIN PGP SIGNATURE----- But in my particular case, what I specified in my input plaintext was -----END OF MESSAGE BODY----- (but with no indentation), but what came out was - -----END OF MESSAGE BODY----- Given that PGP is going to make changes like this to signed plaintext, I suggest there is no longer any reason to object if PGP also removes trailing blanks from signed plaintext. -----BEGIN PGP SIGNATURE----- Version: 2.1 iQCVAgUBK02ta94nNf3ah8DHAQFX8wP/dyusrml+2XH7XQtFcsQveGW3Zz3ib6K9 xGGV2hnvhwIHbFs4HIKTIVT0BFR6Y4SuqFMeF0BS16FIu47GmW8Q55iIhweDP7x5 +CUMXSynwQsz4XOMU/CpqNAwJifNoM9BwNu+RqfhIxwi6KxO1i3FwJjxPzE+uHkh Y7Mjl7Ytkd0= =0l/6 -----END PGP SIGNATURE----- -- edgar at spectrx.saigon.com (Edgar W. Swank) SPECTROX SYSTEMS +1.408.252.1005 Silicon Valley, Ca From edgar at spectrx.Saigon.COM Sat Jan 9 15:00:34 1993 From: edgar at spectrx.Saigon.COM (Edgar W. Swank) Date: Sat, 9 Jan 93 15:00:34 PST Subject: Delimiting text body in ARA Message-ID: On Jan 5, Hal commented on my suggestions for ARA using a Miron Cuperman remailer. > I'd also like to suggest that the message- body to > be encrypted require heading and trailing > delimiters such as: > > -----BEGIN MESSAGE BODY----- > -----END MESSAGE BODY----- > > Note delimiters would not be part of message body > and would not be encrypted. These anonymous addresses do need a distinction between the "message address" (or "envelope") and the message body. The anonymous address gets decrypted at each step, and the message body gets encrypted at each step using the scheme above. But Eric Hughes pointed out that we already have such a distinction in the RFC822 message headers vs body. We should use that existing structure rather than try to create our own. That means that anonymous addresses should be designed to fit into mail headers. Unfortunately many mail agents make this difficult or inconvenient right now, but perhaps that is an area where we could make some improvements. In this model, we would not need message body delimiters, since mail already has its message body delimited distinct from its headers. I think "many mail agents" at least the one at this location, make it downright impossible to put an ARA into the header. Especially a chained ARA, which is part address and part body (to all except the last remailer in the chain). I think we are better off writing tools which will work now on the worst common denominator of mailers, rather than insisting that the world change so our solutions can be more elegant. Note that the user of an ARA is likely to be less computer & e-mail literate than the person he is responding to. It's easy to specify, to reply, mail to the [first remailer address]. Put this encrypted ARA block first in your message body, followed by your reply message enclosed in -----BEGIN MESSAGE BODY----- -----END MESSAGE BODY----- Only the text between these two delimiter lines will be received by the original sender, so your anonymity will be protected too. Note that this elegantly takes care of discarding the automatic sig of the responder, if any. Some here, like Richard Childers, don't want to protect users who might not understand that they need to suppress their automatic sig to maintain their anonymity with a remailer. People who run remailers have to be pretty gutsy anyway. They may get sued by disgruntled recipients of abusive or threatening anon msgs. It seems to me they don't also need to risk being sued by disgruntled message senders (or responders) who are embarassed (or worse) by inadvertantly revealing their identity in what they intended as an anonymous message. Note that your average civil jury is not going to be terribly computer-literate. Even a suit which loses is going to cost a lot to defend against. As to Hal's other suggestion: If we do process the message body with encryption at each stage, I do have an idea which could be useful. If the body which is being encrypted is already in the format of an ASCII-encoded message using the standard RFC822 encryption used in PGP, RIPEM and PEM, then rather than just encrypting it it could be de-ASCII'd, then encrypted, then re-ASCII'd. This would keep it from increasing in size by a factor of 4/3 at each encryption step. Sound's like a good idea, but it's not going to save anywhere near 1/3 (4/3 - 1), at least with PGP, since (recall) PGP (at least by default) compresses before it encrypts. -- edgar at spectrx.saigon.com (Edgar W. Swank) SPECTROX SYSTEMS +1.408.252.1005 Silicon Valley, Ca From 74076.1041 at CompuServe.COM Sat Jan 9 15:33:30 1993 From: 74076.1041 at CompuServe.COM (Hal) Date: Sat, 9 Jan 93 15:33:30 PST Subject: Cascading aliases Message-ID: <930109232813_74076.1041_DHJ76-1@CompuServe.COM> I think Matthew Rapaport's point is good that much of the trouble with the automatic assignment of aliases comes from the automatic mailing to the user of a new alias. Most of the remailing servers have a special address or command you can send meaning "assign me a new alias, and tell me what it is". Probably, as Matthew says, they should only mail back the newly assigned alias when one of these special commands is used. I'm still not convinced that automatic alias assignment should always be done when mail goes through a server from a new address. It seems like this might generate so many aliases that it would be too great a load on the servers, especially if remailers become more widely used. But it's hard to say how bad a problem this is. I feel that the main purpose of an anonymous address is to protect the anonymity of the person being addressed, not people who send to him. Just because a person chooses to be anonymous is no reason to expect that everyone who wants to talk to him also wants to be anonymous. I think it would be better to only provide anonymity when asked. Systems that do too much for people sometimes get in the way. Hal Finney 74076.1041 at compuserve.com Distribution: Cypherpunks >INTERNET:cypherpunks at toad.com From 74076.1041 at CompuServe.COM Sat Jan 9 17:12:59 1993 From: 74076.1041 at CompuServe.COM (Hal) Date: Sat, 9 Jan 93 17:12:59 PST Subject: Trailing blanks in PGP Message-ID: <930110010447_74076.1041_DHJ70-1@CompuServe.COM> Edgar points out that PGP prepends a "- " string to every line that starts with "-", and suggests that it would not be much further to go to strip trailing blanks. While I sympathize with the problems Edgar and others have with trailing blanks messing up signature checking, it turns out that the "- " quoting is done at a different stage of the processing than signature checking. When a signed message is created, it is first "canonicalized", which presently means only that each line is made to end with a carriage return line feed. The signature is then calculated on this form. For the cleartext signature, the message is then wrapped in the "-----BEGIN PGP MESSAGE-----" lines, and the quoting of lines starting with "-" is done. As Edgar surmises, this quoting is so that the end of the message can be accurately located, even if the message contains lines like "-----END PGP MESSAGE-----". On the receiving end, the message is first stripped of the -----BEGIN and -----END lines, and the "-" quoting is undone. The resulting message is then canonicalized (so that lines end with CRLF's) and the signature is calculated and checked against that sent with the message. Space stripping could be done fairly easily in the "unwrapping" process, along with the "-" de-quoting, as Edgar suggests. But it would still fail if the user signed a message which ended a line with a blank. In fact, if he ever did sign such a message, and the de-quoting routine were enhanced to strip trailing blanks, the message would always fail the signature check, because that necessary trailing blank will be gone. What really needs to be done is to change the definition of a "canonical text" message. Presently it only specifies CRLF line terminators. It would have to be enhanced to specify also that no spaces precede any CRLF. If this were done, then the canonicalizing process done at both ends would strip the trailing blanks before calculating the signature, and therefore trailing blanks would not affect the signature check. Presently, PGP "knows" that on a PC, canonical text form is the same as regular text form. That is because CRLF is the normal line terminator on a PC. So, canonicalizing is skipped on the PC, which speeds up signing and verification on this class of machines, which include some of the slowest on which PGP is run. Adding blank-stripping to the definition of canonical text means that all messages will have to be canonicalized on PC's, thus adding an extra processing pass which is avoided now. So there is some cost in doing this. There are also some compatibility problems, in that old signed messages which had trailing blanks would no longer signature-verify if we changed the definition of canonical text in this way. However, there probably aren't that many such messages, so this may be a tolerable cost. I do think we should consider making this change, as many people have complained about it. Hal Finney 74076.1041 at compuserve.com Distribution: Cypherpunks >INTERNET:cypherpunks at toad.com From norm at netcom.com Sat Jan 9 17:52:25 1993 From: norm at netcom.com (Norman Hardy) Date: Sat, 9 Jan 93 17:52:25 PST Subject: Politics of Rmailers Message-ID: <9301100152.AA02289@netcom2.netcom.com> Theodore Ts'o writes: If your mail system is broken enough that it inserts signatures without your permission, and you have no way to controlling it, it's broken. End of statement. Fix it or ditch it. I can imagine a system administrator choosing to require that all mail originating from his machine include a signature that correctly identifies the local name of the sender. I make this special point to illustrate a broader problem with remailers: They require operators of remailers to be sympathetic with the ends of the users of remailers. This obviously does not include the entire population for at least the recipient is not sympathetic. I suspect that technical solutions sought in recent mail will founder in presence of the politics of the operators of the remailers. I understand that routing your message thru at least one "friendly" remailer may be enough but if your reasons for using remailers are not sufficiently popular, then society, in some form, will pressure the friendly remailers to betray the sender without advance warning. If society polarizes into camps then there may be remailers in each camp. A remailer in one camp is unlikely to service messages from the other. Barriers then arise. I think that the technical issues are only the tip of the iceberg. From mjr at netcom.com Sat Jan 9 21:21:39 1993 From: mjr at netcom.com (Matthew Rapaport) Date: Sat, 9 Jan 93 21:21:39 PST Subject: Politics of Rmailers Message-ID: <9301100521.AA28337@netcom2.netcom.com> ***** norm at netcom.com (Norman Hardy) ***** >I can imagine a system administrator choosing to require that >all mail originating from his machine include a signature that >correctly identifies the local name of the sender. I can too, but I suspect they wouldn't last long, particularly if they were commercial systems and their paying users felt that the anonymity option was something to be desired. I worry about institutional constraints much more, particularly at the national level "All machines on the Internet in this country will insure that mail originators are identified...", etc. Even this can be overcome technically though (smarter signature strippers). >This obviously does not include the entire population for at least the >recipient is not sympathetic. This isn't necessarily so. I can appreciate some other person's desire to remain anonymous in certain kinds of transactions. Also, people in other parts of the world seem much more sensitive to issues of privacy then we here in the US tend to be. >If society polarizes into camps then there may be remailers in >each camp. A remailer in one camp is unlikely to service messages >from the other. Well maybe, but this goes against the philosophical, political, and technical grain of the International Internet as it now exists. I note that the world already *is* polarized into camps to a greater or lesser extent. If there is eventual political and social fallout from the use of alias remailers, I think it would be more of an us (the Internet community who use remailers) vs. them (everyone else) kind of thing. I have detected murmurs of dislike for people who use remailers just on general principles (i.e. you should take responsibility for what you say). matthew rapaport Philosopher/Programmer At Large KD6KVH mjr at netcom.com 70371.255 at compuserve.com From tribble at xanadu.com Sat Jan 9 23:56:11 1993 From: tribble at xanadu.com (E. Dean Tribble) Date: Sat, 9 Jan 93 23:56:11 PST Subject: Politics of Rmailers In-Reply-To: <9301100152.AA02289@netcom2.netcom.com> Message-ID: <9301100732.AA10236@xanadu.xanadu.com> Date: Sat, 9 Jan 93 17:52:01 -0800 From: uunet!netcom.com!norm (Norman Hardy) I can imagine a system administrator choosing to require that all mail originating from his machine include a signature that correctly identifies the local name of the sender. I can imagine it, but none exist. This is mostly because the From: field is supplied by the mailer and satisfies that requirement, whereas requiring things in teh body of the mail message goes against the grain of how the systems are used. remailers: They require operators of remailers to be sympathetic with the ends of the users of remailers. This obviously does not Are there other reasons to use a remailer besides anonymity? I can't think of any, so that solves the sympathy problem. If a remailer operator conspires to reveal who you are that's a different issue, and is solved (or reduced a lot) by using a chain of remailers. Then *all* of the remailers have to be compromised to reveal that connection from source to destination. dean From tribble at xanadu.com Sat Jan 9 23:56:14 1993 From: tribble at xanadu.com (E. Dean Tribble) Date: Sat, 9 Jan 93 23:56:14 PST Subject: Politics of Rmailers In-Reply-To: <9301100152.AA02289@netcom2.netcom.com> Message-ID: <9301100731.AA10229@xanadu.xanadu.com> Date: Sat, 9 Jan 93 17:52:01 -0800 From: uunet!netcom.com!norm (Norman Hardy) I can imagine a system administrator choosing to require that all mail originating from his machine include a signature that correctly identifies the local name of the sender. I can imagine it, but none exist. This is mostly because the From: field is supplied by the mailer and satisfies that requirement, whereas requiring things in teh body of the mail message goes against the grain of how the systems are used. remailers: They require operators of remailers to be sympathetic with the ends of the users of remailers. This obviously does not Are there other reasons to use a remailer besides anonymity? I can't think of any, so that solves the sympathy problem. If a remailer operator conspires to reveal who you are that's a different issue, and is solved (or reduced a lot) by using a chain of remailers. Then *all* of the remailers have to be compromised to reveal that connection from source to destination. dean From julf at penet.FI Sun Jan 10 00:45:29 1993 From: julf at penet.FI (Johan Helsingius) Date: Sun, 10 Jan 93 00:45:29 PST Subject: Cascading aliases In-Reply-To: <930109232813_74076.1041_DHJ76-1@CompuServe.COM> Message-ID: <9301101022.aa17715@penet.penet.FI> Hal Finney writes: > I feel that the main purpose of an anonymous address is to protect the > anonymity of the person being addressed, not people who send to him. Just > because a person chooses to be anonymous is no reason to expect that > everyone who wants to talk to him also wants to be anonymous. I think it > would be better to only provide anonymity when asked. Systems that do too > much for people sometimes get in the way. Well, yeeeeesss... but.... It all depends on the intended target audience. If our users are pretty sophisticated netfreaks, I agree that the philosophy of the system ought to be "only do what the user asks for". But if the users are non-computer-literate people, seeking a source of support and understanding in this vast mess of e-mail and netnews, I feel they need and deserve all the hand-holding and safety switches the software can provide. So it seems there is room and need for *different* remailers. Julf From mjr at netcom.com Sun Jan 10 08:02:07 1993 From: mjr at netcom.com (Matthew Rapaport) Date: Sun, 10 Jan 93 08:02:07 PST Subject: Cascading-Automatic aliases Message-ID: <9301101601.AA03100@netcom2.netcom.com> Hal Finney: > I think it would be better to only provide anonymity when asked. Johan Helsingius: > It all depends on the intended target audience. I have to agree with Johan here, and with the way all (?) the Aserver creators/administrators have chosen to go. Consider the following scenarios, assuming that Person-X does not know anything about the particulars of the Aserver(s) he/she is routed through when making a direct *reply* to an anonymous message. A) Person-X doesn't care if he/she is aliased when he/she replies, but he/she is aliased anyway. consequence: Not much, the message still gets through (as would a re-reply, so if the Person-X *wants* to make his/her identity known later he/she can always state it in a message body). B) Person-X *wants* to be aliased in his/her reply, but *isn't* because the Aserver doesn't do it automatically, and person-X isn't aware that such a "switch" needs to be thrown. consequence: Potentially disasterous to person-X! I submit that automatic aliasing, by default, is consistent with the very purpose of Aservers, more exactly their intended, legitimate, uses! This doesn't mean that Aliasing software shouldn't contain some provision for turning ON a switch that passes you through un-aliased, but this switch should be for users who KNOW the server and how to modify its default behavior. I wouldn't object to such a switch, but personally I don't see much use for it either. Once I knew I wanted to reveal myself to someone, I could just tell him/her in a message body. If they want to reveal themselves to me, they can do likewise, and then we can address each other's machines directly, bypassing the Aserver(s). Now if these same creators/administrators would only *turn off* the automatic (default) message saying: "An alias [ALIAS####] has been created for you on Aserver at somewhere.in.the.world" the privacy of what seems to be a growing, potential, aliasing network (Anetwork) would be significantly enhanced. Reversing the default here would be consistent with the "most conservative assumption" approach otherwise already taken with respect to auto-alias. matthew rapaport Philosopher/Programmer At Large KD6KVH mjr at netcom.com 70371.255 at compuserve.com From crys at eith.biostr.washington.edu Sun Jan 10 08:22:48 1993 From: crys at eith.biostr.washington.edu (Crys Rides) Date: Sun, 10 Jan 93 08:22:48 PST Subject: Politics of Rmailers In-Reply-To: <9301100152.AA02289@netcom2.netcom.com> Message-ID: <9301101621.AA12728@ucunix.san.uc.edu> >>>>> On Sat, 9 Jan 93 23:32:18 PST, tribble at xanadu.com (E. Dean Tribble) said: E.> Date: Sat, 9 Jan 93 17:52:01 -0800 E.> From: uunet!netcom.com!norm (Norman Hardy) E.> I can imagine a system administrator choosing to require that E.> all mail originating from his machine include a signature that E.> correctly identifies the local name of the sender. E.> I can imagine it, but none exist. This is mostly because the From: ^^^^^^^^^^^ E.> field is supplied by the mailer and satisfies that requirement, E.> whereas requiring things in teh body of the mail message goes against E.> the grain of how the systems are used. *Bzzzzt* Wrong answer, thank you for playing. The public access bbs system running out of Chapel Hill, automatically appends the same signature to all outgoing messages, and other sites are considering the same measures. CrysRides From nowhere at bsu-cs.bsu.edu Sun Jan 10 17:33:05 1993 From: nowhere at bsu-cs.bsu.edu (Chael Hall) Date: Sun, 10 Jan 93 17:33:05 PST Subject: Politics of Rmailers In-Reply-To: <9301101621.AA12728@ucunix.san.uc.edu> Message-ID: <9301110129.AA09743@bsu-cs.bsu.edu> >E.> I can imagine it, but none exist. This is mostly because the From: > ^^^^^^^^^^^ >E.> field is supplied by the mailer and satisfies that requirement, >E.> whereas requiring things in teh body of the mail message goes against >E.> the grain of how the systems are used. >*Bzzzzt* Wrong answer, thank you for playing. The public access bbs >system running out of Chapel Hill, automatically appends the same signature >to all outgoing messages, and other sites are considering the same measures. I think what he's saying is that a signature that identifies which *user* on the system as well as the system name does not exist. I'm sure there are a couple, but I agree with your point that most BBS's on any mail network append an identifying "tagline" or signature. As a matter of fact, in many nets it is a requirement that your system append a tagline to all messages. Incidentally, it is preceded often by "--" on a line by itself. Chael Hall -- Chael Hall nowhere at bsu-cs.bsu.edu, 00CCHALL at LEO.BSUVC.BSU.EDU, CHALL at CLSV.Charon.BSU.Edu (317) 285-3648 after 3 pm EST From crys at eith.biostr.washington.edu Sun Jan 10 17:44:13 1993 From: crys at eith.biostr.washington.edu (Crys Rides) Date: Sun, 10 Jan 93 17:44:13 PST Subject: Politics of Rmailers In-Reply-To: <9301101621.AA12728@ucunix.san.uc.edu> Message-ID: <9301110143.AA15332@ucunix.san.uc.edu> >>>>> On Sun, 10 Jan 93 20:29:47 EST, nowhere at bsu-cs.bsu.edu (Chael Hall) said: >E.> I can imagine it, but none exist. This is mostly because the From: > ^^^^^^^^^^^ >E.> field is supplied by the mailer and satisfies that requirement, >E.> whereas requiring things in teh body of the mail message goes against >E.> the grain of how the systems are used. >*Bzzzzt* Wrong answer, thank you for playing. The public access bbs >system running out of Chapel Hill, automatically appends the same signature >to all outgoing messages, and other sites are considering the same measures. Chael> I think what he's saying is that a signature that identifies which Chael> *user* on the system as well as the system name does not exist. I'm Chael> sure there are a couple, but I agree with your point that most BBS's on Chael> any mail network append an identifying "tagline" or signature. As a Chael> matter of fact, in many nets it is a requirement that your system append Chael> a tagline to all messages. Incidentally, it is preceded often by "--" Chael> on a line by itself. Evidently I mis-interpreted his exact meaning in his statement, but if I remember correctly, wasn't one of the original mail messages along this line stating that any mail system which included a signature or identification automatically was broken? The point being is this is a common example of how this is used, and that if an anonymous poster comes from such a site, his sig would close the search area greatly if not removed. So this appears to me to be a good point in favor of signature stripping. Chael> Chael Hall Chael> -- Chael> Chael Hall Chael> nowhere at bsu-cs.bsu.edu, 00CCHALL at LEO.BSUVC.BSU.EDU, CHALL at CLSV.Charon.BSU.Edu Chael> (317) 285-3648 after 3 pm EST CrysRides From nowhere at bsu-cs.bsu.edu Sun Jan 10 20:22:10 1993 From: nowhere at bsu-cs.bsu.edu (Chael Hall) Date: Sun, 10 Jan 93 20:22:10 PST Subject: Politics of Remailers In-Reply-To: <9301110143.AA15332@ucunix.san.uc.edu> Message-ID: <9301110419.AA14032@bsu-cs.bsu.edu> >Evidently I mis-interpreted his exact meaning in his statement, but if I >remember correctly, wasn't one of the original mail messages along this line >stating that any mail system which included a signature or identification >automatically was broken? The point being is this is a common example >of how this is used, and that if an anonymous poster comes from such a site, >his sig would close the search area greatly if not removed. So this >appears to me to be a good point in favor of signature stripping. > >CrysRides True, it will make tracing the mail extremely simple if nothing is done to strip the signature out. Where I disagree is where Hal appears to disagree--it is too simple to accidentally cut off the rest of your message by putting a line starting with "--" in your message. I think a "kill line" would be best. Anything after that line is ignored. Chael -- Chael Hall nowhere at bsu-cs.bsu.edu, 00CCHALL at LEO.BSUVC.BSU.EDU, CHALL at CLSV.Charon.BSU.Edu (317) 285-3648 after 3 pm EST From barrus at tree.egr.uh.edu Sun Jan 10 21:42:51 1993 From: barrus at tree.egr.uh.edu (Karl L. Barrus) Date: Sun, 10 Jan 93 21:42:51 PST Subject: No Subject Message-ID: <9301110542.AA20105@tree.egr.uh.edu> Hal <74076.1041 at compuserve.com> said: >My understanding was that everyone who tried to talk to him would get >two aliases assigned automatically. Actually, what I expected to happen was this: the acknowledgement of an anonymous id on penet for the anonymous id on pax would be generated, and this ack would be sent via the chain back to me (barrus at tree) since I established the chain. That is, I had linked anon.435 at pax to an5022 at penet to barrus at tree. Then, upon mailing to anon.435 at pax from my other account (which already has an anonymous id established, so another would not be generated), the mail would proceed to an5022 at penet, which would create an id and send it back to anon.435 at pax. Now I expected this ack to then be turned right around, send to an5022 at penet and then on to barrus at tree. So I was expecting the creation of another anonymous id, but the acknowledgement didn't go to barrus at tree. My original thinking was that once I established the id's in both direction, when someone responded to anon.435 at pax, they would be allocated an id if they didn't have one. And since penet had by this time seen anon.435 at pax, no new id would be made, and the mail would proceed on the me. Anyway, that was an experiment that seems to lead to explosive anonymous id growth :-) I agree with Matthew that not mailing back an ack would help cut down the flurry of mail, but it still results in all sorts of extra id's. I was hoping the whole thing would be like a pointer: mail to id1 at pax forwards to id2 at penet and then on to me with no extraneous account manufactured. But since we have our own cryptographically protected remailers, we cypherpunks can make our own remailing chains (Hal's constructed anonymous addresses). This way, you can decided on the path of your outgoing mail and your return mail: create the appropriate header, and attach your message on the end. To receive responses, just send a response header with the return path encrypted along with instructions to your recipient to cut the response header into a new file, add a message to the bottom, and mail to the appropriate remailer. (Note: I've used this method successfully twice, so it isn't too hard to do). Just remember that if your recipient doesn't have pgp, don't route your mail through extropia or their message will be blocked. If I get a chance I'll work on a program that will generate the appropriate header given routing input. /-----------------------------------\ | Karl L. Barrus | | barrus at tree.egr.uh.edu (NeXTMail) | | elee9sf at menudo.uh.edu | \-----------------------------------/ From tribble at xanadu.com Sun Jan 10 22:30:05 1993 From: tribble at xanadu.com (E. Dean Tribble) Date: Sun, 10 Jan 93 22:30:05 PST Subject: both stripping and not Message-ID: <9301110551.AA14300@xanadu.xanadu.com> With even current remailer architectures, it's trivial to simply have different services for normal remailing (which leaves body intact) and stripping services that grundge the message arbitrarily. When we really want anonymity, for instance, we will need message rewriting services that break the correlation between authors and writing style. A friend of mine looked into that material and claims that such analysis can do a depressingly good job at figuring out what messages were written byt he same author, even if the author tries to stilt his style. dean From tribble at xanadu.com Sun Jan 10 22:30:18 1993 From: tribble at xanadu.com (E. Dean Tribble) Date: Sun, 10 Jan 93 22:30:18 PST Subject: Politics of Rmailers In-Reply-To: <9301110143.AA15332@ucunix.san.uc.edu> Message-ID: <9301110548.AA14295@xanadu.xanadu.com> >E.> I can imagine it, but none exist. This is mostly because the From: > ^^^^^^^^^^^ >*Bzzzzt* Wrong answer, thank you for playing. The public access bbs Yes. Absolutes are almost always wrong. I've never encountered such a system, however. Chael> I think what he's saying is that a signature that identifies which Chael> *user* on the system as well as the system name does not exist. I'm There are lots of mailers that add the X-Organization: field, or some such. Evidently I mis-interpreted his exact meaning in his statement, but if I Now now. No need to be too sarcastic. :-) dean From 74076.1041 at CompuServe.COM Mon Jan 11 09:03:28 1993 From: 74076.1041 at CompuServe.COM (Hal) Date: Mon, 11 Jan 93 09:03:28 PST Subject: Chaining Pax and Penet. Message-ID: <930111164804_74076.1041_DHJ37-1@CompuServe.COM> -----BEGIN PGP SIGNED MESSAGE----- From: Karl L. Barrus > My original thinking was that once I established the id's in both > direction, when someone responded to anon.435 at pax, they would be > allocated an id if they didn't have one. And since penet had by this > time seen anon.435 at pax, no new id would be made, and the mail would > proceed on the me. The problem is this: when someone responds to your anonymous ID anon.435 at pax, their mail _from_ Pax does not come from anon.435. Anon.435 is _your_ id. Instead, their mail from Pax comes from their own anonymous ID (possibly a newly allocated one). Then, when the mail goes to Penet, it sees this new "From" ID and allocates one of its own. The same thing happened when you sent to anon.435 at pax from your system which already had a Pax ID. When the mail was forwarded from Pax to Penet, it was not marked as coming from anon.435. Instead, it was marked as coming from this already-assigned Pax ID. (I don't think you ever said what that already-assigned ID was.) Penet had not seen that ID before, so it allocated an alias for it and sent back to that ID. Penet's mail-back would _not_ go to anon.435, but rather to the Pax ID which it was replying to. Hal -----BEGIN PGP SIGNATURE----- Version: 2.1 iQCVAgUBK1F6D6gTA69YIUw3AQGMTAQAqXm7SdE6uyf+04J5GY3KU7dk7A2D7loC TeT+0UqpsSPOI+31YrJPww2h9XuwGylAZ9dqu/hPdolIzukjr+WiOKRyU34imezd iX9yYv3Ry3jCebcn9c79NY3zEQhjGh1LhqKmec5QLp3FjPB+gQZZypdaHz4GeDJF 4oDyArzKafc= =wZgY -----END PGP SIGNATURE----- Distribution: CYPHERPUNKS >INTERNET:CYPHERPUNKS at TOAD.COM From 74076.1041 at CompuServe.COM Mon Jan 11 09:03:59 1993 From: 74076.1041 at CompuServe.COM (Hal) Date: Mon, 11 Jan 93 09:03:59 PST Subject: .Sig suppression Message-ID: <930111164833_74076.1041_DHJ37-2@CompuServe.COM> -----BEGIN PGP SIGNED MESSAGE----- Chael> I'm Chael> sure there are a couple, but I agree with your point that most BBS's on Chael> any mail network append an identifying "tagline" or signature. As a Chael> matter of fact, in many nets it is a requirement that your system append Chael> a tagline to all messages. Incidentally, it is preceded often by "--" Chael> on a line by itself. I'd like to hear more about systems which do this. What is the rationale for adding the system name at the end? Do these networks not use Internet-style "From:" headers, so these automatic system-wide .sigs are used for the same effect? I guess there must be gateways between these bbs's and the internet, for this issue to arise. It's too bad that these gateways don't convert the .sig info into a more conventional RFC-822 style Internet header. Hal Finney -----BEGIN PGP SIGNATURE----- Version: 2.1 iQCVAgUBK1F586gTA69YIUw3AQFNogP9FU2W3wrHTnfrZeKtrMOq4Zz5aTUN7+vv 04iMOdV975fCzqdmgR7O758qamewguYV8XHmPVloLSMwgnmbzBNs8zRZkVAwTKnB rpQqeahXPNeC1PVu/ezoiBvc26ujcN2Ga9OuGUWu9RFRvjwQ0rl51mTjHED1fJi+ 7I/TV4kT4Kk= =WeLq -----END PGP SIGNATURE----- Distribution: CYPHERPUNKS >INTERNET:CYPHERPUNKS at TOAD.COM From ASTMWILL%STETSON.bitnet at CUNYVM.CUNY.EDU Mon Jan 11 11:02:02 1993 From: ASTMWILL%STETSON.bitnet at CUNYVM.CUNY.EDU (Matt Willis) Date: Mon, 11 Jan 93 11:02:02 PST Subject: Commie's Message-ID: <01GT8HKCAJFK0004WU@stetson.bitnet> To this southern boy, it looks like the pinkos are slamming American (whoops, sorry, English) programming... :) "pgp in actual use is not recommended.", oh yeah, well our alphabet has more characters, so there... There were some interesting flaws that they pointed out... Could someone do a follow up and say what has been fixed in PGP version 2.1? If pgp cyphertext/encrypted data is predictable, I wonder how that would affect the "it'd take a Cray a year" figure? (or were the pinkos being overconfident) I actually like the Russians, but I'm just fulfilling my stereotype. peace :* +-------Matt-Willis--------------------------------+ | Matt Willis ASTMWILL at STETSON.BITNET | elsewhere: | Matt Willis Head of the Underground | mwill at mindvox.phantom.com | Matt Willis Robotech PBM List | +-------Matt-Willis--------------------------------+ "Absolutely alone in awareness of the mechanism." -Agrippa by WG From ccat at netcom.com Mon Jan 11 12:03:17 1993 From: ccat at netcom.com (Chris Beaumont) Date: Mon, 11 Jan 93 12:03:17 PST Subject: Atari PGP -is it available.. Message-ID: <9301112002.AA13654@netcom2.netcom.com> Does anyone know if there is a current version of PGP available for the Atari ST. Thanks! From rchilder at us.oracle.com Mon Jan 11 12:11:31 1993 From: rchilder at us.oracle.com (Richard Childers) Date: Mon, 11 Jan 93 12:11:31 PST Subject: request digest format Message-ID: <9301112009.AA14251@rchilder.us.oracle.com> When is this going to be converted into a Digest format ? Without wishing to appear peckish, Christmas would have been a good opportunity ... -- richard ===== -- richard childers rchilder at us.oracle.com 1 415 506 2411 oracle data center -- unix systems & network administration ... whatever remains, however improbable, must be the truth. From barrus at tree.egr.uh.edu Mon Jan 11 13:03:35 1993 From: barrus at tree.egr.uh.edu (Karl L. Barrus) Date: Mon, 11 Jan 93 13:03:35 PST Subject: constructed anonymous addresses Message-ID: <9301112102.AA23795@tree.egr.uh.edu> Had sort of a slow day at work, so I had the chance to crank out this: Here is a rough script which will allow you to route your mail through the various remailers. (However, extropia is not yet supported...I'm working on it). You must have the public key for each remailer on your keyring. Save the file, run it, and it will prompt for 1) mail, or 2) header. Choose 1 to pick a path and send a file, choose 2 to create a header which can be used to reach you. I intend option 2 to be used as follows: create a message to someone you want to remain anonymous from, run the script, pick 2, follow the prompts, and then instruct the script to append the header to your letter. Then your recipient will be able to follow the directions and respond to you. When the script prompts for "And then to (1-3 or address)", to end the process, type the final address you want your mail sent to. Of course, if you are creating a header, you'll want to type your own address. Further improvements include supporting extropia; and rewriting in C, perl, awk, ksh, or any language with arrays! I've tested this script using the remailers at alumni and rosebud, because the turnaround time seems faster. But there is no reason that rebma shouldn't work as well. --------8<--cut here-->8-------- #!/bin/sh # support script for anonymous remailers # allows routing a message through various remailers # NOTE: extropia remailer not supported just yet #find out which mode user wants echo "Do you want to:" echo "1. Create routing and mail a file" echo " This will allow you to specify the route your message will take," echo " and mail a file through that route." echo "2. Create remailing header" echo " This creates an appropriate remailing header, with instructions." echo " Include the generated file in one of your own messages and" echo " someone else can use it to reply to you." read choice #declare remailers mail1=hal at alumni.caltech.edu mail2=remailer at rebma.mn.org mail3=elee7h5 at rosebud.ee.uh.edu mail4=remail at extropia.wimsey.com #temporary files t1=.anon1 t2=.anon2 t3=.anon3 #set up header echo "::" > $t1 echo "Encrypted: PGP" >> $t1 echo "" >> $t1 #blank out .anon3 cat /dev/null > $t3 #print menu echo "" echo "1) $mail1" echo "2) $mail2" echo "3) $mail3" #echo "4) $mail4" echo "" #get hop echo "Mail to (1-3): " read to #convert from number to address if [ $to = "1" ] then to=$mail1 elif [ $to = "2" ] then to=$mail2 else to=$mail3 fi firsthop=$to notdone=true #begin loop while [ $notdone ] do #find out remailing request echo "And then to (1-3 or address): " read rto if [ $rto = "1" ] then rto=$mail1 elif [ $rto = "2" ] then rto=$mail2 elif [ $rto = "3" ] then rto=$mail3 fi echo "::" > $t2 echo "Request-Remailing-To: $rto" >> $t2 echo "" >> $t2 # echo "remailing to $rto; encrypted for $to" pgp -ea $t2 $to 2> /dev/null cat $t1 $t2.asc >> $t3 if [ $rto = $mail1 -o $rto = $mail2 -o $rto = $mail3 ] then to=$rto else notdone="" fi done if [ $choice = "1" ] then #now include message echo "Message to include? " read msg if [ ! -f $msg ] then echo "$msg not found" exit 1 fi cat $msg >> $t3 elm -s "anonymous mail" $firsthop < $t3 else echo "Append to file: " read msg echo "--------8<--cut here-->8--------" >> $msg cat $t3 >> $msg echo "" >> $msg echo "> $msg echo "> $msg echo "> $msg fi rm -rf $t1 $t1.asc $t2 $t2.asc #end of script---------------------------- /-----------------------------------\ | Karl L. Barrus | | barrus at tree.egr.uh.edu (NeXTMail) | | elee9sf at menudo.uh.edu | \-----------------------------------/ From nowhere at bsu-cs.bsu.edu Mon Jan 11 13:42:36 1993 From: nowhere at bsu-cs.bsu.edu (Chael Hall) Date: Mon, 11 Jan 93 13:42:36 PST Subject: .Sig suppression In-Reply-To: <930111164833_74076.1041_DHJ37-2@CompuServe.COM> Message-ID: <9301112135.AA21344@bsu-cs.bsu.edu> >Chael> I'm >Chael> sure there are a couple, but I agree with your point that most BBS's on >Chael> any mail network append an identifying "tagline" or signature. As a >Chael> matter of fact, in many nets it is a requirement that your system append >Chael> a tagline to all messages. Incidentally, it is preceded often by "--" >Chael> on a line by itself. > >I'd like to hear more about systems which do this. What is the rationale >for adding the system name at the end? Do these networks not use >Internet-style "From:" headers, so these automatic system-wide .sigs are >used for the same effect? The reason why they were created (IMHO) was because most PC-based BBS software only allows for a very limited space in the header for a From name and for a To name. For example, in ChaelBoard, a BBS package that I wrote, this limitation is 31 characters (in order to make the string 32 bytes long). Therefore, only names are used. This gets ambiguous if two John Smith's are sending messages to the same conference (similar to newsgroups). So, the systems started appending a line stating the origin of the message. Sometimes it's as simple as "X BBS - (222) 222-2222 Smalltown, USA" Other times it's more complex. Some nets have decided upon a specific type of tagline so that they all contain the same information in the same format. Usually they contain the phone number. RelayNet(tm) and other popular nets provide for "Receiver-only, Routed" messages. That is, the message is considered private and sent from your system to a hub and that hub only sends it on to other hubs or the appropriate node if it is connected to that hub. Unfortunately, every SYSOP between your system and the receiving system can read the message. That's why encryption is important. >I guess there must be gateways between these bbs's and the internet, >for this issue to arise. It's too bad that these gateways don't convert >the .sig info into a more conventional RFC-822 style Internet header. Yes, gateways exist for many systems. Most consider the tagline a part of the message. The de facto standard is to consider "--" on a line by itself to mark the end of the message body and the beginning of the tagline. Users often append their own tagline before the system tagline. Each mail reader has its own format, usually including the name of the program on the line. Chael Hall -- Chael Hall nowhere at bsu-cs.bsu.edu, 00CCHALL at LEO.BSUVC.BSU.EDU, CHALL at CLSV.Charon.BSU.Edu (317) 285-3648 after 3 pm EST From mjr at netcom.com Mon Jan 11 16:09:41 1993 From: mjr at netcom.com (Matthew Rapaport) Date: Mon, 11 Jan 93 16:09:41 PST Subject: multiple aliases. It doesn't matter how many Message-ID: <9301112219.AA25430@netcom2.netcom.com> ***** Karl L. Barrus ***** >I agree with Matthew that not mailing back an ack would help cut down >the flurry of mail, but it still results in all sorts of extra id's. Yes, but so what? That is, why does it matter so long as all the conversion from one to the next takes place automatically. The process strengthens your security as well as that of any respondent. True this may not be necessary, but under the circumstances (the whole point of alias servers) isn't a "lets not take chances" approach best? Lets take an extreme case (not that I'm suggesting things be implemented this way). Imagine that every time you or anyone else originates mail through an Aserver you are given a NEW ID (not just the first time, but EVERY TIME). Again, so long as a relationship is maintained between all your ID's on a given server and their corresponding ID's on the next machine down or up the line, it shouldn't matter to you at all! After a few years you could end up with hundreds or thousands of IDs. What difference would it make? You don't need to know what *any* of them are... matthew rapaport Philosopher/Programmer At Large KD6KVH mjr at netcom.com 70371.255 at compuserve.com From phr at napa.Telebit.COM Mon Jan 11 16:49:40 1993 From: phr at napa.Telebit.COM (Paul Rubin) Date: Mon, 11 Jan 93 16:49:40 PST Subject: share room at RSA conference Thursday? Message-ID: <9301120048.AA01484@napa.TELEBIT.COM> Does anyone have crash space, or need some, at the Sofitel hotel on Thursday night? (I'm not sure if it's all booked up or what the room rates are). I live fairly close to Redwood City but figure that staying at the conference hotel is the only way I'll have any chance of getting up early enough for the 9:00 A.M. session on Friday. I might also be interested in splitting up a room on Wednesday night but the interesting sessions on Thurs. don't start til 10:45 a.m. which is not quite as bad... Please reply by direct email, as I'm not on the list any more. Thanks. Paul From pmetzger at shearson.com Mon Jan 11 22:44:03 1993 From: pmetzger at shearson.com (Perry E. Metzger) Date: Mon, 11 Jan 93 22:44:03 PST Subject: Politics of Rmailers Message-ID: <9301111556.AA03382@maggie.shearson.com> > From: Crys Rides > > >>>>> On Sat, 9 Jan 93 23:32:18 PST, tribble at xanadu.com (E. Dean Tribble) said: > > E.> Date: Sat, 9 Jan 93 17:52:01 -0800 > E.> From: uunet!netcom.com!norm (Norman Hardy) > > E.> I can imagine a system administrator choosing to require that > E.> all mail originating from his machine include a signature that > E.> correctly identifies the local name of the sender. > > E.> I can imagine it, but none exist. This is mostly because the From: > ^^^^^^^^^^^ > E.> field is supplied by the mailer and satisfies that requirement, > E.> whereas requiring things in teh body of the mail message goes against > E.> the grain of how the systems are used. > *Bzzzzt* Wrong answer, thank you for playing. The public access bbs > system running out of Chapel Hill, automatically appends the same signature > to all outgoing messages, and other sites are considering the same measures. Mr Rides; Your rudeness is exceeded only by your apparent incapacity to read. As has been stated, quite clearly, no one is doubting that such systems exist. The "none exist" in the last paragraph refers to REASONS FOR THIS PRACTICE, not to the number of sites practicing it. As was said, the "From:" field satisfies the stated requirement without the need for autosignatures. The notion of an automatic footer when automatic headers exist already that satisfy the identification requirement is without merit. Perry From honey at citi.umich.edu Tue Jan 12 11:37:57 1993 From: honey at citi.umich.edu (peter honeyman) Date: Tue, 12 Jan 93 11:37:57 PST Subject: Random number generators In-Reply-To: <9212310751.AA21888@cygnus.com> Message-ID: <9301121937.AA00359@toad.com> > Can someone get the paper(s) and/or talk to the researcher? got it! peter ------- Forwarded Message Date: Tue, 12 Jan 1993 14:14:39 -0500 From: amf at csp2.csp.uga.edu (Alan Ferrenberg) To: honey at citi.umich.edu Subject: Re: Phys. Rev. Let. paper Dear Dr. Honeyman, A postscript version of the paper is available on our anonymous ftp site (csp2.csp.uga.edu) in the /pub/documents/amf1 directory as rng.ps. Alan Ferrenberg PS: We are just beginning this ftp site, but have already collected a number of (hopefully) interesting preprints from several authors here, as well as from Japan and Israel. Please feel free to browse through the selection of papers, to upload any articles you feel might be interesting to simulational physicists and to spread the word about this new service. ------- End of Forwarded Message From hugh at domingo.teracons.com Tue Jan 12 13:10:47 1993 From: hugh at domingo.teracons.com (Hugh Daniel) Date: Tue, 12 Jan 93 13:10:47 PST Subject: Crypto Bus is not going to happen it looks like... In-Reply-To: <9212300014.AA08503@domingo.teracons.com> Message-ID: <9301122108.AA03857@domingo.teracons.com> So far I have gotten three (3) positive replys to rideing the Crypto Bus to Usenix, thats about $800 each round trip. Unless I get an avalanche of riders in the next couple of days I am not even going to try to get a bus. If you need to know more about the idea of chartering a bus for bay area folks (and anyone along the way) to Usenix, contace me. ||ugh Daniel From hugh at domingo.teracons.com Tue Jan 12 14:39:03 1993 From: hugh at domingo.teracons.com (Hugh Daniel) Date: Tue, 12 Jan 93 14:39:03 PST Subject: Cascading aliases with ID forwarding re-mailers In-Reply-To: <930109232813_74076.1041_DHJ76-1@CompuServe.COM> Message-ID: <9301122237.AA03911@domingo.teracons.com> I suspect that a ID creating forwarder should _never_ send the ID to the user, as someone might be looking (both the current plain text replys and traffic analsys are problems). If the user wishes to know their ID then they can send a message to themselvs, and read the ID off of that, right? ||ugh Daniel From barrus at tree.egr.uh.edu Tue Jan 12 20:00:31 1993 From: barrus at tree.egr.uh.edu (Karl L. Barrus) Date: Tue, 12 Jan 93 20:00:31 PST Subject: security of constructed addresses Message-ID: <9301130359.AA00390@tree.egr.uh.edu> Alert! Hal Finney has alerted me to a problem with the way my script builds an anonymous remailer chain. Simply saving eachheader portion into a seperate file and running pgp on the pieces reveals each link in the chain. The solution (also from Hal Finney) is: hide the intermediate hops until they get to the machine that needs them. (machine1, encrypt1(machine2, encrypt2(machine3, encrypt3(user at dest)))) Here, the entire header is decrypted at each remailer, revealing the next destination to that remailer only. No peeking ahead! The only remailer that will be revealed is the first one, where mail has to be sent anyway. I'll rework the script, provide a ksh version, and write a little help file ASAP. /-----------------------------------\ | Karl L. Barrus | | barrus at tree.egr.uh.edu (NeXTMail) | | elee9sf at menudo.uh.edu | \-----------------------------------/ From barrus at tree.egr.uh.edu Tue Jan 12 20:12:55 1993 From: barrus at tree.egr.uh.edu (Karl L. Barrus) Date: Tue, 12 Jan 93 20:12:55 PST Subject: mental poker Message-ID: <9301130412.AA00436@tree.egr.uh.edu> Okay, anybody want to play mental poker with me??? A protocol involving bit committment was posted to sci.crypt recently, which we can use to play. There is an RSA protocol, but a commutative encryption/decryption is required, which I don't think PGP provides. So here is the protocol: 1) A shuffles cards, creates a message M1 that lists the cards by number. A appends a random bit stream, and computes the hash (using MD5). A sends hash MD5(M1) to B. 2) B composes message M2 that lists the cards he chooses by number. B appends a random bit stream, and computes the hash. B sends the hash MD5(M2) to A. 3) A sends B M1 so B can get his cards. 4) B shuffles the remaining 47 cards, lists them by number, appends a random bit stream to create M3, and computes the hash. B sends hash MD5(M3) to A. 5) A chooses cards by number, appends a random bit stream to create M4, and computes hash. A sends MD5(M4) to B. 6) B sends A M3 so A get get her cards. A and B can catch cheating by comparing the various message and hashes. Getting extra cards can be left as further extensions, as can multiple players (3 or more). Any takers? By the way, the hash function implementation I have is the sigfetch routine contained in tripwire. It includes md5, md4, md2, snefru, crc, and crc32. So before a game starts the players should verify their respective hashers. /-----------------------------------\ | Karl L. Barrus | | barrus at tree.egr.uh.edu (NeXTMail) | | elee9sf at menudo.uh.edu | \-----------------------------------/ From 74076.1041 at CompuServe.COM Tue Jan 12 23:17:59 1993 From: 74076.1041 at CompuServe.COM (Hal) Date: Tue, 12 Jan 93 23:17:59 PST Subject: Mental poker. Message-ID: <930113070548_74076.1041_DHJ40-1@CompuServe.COM> Mental poker protocols are notorious for having sometimes subtle weaknesses. I missed the posting on sci.crypt which Karl mentioned but his description of the protocol seems to have a flaw: > 4) B shuffles the remaining 47 cards, lists them by number, appends a > random bit stream to create M3, and computes the hash. B sends hash > MD5(M3) to A. > [...] > 6) B sends A M3 so A get get her cards. If B in step 6 sends A message M3, which lists the 47 cards left after B has chosen his 5 from the 52 they started with, then A will be able to see which 5 B chose; those are the 5 not listed in M3. Am I missing something in the description of the protocol, or was the actual protocol perhaps a little different than this? Hal Finney 74076.1041 at compuserve.com From barrus at tree.egr.uh.edu Wed Jan 13 09:15:34 1993 From: barrus at tree.egr.uh.edu (Karl L. Barrus) Date: Wed, 13 Jan 93 09:15:34 PST Subject: mental poker protocol Message-ID: <9301131714.AA02844@tree.egr.uh.edu> Hal writes: >Am I missing something in the description of the protocol, or was the >actual protocol perhaps a little different than this? Oops. I typed too quickly; the posted protocol specified shuffling the entire deck to form message M3. Thus, each player draws from a full deck. While this isn't exactly poker, I'm still willing to play somebody. So Hal's right: the original protocol is different - it's not broken like the one I posted :-) The post to sci.crypt was in response to a bit commitment question. Here, players commit by making public their hashes. Later, everyone can verify when the messages are known. If anyone's interested, send me a notice to elee9sf at menudo.uh.edu. (The server for my other account is acting erratic and I'm considering moving my subscription). /-----------------------------------\ | Karl L. Barrus | | elee9sf at menudo.uh.edu | <- preferred address | barrus at tree.egr.uh.edu (NeXTMail) | \-----------------------------------/ From nowhere at bsu-cs.bsu.edu Wed Jan 13 13:36:56 1993 From: nowhere at bsu-cs.bsu.edu (Chael Hall) Date: Wed, 13 Jan 93 13:36:56 PST Subject: bbs Message-ID: <9301132133.AA22203@bsu-cs.bsu.edu> >So they are using a whole bunch of accounts in an effort to conceal their >identity? And they hope that one of the accounts will be approved >for full access to adult material, without the sysop really knowing >who they are? Yes, the intention is to get one approved without the SYSOP really knowing who he approves. >Do you always check the phone number supplied as part of the registration >process or wait until the user abuses the BBS? It seems that someone >could simply start taking names out of the phone book if he wanted to >conceal who he really is... I used to check phone numbers, now I only check those of users with strange names or wait until they abuse the system. The first thing I check when someone abuses my system is their identity. If it's fraudulent, I put the account in the system kill file and they can no longer login. I use a pretty good method for allowing access to adult areas. A consent form must be filled out and signed. Then it is mailed to me with a photocopy of the same person's driver's license (SSN can be blacked out, I'm not concerned with it). I file it away and give them access if it looks correct. Generally, I detect system abuse pretty soon after it occurs. Then, I handle the situation as quickly and efficiently as possible. The same user rarely tries it again. I did voice validate all of my users, but that got to be tedious, so I just check when something happens. Many BBS's require that they be able to call a user back directly before granting full access. This would not work over the Internet, a University modem pool like many were using here, or long distance for the cheap SYSOP. There are, however, a flurry of programs that perform "automatic call-back telephone number verification." Chael Hall -- Chael Hall nowhere at bsu-cs.bsu.edu, 00CCHALL at LEO.BSUVC.BSU.EDU, CHALL at CLSV.Charon.BSU.Edu (317) 285-3648 after 3 pm EST From barrus at tree.egr.uh.edu Wed Jan 13 17:42:17 1993 From: barrus at tree.egr.uh.edu (Karl L. Barrus) Date: Wed, 13 Jan 93 17:42:17 PST Subject: new remailing script Message-ID: <9301140141.AA05172@tree.egr.uh.edu> Here is the new sh version of the remailing script. Enjoy! #!/bin/sh # support script for anonymous remailers # allows routing a message through various remailers # NOTE: to use extropia remailer, uncomment the appropriate lines # see the documentation file #find out which mode user wants echo "Do you want to:" echo "1. Mail a file via anonymous remailers" echo "2. Create a remailing header and append to a file" echo "" echo -n "Your choice? " read choice if [ "$choice" = "" -o "$choice" -lt 1 -o "$choice" -gt 2 ] then echo "Error. Improper mode selected." exit 1 fi #declare remailers mail1=hal at alumni.caltech.edu mail2=remailer at rebma.mn.org mail3=elee7h5 at rosebud.ee.uh.edu mail4=remail at extropia.wimsey.com #temporary files t1=.anon1 t2=.anon2 t3=.anon3 #set up encrypted pgp header echo "::" > $t1 echo "Encrypted: PGP" >> $t1 echo "" >> $t1 #blank out .anon3 cat /dev/null > $t3 #get final destination if [ "$choice" -eq 1 ] then echo -n "Final destination (user at host): " else echo -n "Your email address (user at host): " fi read to #exit if no final destination if [ ! "$to" ] then echo "Error. No destination specified." exit 1 fi #print menu echo "" echo "Mailing via:" echo "1) $mail1" echo "2) $mail2" echo "3) $mail3" #echo "4) $mail4" # uncomment to use extropia echo "" notdone=true #begin loop while [ $notdone ] do #find out remailing request echo -n "via (1-3 or q)? " read rto if [ "$rto" = "" -o "$rto" = q ] then notdone="" # exit while loop else #convert number to address case "$rto" in 1) rto=$mail1;; 2) rto=$mail2;; 3) rto=$mail3;; # 4) rto=$mail4;; # uncomment to use extropia *) echo "Invalid menu choice."; exit;; esac #set up remailing request header echo "::" > $t2 echo "Request-Remailing-To: $to" >> $t2 echo "" >> $t2 # echo "remailing to $rto; encrypted for $to" cat $t3 >> $t2 # append previous message pgp -ea $t2 $rto 2> /dev/null # do the encryption cat $t1 $t2.asc > $t3 # prepend header to encrypted message to=$rto # save last hop fi done if [ "$choice" -eq 1 ] then #now include message echo -n "Message to include? " read msg if [ ! -f "$msg" ] then echo "Error: $msg not found" exit 1 fi cat $msg >> $t3 mail -s "anonymous mail" $to < $t3 echo "Mail sent." elif [ "$choice" -eq 2 ] then echo -n "Append to file: " read msg echo "--------8<--cut here-->8--------" >> $msg cat $t3 >> $msg echo "" >> $msg echo "> $msg echo "> $msg echo "> $msg else echo "Error. Invalid choice." exit 1 fi #clean up some of the temporary files rm -rf $t1 $t1.asc $t2 $t2.asc From barrus at tree.egr.uh.edu Wed Jan 13 17:46:04 1993 From: barrus at tree.egr.uh.edu (Karl L. Barrus) Date: Wed, 13 Jan 93 17:46:04 PST Subject: help file for remailing script Message-ID: <9301140145.AA05184@tree.egr.uh.edu> And here is a short help file I've written. I will try to write another version of this script (maybe in perl or something) and submit everything to be placed on the ftp site. To cut down on mail, I won't be mailing further versions, etc. to the list, so request it from me or get it via ftp (once I get around to submitting it). ------------------------------ hop.mail is a shell script that automates the process of using the cypherpunk cryptographically protected remailers. Briefly, it has two modes of operation: one is to send a file, the other is to create a header which can be used by someone else to send a file to you. WHAT YOU NEED TO HAVE Well, you need to have PGP installed. Also, you'll need the public keys of the various remailers on your keyring. SENDING A FILE Create the message you want to mail, and save it as a file. To send a file, choose option 1. You will then be prompted for the final destination of the file you would like to send (by final destination I mean email address). After that, the script will continue prompting you for routing information. Each remailer you specify routes your mail through that particular remailer. Note: due to the way the remailing headers are built up, the path your file will actually take is the reverse of what you specify. That is, the first remailer you route through will be the one you file will appear to come from. The last remailer you specify is actually the first hop in the chain. After routing your mail through as many remailers as you want (keep in mind that your mail will arrive slower the more hops you take), enter 'q' to exit. After you have set up your mail route, the script will ask what file you wish to send. The file is simply appended on to the header, and the whole thing is sent off. No encryption of the file takes place. If you wish, you may encrypt the file you want to mail with your destination's public key or some other encryption scheme. The advantage of not encrypting the message in with the remailing header is that you can use this script to mail to people who don't use pgp. CREATING A HEADER Create the message you wish to send and save it as a file. Choose option 2 to create a header. The steps are similar to sending a file, except remember that someone will use this to reply to you, so type in the address you want them to respond to. This can be your real mail address, or an anonymous id on one of the various anonymous services, or anything else. Route your mail like you want, and enter 'q' to exit. At this point, you will be prompted for a file to append to (the message you created). Enter the file you want the remailing header appended to. Now you have a file which contains the message you typed, as well as instructions on how whoever you mail it to can use the included header to reply to you. If you wish, you may mail this file via option 1! NOTES My first attempt at this script simply built each header separately. This worked, but was vulnerable: simply save each piece in a separate file, run pgp on them, and you will be told which remailer the header is encrypted for! This version nests the encryption, so that only the next destination is revealed to the current remailer. That is, the structure of the header is: encrypt1(address2, encrypt2(address3, encrypt3(message))) So when your file arrives at remailer1, the header is decrypted to reveal the next hop, and the rest of the header is mailed off the remailer2, where it is decrypted to reveal the next hop, etc. As I said above, the file you send is not encrypted. If it bugs you that your file is mailed plain text, then encrypt it first if the person you are sending to can decrypt. I purposely did not encrypt the file you want to send so you can use this procedure with people who don't have pgp. Or you can post to usenet via a email-to-usenet gateway. Or whatever. Also, the remailer at extropia is not supported yet. Not because I don't like it, but because encryption must be used there. This isn't bad or anything, but it causes difficulty building the remailing header separately. Extropia will not allow you to mail plain text through it, you must encrypt it with extropia's public key. So if you do that, then you should be able to use extropia, and you'll need to go through and uncomment the appropriate lines. Finally, the mail command I used in the script is mail -s "anonymous mail" Make the appropriate changes if you want to use another mailer or change the subject line BUGS Ug. :-) Send reports of problems to elee9sf at menudo.uh.edu, or barrus at tree.egr.uh.edu, and I'll look into them! Or, send any comments you might have. /-----------------------------------\ | Karl L. Barrus | | elee9sf at menudo.uh.edu | <- preferred account | barrus at tree.egr.uh.edu (NeXTMail) | \-----------------------------------/ From eric at parallax.com Wed Jan 13 18:07:53 1993 From: eric at parallax.com (Eric Messick) Date: Wed, 13 Jan 93 18:07:53 PST Subject: Details on return envelopes Message-ID: <9301140202.AA22884@parallax.com> This is a long, complicated, and information dense message. You've been warned. I've been working out details of what would be required of an anonymous return envelope. To make sure I've thought of everything, I've filled in a matrix with the types of information that might need to be passed between the various participants during the sending of a message. The person who created the envelope is the ultimate recipient of the message (recv). The envelope has somehow been transmitted to a person (send) who wishes to send a message to recv. The message will be transmitted via several remailers, collectively referred to as hops. This results in nine potential transmission channels, several of which need not be possible for various reasons. Clearly, the sender does not need a special channel to communicate back to herself, and likewise the receiver does not need special provisions to communicate to herself either. The sender should be unable to receive information from the various hops, as that would compromise the path that the message takes. The various hops already communicate directly with their following neighbor through headers, and we want to prohibit communication back towards the sender. The remaining five cases are listed below: | from | send recv hops -------------+------------------------ send | - pneed (ack) to recv | msg - pdue hops | post addr - where: msg is the message being delivered post is postage paid by the sender addr is addressing info from the receiver pneed is info to help sender provide postage pdue is info on missing postage (ack) is info that is disallowed pneed is cleartext on the outside of the envelope. This leaves us with the message, and three parts of the envelope: the delivery address, postage paid, and postage due. Note that information other than what I'm describing here could be sent along these channels; I am simply using postage as a concrete example of information that might need to be transmitted. And now, let's trace a message through to its delivery. Being stuck with ascii, the notation is not wonderful. Groups of letters represent sets of similar things. Case is significant. Lower case letters r and v-z are public keys. Upper case letters preceded by & are the machines that know the associated secret keys (from the C address of operator). So machine &Y can decrypt something encrypted with public key y. Upper case letters A-F are conventional keys. Keys A-C are generated by the sender, keys D-F by the receiver. The symbols P, S, Q, $, and # are followed by lower case letters indicating who the item is associated with. Q and # are conventional keys, P and S form a public key-secret key pair, and $ is a digicash stamp. NOTATION: x(...) contents encrypted with public key x &X mail address for remailer using public key x A(...) contents encrypted with conventional key A Px public key for delivering postage to &X Sx secret key for delivering postage to &X Qx conventional key for postage due from &X $x a postage stamp for &X to cash Amt_x an amount of postage to deliver to &X Due_x postage still due to &X, plus a unique ID #x conventional key held by &X while postage is due pad random padding (see below) &R mail address of the final recipient Pr, Qr, $r stuff associated with &R M the actual message to be delivered to &R junk padding created by &R as a diversion ABOUT PADDING: K(stuff, pad) can be transformed into stuff by decrypting with key K. Since stuff has a length associated with it inside the encryption, an external viewer cannot tell the length of stuff. It is also possible to turn K(stuff) into K(stuff, pad) without knowing K. The encryption packet contains an external length as well as the internal length. The external length must be adjusted to cover the added padding, which is just a random bitstream appended to the cyphertext. Once this padding has been performed, it is impossible to determine the length of stuff without decrypting with K. In this manner, a portion of a message can be either lengthened or shortened at every step along the way, as long as a decryption is performed at each step. This is the motivation for the keys A..F in the exchange that follows. PGP should be augmented with a function to pad a message, and should explicitly accept padded data. I have tested PGP2.1 on Unix and it accepts padded data that I manually added. OK, here we go... The envelope provided by the receiver to the sender looks like this: Addr: &X, x, x(...) Pneed: [Px, Amt_x], [Py, Amt_y], [Pz, Amt_z], [Pr, Amt_r] Everything except the encrypted segment x(...) is considered public knowledge. The keys Px, etc... pose a slight problem: One of the hops can identify which envelope a message is associated with by comparing the postage key sealed inside the addressing info with this public string of keys. It's not clear how serious of an issue this is. The sender decides to send the message through hosts &V and &W before using the provided envelope. She sends the following message to &V: Addr: v(A), v(Sv, Qv, B, &W, w(B), w(Sw, Qw, C, &X, x(C), x(...)), pad) Post: A(Pv($v, Pw($w, Px($x, Py($y, Pz($z, Pr($r)))))), pad) Pdue: A(pad) Message: A(M, pad) She has created keys A-C, Pv, Sv, Pw, Sw, Qv, and Qw. She obtains the specified postage stamps and wraps them in the various postage keys. The keys and addresses get wrapped in public keys for the address field, and all of the other elements of the message are sealed with key A. The address field consists of two public key encrypted segments because the sender must create key C, but cannot seal it into the packet that the recipient has provided for host &X. If C were public knowledge, host &X could be monitored, and the plaintext of M revealed to an external watcher. As it is, M still occurs in plaintext within each remailer, so it should be protected by the recipient's public key (i.e. M = r(the real message) ). &V decrypts the v() encryptions to find all of the keys necessary for it to process the message. The padding is removed from the address field. The key A unlocks the message M, allowing the stripping of the padding, which is replaced with new padding before being encrypted with key B. It notes that the Pdue field is empty. Sv allows it to extract its postage stamp $v, and strip the padding. The message it sends to &W looks like this: Addr: w(B), w(Sw, Qw, C, &X, x(C), x(...), pad) Post: B(Pw($w, Px($x, Py($y, Pz($z, Pr($r))))), pad) Pdue: B(pad) Message: B(M, pad) &W does likewise, and sends the following to &X (we have revealed the encrypted part of the original envelope at this point): Addr: x(C), x(Sx, Qx, D, &Y, y(D), y(Sy, Qy, E, &Z, z(E), z(Sz, Qz, F, &R, r(junk), r(junk))), pad) Post: C(Px($x, Py($y, Pz($z, Pr($r)))), pad) Pdue: C(pad) Message: C(M, pad) Postage rates have gone up since the envelope was first issued, so &X, &W, and &Z will need to use the Pdue field. It works like this: Addr: y(D), y(Sy, Qy, E, &Z, z(E), z(Sz, Qz, F, &R, r(junk), r(junk)), pad) Post: D(Py($y, Pz($z, Pr($r))), pad) Pdue: D(Qx(Due_x), pad) Message: D(#x(M), pad) &Y then sends the following to &Z: Addr: z(E), z(Sz, Qz, F, &R, r(junk), r(junk), pad) Post: E(Pz($z, Pr($r)), pad) Pdue: E(Qy(Due_y, Qx(Due_x)), pad) Message: E(#y(#x(M)), pad) &Z sends the following to &R: Addr: r(junk), r(junk, pad) Post: F(Pr($r), pad) Pdue: F(Qz(Due_z, Qy(Due_y, Qx(Due_x)), pad) Message: F(#z(#y(#x(M))), pad) Now, &R (the receiver, who created the envelope in the first place) knows F, Sr, Qx, Qy, Qz, and thus finds out Due_x, Due_y, Due_z, #z(#y(#x(M))) [the message, with postage due], and gets a stamp $r. &R then generates a message that is designed to deliver #x, #y, and #z, and sends it to &X: Addr: x(C), x(Sx, Qx, D, &Y, y(D), y(Sy, Qy, E, &Z, z(E), z(Sz, Qz, F, &R, r(junk), r(junk))), pad) Post: C(Px($x, Due_x, Py($y, Due_y, Pz($z, Due_z, Pr(junk)))), pad) Pdue: C(pad) Message: C(pad) &X unwraps it and sends #x along: Addr: y(D), y(Sy, Qy, E, &Z, z(E), z(Sz, Qz, F, &R, r(junk), r(junk)), pad) Post: D(Py($y, Due_y, Pz($z, Due_z, Pr(junk))), pad) Pdue: D(Qx(#x), pad) Message: D(pad) And again: Addr: z(E), z(Sz, Qz, F, &R, r(junk), r(junk), pad) Post: E(Pz($z, Due_z, Pr(junk)), pad) Pdue: E(Qy(#y, Qx(#x)), pad) Message: E(pad) And back to &R: Addr: r(junk), r(junk, pad) Post: F(Pr(junk), pad) Pdue: F(Qz(#z, Qy(#y, Qx(#x))), pad) Message: F(pad) So &R now knows #x, #y, and #z, and so can recover M. To keep &Z from knowing it is the tail of the path, extra postage stamps are required of the sender. These are cashable by the receiver. The sender thus has no way of knowing the length of the path, but only has an idea of the upper bound on it. If the sender does not include sufficient postage on the steps she prepended to the path, the receiver will not be able to read the message, as there is no way for the receiver to find out Qv and Qw. Perhaps these could be affixed to the innermost stamp, along with &V and &W, but this is probably not a good idea. Since remailers wouldn't add extra encryption to the header fields of a postage due message (it would make paying the postage due a lengthy process), the postage due concept could be circumvented by placing the message in the Post or Pdue headers disguised as postage info. To discourage this, remailers would only allow postage due deliveries for a fixed period after a rate increase, and would still require the older rate be paid. Another use for postage due would be to disguise the use of an expensive remailer. Such a remailer would forward with postage due when paid the prevailing rate. Well, I've beaten this thing bloody now and can't find any more flaws. I admit it's a bit of a monster, but most of it goes away if you don't require postage. I think the system needs to be designed with postage in mind from the start, however. Anyway, it's time for you people to start ripping it apart. Perhaps we can have a discussion of this at the physical meeting this week if Eric Hughes can fit it into the schedule. -eric messick From barrus at tree.egr.uh.edu Thu Jan 14 06:36:40 1993 From: barrus at tree.egr.uh.edu (Karl L. Barrus) Date: Thu, 14 Jan 93 06:36:40 PST Subject: anonymous service shutdown (pax) Message-ID: <9301141435.AA07332@tree.egr.uh.edu> This was posted to alt.security.pgp: (I trimmed the header) -------------------------------------------------------------- The anonymous and encrypted mail service at PAX has been shutdown. The site that connects PAX has been told by someone from AARNet (the Australian Academic Research Network) that the service is unsuitable for AARNet, and that if it is not stopped then the feeding site will be disconnected from the net. There has been no communication from AARNet to me or anyone else at PAX, but I cannot allow the feeding site to put itself at risk hence the service is closed until further notice. I am lead to believe that this is not so much AARNet's policy, but the NSF Net's policy and the NSF have brought pressure to bear on AARNet, as they believe that all mail that crosses their network must be traceable to its origin, ipso facto no anonymous mailers. I have not been approached by either organization personally so I cannot confoirm this. I am extremely disappointed but c'est la vie. It was an interesting experiment, and proof that the concept of anonymous encrypted mail is feasible with simple tools. Hopefully someone somewhere outside the jurisdiction of these authorities will be able to continue the good work. david clunie (dclunie at pax.tpa.com.au) ex-anon.admin at pax.tpa.com.au :( ------------------------------------------------------------------------ Uh oh, looks like anon.penet.fi is the only one left (besides the one at twwells, but it is more limited than pax or penet). I think this raises some important and scary issues for we cypherpunks. Does anybody have a printout of NSF guidelines about tracing mail back to its origin? This may affect our remailers (if word gets out!) in that logs might have to be kept...or worse :-( I run an anonymous remailer, and I depend upon people to not abuse the service. If somebody wants to use it to request the source code for the internet worm, fine. Or distribute virus source code, okay (but encrypt the code for heaven's sake :-) But don't threaten, libel, or insult somebody via anonymous mail (never mind that you can do all these things anonymously with the postal service, but the difference is everybody uses the post office). Like it says in the pgp docs, if everybody encrypted their mail, then it would be a right taken for granted, and people would scream bloody murder if it were taken away. If "everybody" routes their mail, then it too would become acceptable. So we need MORE remailers than the four I know of - alumni, rebma, rosebud, extropia (there was one at soda but it was shut down, right??) (subliminal hint: it's real easy to run one of the cypherpunk remailers, you just need unix, pgp, and perl) Comments? /-----------------------------------\ | Karl L. Barrus | | barrus at tree.egr.uh.edu (NeXTMail) | | elee9sf at menudo.uh.edu | \-----------------------------------/ From eichin at cygnus.com Thu Jan 14 06:48:48 1993 From: eichin at cygnus.com (Mark Eichin) Date: Thu, 14 Jan 93 06:48:48 PST Subject: pax anonymous remailer shutdown Message-ID: <9301141447.AA19074@cygnus.com> I include the article as it arrived here. _Mark_ Path: cambridge-news.cygnus.com!enterpoop.mit.edu!gatech!rpi!zaphod.mps.ohio-state.edu!howland.reston.ans.net!sol.ctr.columbia.edu!flash.pax.tpa.com.au!britt!dclunie From: dclunie at pax.tpa.com.au (David Clunie) Newsgroups: aus.aarnet,aus.news,alt.sexual.abuse.recovery,alt.sex,alt.sex.bondage,alt.sex.motss,alt.sex.stories,talk.politics.homosexuality,alt.personals,alt.personals.bondage,alt.security.pgp,comp.security.misc,talk.politics.guns Subject: PAX Anonymous & Encrypted Service shutdown Date: 14 Jan 1993 07:39:22 GMT Organization: PAX - Public Access Unix (Adelaide,South Australia) Lines: 30 Distribution: world Message-ID: <1j35baINNgm at flash.pax.tpa.com.au> Reply-To: dclunie at pax.tpa.com.au NNTP-Posting-Host: britt.pax.tpa.com.au Xref: cambridge-news.cygnus.com alt.sexual.abuse.recovery:1414 alt.sex:4689 alt.sex.bondage:2827 alt.sex.motss:243 alt.sex.stories:1172 alt.personals:2845 alt.personals.bondage:459 alt.security.pgp:800 comp.security.misc:657 talk.politics.guns:2223 The anonymous and encrypted mail service at PAX has been shutdown. The site that connects PAX has been told by someone from AARNet (the Australian Academic Research Network) that the service is unsuitable for AARNet, and that if it is not stopped then the feeding site will be disconnected from the net. There has been no communication from AARNet to me or anyone else at PAX, but I cannot allow the feeding site to put itself at risk hence the service is closed until further notice. I am lead to believe that this is not so much AARNet's policy, but the NSF Net's policy and the NSF have brought pressure to bear on AARNet, as they believe that all mail that crosses their network must be traceable to its origin, ipso facto no anonymous mailers. I have not been approached by either organization personally so I cannot confoirm this. I am extremely disappointed but c'est la vie. It was an interesting experiment, and proof that the concept of anonymous encrypted mail is feasible with simple tools. Hopefully someone somewhere outside the jurisdiction of these authorities will be able to continue the good work. david clunie (dclunie at pax.tpa.com.au) ex-anon.admin at pax.tpa.com.au :( From honey at citi.umich.edu Thu Jan 14 07:56:07 1993 From: honey at citi.umich.edu (peter honeyman) Date: Thu, 14 Jan 93 07:56:07 PST Subject: anonymous service shutdown (pax) In-Reply-To: <9301141435.AA07332@tree.egr.uh.edu> Message-ID: <9301141556.AA12838@toad.com> > Does anybody have a printout of NSF guidelines about > tracing mail back to its origin? karl, don't leap to conclusions -- david said he is led to believe that nsfnet pressure was brought to bear, but that he had no evidence to confirm this suspicion. personally, i doubt that there is any nsfnet policy regarding the ability to trace mail back to an individual, but i'll ask. peter From 74076.1041 at CompuServe.COM Thu Jan 14 12:09:52 1993 From: 74076.1041 at CompuServe.COM (Hal) Date: Thu, 14 Jan 93 12:09:52 PST Subject: Details on return envelopes Message-ID: <930114195927_74076.1041_DHJ54-1@CompuServe.COM> I've been studying Eric Messick's message. It's pretty complicated and it will take more time to really understand it. I did spot one possible problem. Remailer &V sends to &W an address field that looks like: Addr: w(B), w(Sw, Qw, C, &X, x(C), x(...), pad) but I don't think &V has enough information to create the 2nd item here. The reason for the A, B, etc. keys is, I think, to allow new padding to be done as the message gets passed between each pair of remailers. I think that may need to be used here as well. &V can't put padding into the w(Sw,...) block. As a more general comment, I'd like to see some simpler examples. Eric has shown the most complex case in order to demonstrate that his scheme works for that, but I think more people would be able to comment on it if some simpler examples were provided. How about an anonymous address that is just one hop long, instead of 3, and which is used by the sender without going through any remailers first? I think that would be less intimidating. Another general point, which may be important. Chaum emphasized that his anonymous addresses should be use-once, because if two people send messages to the same anonymous address, someone who has access to the mail goig into and coming out of the remailer will see identical address fields coming out for the pair of messages. I think Eric's scheme has the same property. I have to admit that I don't see that a use-once anonymous address is very useful, but I think we should give this some consideration. I think Eric's use of padding is to defeat just such an attacker, so that there is no message-length correlation between incoming and outgoing messages. If we are going to worry about such attacks, it calls into question the whole approach to anonymous addresses. As one possible corollary, if anonymous addresses were used once then the postage could be supplied by the addressee. This might change the protocol very considerably. Hal Finney 74076.1041 at compuserve.com From Marc.Ringuette at GS80.SP.CS.CMU.EDU Thu Jan 14 12:14:24 1993 From: Marc.Ringuette at GS80.SP.CS.CMU.EDU (Marc.Ringuette at GS80.SP.CS.CMU.EDU) Date: Thu, 14 Jan 93 12:14:24 PST Subject: anonymous service shutdown (pax) Message-ID: <9301142014.AA15788@toad.com> I think a large stink should be made at this point, to bring our legitimate privacy concerns to the attention of net admins, and to flush out who it was who threatened pax's net connection. I'm really uncomfortable with the way that the pax anon remailer was shut down on what seems to be pure hearsay. I think we need a little more guts from our anon administrators. Stick to your guns! Make them at least deliver an ultimatum to you so you know where the threat came from. A note on whether we cypherpunks should "lie low" -- it's always possible for us to go underground and hide from the authorities. I don't believe we should do this until it's absolutely necessary. As of now, we are legitimate net citizens. M. From 74076.1041 at CompuServe.COM Thu Jan 14 12:24:43 1993 From: 74076.1041 at CompuServe.COM (Hal) Date: Thu, 14 Jan 93 12:24:43 PST Subject: anonymous service shutdown (pax) Message-ID: <930114200748_74076.1041_DHJ54-2@CompuServe.COM> to: >internet:cypherpunks at toad.com I agree that the PAX shutdown is an ominous development. Nobody's internet access is perfectly free from the kinds of pressures that were brought against PAX. What steps can we take to keep the same thing from happening to us? I agree with Karl that a big step would be to spread remailers more widely. Eric Hollander is running three remailers in addition to the ones Karl mentioned - hh at soda.berkeley.edu, and two other machines which I don't have handy. They don't encrypt but they forward, and that's good enough for many purposes. Some time back, there was mention that the owner of the commercial Portal system would run one. Could someone follow up on that who knows him? PGP is gradually disappearing from U.S. sites where it used to be available. Recently it got taken off the EFF area on Compuserve. We can't afford to see encryption and remailers be slowly strangled. Hal 74076.1041 at compuserve.com From strat at intercon.com Thu Jan 14 12:57:07 1993 From: strat at intercon.com (Bob Stratton) Date: Thu, 14 Jan 93 12:57:07 PST Subject: Persecution of anon remailers Message-ID: <9301142057.AA23582@intercon.com> Things like this are what organs like Computer Underground Digest, a.k.a CuD, are always crying for. It might not be bad to bounce a message or two to the RISKS Digest as well. The best way to fight this sort of quite strangulation is to bring it out into the light. People are starting to look at the Internet as a nascent version of the next ubiqitous telecommunications technology. If we speak from the stand of "we want to have privacy technology ready for the day the general public gets this technology, and these guys are getting in the way...", then we have an opportunity to get the libraries, researchers, and other current net users up in arms about these developments. Bob Stratton Engineer, InterCon Systems Corp. strat at intercon.com +1 703 709 5525 From wayner at cs.cornell.edu Thu Jan 14 14:06:54 1993 From: wayner at cs.cornell.edu (Peter Wayner) Date: Thu, 14 Jan 93 14:06:54 PST Subject: No Subject Message-ID: <9301142206.AA23922@brokk.cs.cornell.edu> I often find it useful to think about these matters by mapping them over to the real world. Anonymous remailers are really quite common. Here are a few common sources: 1) Academic journals which review papers. These often keep the names of the reviewers and the names of the paper authors hidden to allow people the chnace to speak freely. 2) Newspapers with personals sections offer both anonymous mailboxes and anonymous voiceboxes for obvious reasons. 3) The WSJ also offers these advertisements for executive searches. 4) The Police, in some cities, maintain anonymous tip lines. They also occasionaly offer cash rewards to these anonymous tipsters. I think the NYPD has a anonymity office set up to do just this. I realize that the cypherpunk mailing list likes to cloak itself in the romance of the counter culture, but in moments like this it might make sense to think about how mainstream and suburban and respectable the concept of anonymous mailers can be. In many cases, authority reacts to the perceived threat-- not to the threat itself. -Peter Wayner From marc at MIT.EDU Thu Jan 14 15:49:51 1993 From: marc at MIT.EDU (Marc Horowitz) Date: Thu, 14 Jan 93 15:49:51 PST Subject: anonymous service shutdown (pax) In-Reply-To: <930114200748_74076.1041_DHJ54-2@CompuServe.COM> Message-ID: <9301142348.AA00333@TLA.MIT.EDU> >> I agree that the PAX shutdown is an ominous development. Nobody's >> internet access is perfectly free from the kinds of pressures that were >> brought against PAX. What steps can we take to keep the same thing from >> happening to us? There's one very obvious thing, but it costs money (the real kind, not the stuff we've been playing with). Someone needs to *buy* a connection to the *commercial* internet and put an anonymous remailer where the NSF can't touch it. NEARnet recently signed an agreement with ANS and CIX to use ANS as a pipe between it and the CIX (note the lack of *any* government involvement here). If I understand this development correctly, this means a site on NEARnet with the Commercial Routing Service (it costs extra, numbers on request) can, I think, send packets anywhere without crossing the NSFnet. ANS simply leases bandwidth to the NSF. Most backbone bits cross this leased bandwidth, but now, it is possible to buy access to this *privately* owned network. Now, who has $16k annually (that's the number, I have a quote on my desk) to sink into the connection? Are we serious enough about this to form some sort of corporation (with legal ties that bind, and identify) to maybe set this up? There's enough people on this list to make this sort of thing cost < $10/month each if *everyone* participated. Of course, if we did this, we'd have to make it quite clear what we were planning on doing. Use of PGP makes this hard. A company set up for the purpose of making PGP easier to use would arouse the Wrath of RSA really quickly. FYI, the NEARnet AUP: NEARnet Primary Goals NEARnet, the New England Academic and Research Network, has been established to enhance educational and research activities in New England, and to promode access to regional and national innovation and competitiveness. NEARnet provides access to regional and national resources to its Members, and access to regional resources from organizations throughout the United States and the world. NEARnet Acceptable Use Policy 1. All use of NEARnet must be consistent with NEARnet's primary goals. 2. It is not acceptable to use NEARnet for illegal purposes. 3. It is not acceptable to use NEARnet to transmit threatening, obscene, or harassing materials. 4. It is not acceptable to use NEARnet so as to interfere with or disrupt network users, services or equipment. Disruptions include, but are not limited to, distribution of unsolicited advertizing, propagation of computer worms and viruses, and using the network to make unauthorized entry to any other machine accessible via the network. 5. It is assumed that information and resources accessible via NEARnet are private to the individuals and organizations which own or hold rights to those resources and information unless specifically stated otherwise by the owners or holders of rights. It is therefore not acceptable for an individual to use NEARnet to access information or resources unless permission to do so has been granted by the owners or holders of rights to those resources or information. Violation of Policy NEARnet will review alleged violations of Acceptable Used Policy on a case-by-case basis. Clear violations of policy which are not promptly remedied by Member organization may result in termination of NEARnet Membership and network services to Member. It seems to me that the user of possibly illegal software like PGP could be considered a violation of rule 2. The whole issue of anonymous harassing email brings up rule 3. I've send mail to one of the NEARnet discussion lists asking how encryption and anonymity affects the interpretation of rule 3. Marc From marc at Aktis.COM Thu Jan 14 15:57:58 1993 From: marc at Aktis.COM (Marc Horowitz) Date: Thu, 14 Jan 93 15:57:58 PST Subject: possible solution to the anonymous harrassment problem Message-ID: <9301142356.AA26090@dun-dun-noodles.aktis.com> (I'm also marc at mit.edu. But composing over a 9600 baud line sucks :-) I just had an idea. Assume we have some sort of workable system for anonymous return addresses. What if every message were *required* to have one, and if the remailers verified their correctness (at least as far as we can, given the fakability of net mail)? Then, if someone received harassing email, she could ask the remailer maintainers to find the real name of the sender of a piece of mail. Assuming reasonable remailer maintainers (and we can use positive reputations to decide that), they'd be able to do this. The system has a built-in safety: All the remailer maintainers would have to agree that a message was indeed harassing to the recipient before they would use their private keys to follow the chain back. Unless all the maintainers agreed to trace the message, it would be impossible, and the sender's anonymity would be assured. I'm just trying to think of technical solutions to our societal woes, as hopeless as this may be. Remember, if people were honest, we wouldn't need encryption, either. Sigh. Marc From whitaker at eternity.demon.co.uk Thu Jan 14 16:01:10 1993 From: whitaker at eternity.demon.co.uk (Russell Earl Whitaker) Date: Thu, 14 Jan 93 16:01:10 PST Subject: Forwarded article. Message-ID: <9147@eternity.demon.co.uk> This article was forwarded to you by whitaker at demon.co.uk (Russell Earl Whitaker): --------------------------------- cut here ----------------------------- Newsgroups: demon.security Path: eternity.demon.co.uk!demon!visigoth.demon.co.uk!pettsj From: James Petts Subject: Public Key Exchange Message-ID: X-Xxmessage-Id: X-Xxdate: Thu, 14 Jan 93 09:54:44 GMT Sender: news at demon.co.uk Nntp-Posting-Host: visigoth.demon.co.uk Organization: No Affiliation X-Useragent: Nuntius v1.1.1d13 Date: Thu, 14 Jan 1993 09:55:42 GMT For those who are interested, there is a short article in today's (14/1/93) New Scientist explaining how quantum uncertainties can be used to improve the security of exchanging cryptographic keys. ===> James Petts <=== *** CAUTION - READ THIS .sig AT YOUR OWN RISK! *************************** * * NOTE! VISIGOTH HAS NO * * Q. Wenn ist das Nunstueck git und Slotermeyer? * CONNECTION WITH ANY * * A. Ja!... Beiherhund das Oder die Flipperwaldt * OTHER SITE AT * * gersput! * DEMON.CO.UK * * * * ************************************************************************** * pettsj at visigoth.demon.co.uk (preferred), pettsj at cix.compulink.co.uk * ************************************************************************** --------------------------------- cut here ----------------------------- From dclunie at pax.tpa.com.au Thu Jan 14 16:03:48 1993 From: dclunie at pax.tpa.com.au (David Clunie) Date: Thu, 14 Jan 93 16:03:48 PST Subject: anonymous service shutdown (pax) Message-ID: <9301150003.AA00743@britt> I have had a fairly long discussion via email with the AARnnet administrator involved. He points out that wrongly or rightly (he believes wrongly) the AARNet does not have an "open access" policy, and the network is setup exclusively to service the university community. Public access systems are tolerated, but barely, and mainly through the grace of those who administer the system rather than those who fund it. The complaint in question was actually not at all specific, and came not from the NSF but from one of the NASA Internet officers who is responsible for the US end of the link to Australia (and pay for some of it). Essentially the complaint was one of increasing mail traffic on an already congested link to the US, as well as concern about the "hiding people's identities so they cannot be responsible for what they say". Personally I disagree with the second complaint, but cannot dispute the first, without statistsics about what component of the link was being consumed by the posting service. I suspect it was very small but these things all add up. It seems a shame that the anonymous system is being terminated "on principle" but the AARNet person has been friendly about it, in fact positively graceful in view of my somewhat inflammatory post, and so I guess I just have to leave it there. Hopefully eventually commercial vendors will provide an alternative channel to the university-based network here currently, much as has happened in the US over the years, and these questions will be less of a concern. david From eab at msc.edu Thu Jan 14 16:53:28 1993 From: eab at msc.edu (Edward Bertsch) Date: Thu, 14 Jan 93 16:53:28 PST Subject: quantum crypto/forwarded article In-Reply-To: <9147@eternity.demon.co.uk> Message-ID: <9301150052.AA05277@wc.msc.edu> ->For those who are interested, there is a short article in today's ->(14/1/93) New Scientist explaining how quantum uncertainties can be used ->to improve the security of exchanging cryptographic keys. Scientific American had this quite recently also. Or at least something very like it. I haven't seen the New Scientist article. If anyone has it in GIF, TIFF, ASCII or PostScript format, I'd like to see it. Ed -- Edward A. Bertsch (eab at msc.edu) Minnesota Supercomputer Center, Inc. Operations/User Services 1200 Washington Avenue South (612) 626-1888 work Minneapolis, Minnesota 55415 (612) 645-0168 voice mail From honey at citi.umich.edu Thu Jan 14 19:44:54 1993 From: honey at citi.umich.edu (peter honeyman) Date: Thu, 14 Jan 93 19:44:54 PST Subject: possible solution to the anonymous harrassment problem In-Reply-To: <9301142356.AA26090@dun-dun-noodles.aktis.com> Message-ID: <9301150344.AA22546@toad.com> the remailer of my dreams would offer ironclad guarantees of anonymity. call me a cynic, but asking me to place my trust in the hands of ... well, just about anybody! leaves me cold. i recognize that social issues will surely arise, but society has managed to deal with anonymity in other contexts. for example, i can send postal mail with high confidence of anonymity, and can make anonymous phone calls (with care, e.g., by using phone booths and moving around). something tells me that the difference here is that we are getting remailer services for free. how's the cypherpunks bank coming along? i have an application in mind ... a final comment: > Remember, if people were honest, we > wouldn't need encryption, either. forgive me if i'm coming on too strong, but that is total bullshit. privacy and honesty are orthogonal. peter From 74076.1041 at CompuServe.COM Thu Jan 14 23:08:10 1993 From: 74076.1041 at CompuServe.COM (Hal) Date: Thu, 14 Jan 93 23:08:10 PST Subject: possible solution to the anonymous h Message-ID: <930115065840_74076.1041_DHJ55-1@CompuServe.COM> I have to agree with Peter Honeyman that Marc Horowitz's proposal that remailers reveal message sources under certain conditions wouldn't work well. Remailer users will prefer remailers which won't do this. So reputations and such will tend to push things in the opposite direction. Also, I'd point out that the Pax remailer actually did maintain a database of anonymous addresses with the corresponding real addresses. So it already worked much as Marc suggested. You can actually send mail to someone who posts anonymously through Pax just as easily as you could send to someone who posted non-anonymously. So if you want to complain about some offensive posting or email to the person who did it, you still could with Pax. These features didn't stop Pax from getting shut down. Marc's suggestion that commercial users could run remailers without pressure from NSF sounds good in theory, but it's not clear how well it would work in practice. I don't think Cypherpunks could run such a remailer, even if Marc is right and it would cost $10 per Cypherpunks reader per month. I doubt that many people would be willing to make this charitable contribution for what would be a public good - a remailer that anyone could use. Even if it could be done, one remailer isn't enough. We need many remailers so that no one remailer can expose users. I think the best bet would be a commercial site which has a connection for other reasons, and which is willing to run a remailer on the side. I don't know what kinds of sites use these commercial connections. The commercial Internet access that I am aware of is through companies like Compuserve, Portal, Netcom, the WELL, and so on, and I think they all have to abide by the NSF acceptable use policies. At least, I had to agree to those on Portal and I think on Compuserve. What would be an example of a site with commercial Internet access which would be free of NSF pressure? One other point I'd make with regard to Marc's message is that if PGP itself is the problem, there's no reason the remailers can't use RIPEM. That's legal in the U.S., so the legality issue would not arise. This might be a good approach to take in broaching the subject with administrators. I haven't looked at RIPEM much but I'm sure the remailers could use it just as easily as PGP. Even non-encrypting remailers can provide basic anonymous posting and mail, if those would be more acceptable. A final point is that forwarding mail for another person can hardly be made illegal in general. If I receive a message from person A asking me to forward it on to person B, and I do so, this is clearly a legitimate email message that I choose to send. To try to disallow this would be to put intolerable restrictions on email content. So, if this is allowed, it seems to me that I should be able to write a program to do what I am allowed to do manually. If these remailers could be made widespread, with tens of thousands of people running them as a routine service, I think a crackdown would be much more difficult. I think we need to educate users about the value of privacy and anonymity in order to encourage more people to run remailing software. Can anyone suggest a newsgroup where these kinds of discussions would be appropriate? Hal Finney 74076.1041 at compuserve.com From 74076.1041 at CompuServe.COM Thu Jan 14 23:19:06 1993 From: 74076.1041 at CompuServe.COM (Hal) Date: Thu, 14 Jan 93 23:19:06 PST Subject: Electronic money legality Message-ID: <930115071353_74076.1041_DHJ55-2@CompuServe.COM> The question came up here some time ago as to whether it would be legal to issue electronic money, or regular money, for that matter. I got a couple of books out of the library to try to learn something of the history of private bank notes. It seems that private bank notes were the rule rather than the exception in the U.S. up until around the time of the Civil War. However, the notes were issued by banks which generally had a charter or license from the state government. I'm not sure whether a private individual could have legally issued his own banknotes without state permission. Around the time of the Civil War the Federal government levied a 10% tax on all issues of banknotes. This was intended to drive them out of use, and it did. Apparently this tax is still in effect today. George Selgin's book, The Theory of Free Banking, is a call to return to a situation of competitive note issue, where each bank would print its own "money" and people would use all these different monies freely according to their preferences. Regardless of the pros and cons of this idea, he does mention the legal situation briefly in footnote 7 of chapter 11: "Strictly speaking, issue of bank notes by commercial banks is not presently illegal; however, such issue must still meet the bond-deposit requirements established under the National Banking System or the 10 percent tax on state bank notes. Since all bonds eligible as security for circulating notes were retired before 1935 (or had the circulation privilege conferred upon them withdrawn), note issue, while not illegal, is nevertheless impossible under existing law. Restoration of commercial bank note-issuing privileges merely requires repeal of the bond deposit provisions of the original National Banking statutes and of the prohibitive tax on bank notes." One other point I learned was about the nature of "legal tender" laws. If a money is a legal tender, a creditor cannot turn down an offer by a debtor to repay using that money. If he does turn it down, the debt is void (roughly). So, legal tender laws don't forbid repayment of a debt in some other form (I can give you a bike in place of the $100 I owe you), (if we both agree), but they may specify that even if a debt is denominated in some other units, I can repay using federal reserve notes. This is what happened when the U.S. stopped redeemin for gold during the 1930's - long-term contracts had routinely been denominated in gold, but the courts held that dollars could still be used to pay them off. So, legal tender laws don't appear relevant to the use of digital money, except that contracts based on digicash could still be paid off by dollar bills if the debtor wants. Hal Finney 74076.1041 at compuserve.com From marc at MIT.EDU Thu Jan 14 23:40:28 1993 From: marc at MIT.EDU (Marc Horowitz) Date: Thu, 14 Jan 93 23:40:28 PST Subject: possible solution to the anonymous h In-Reply-To: <930115065840_74076.1041_DHJ55-1@CompuServe.COM> Message-ID: <9301150739.AA02931@deathtongue.MIT.EDU> >> One other point I'd make with regard to Marc's message is that if PGP itself >> is the problem, there's no reason the remailers can't use RIPEM. That's >> legal in the U.S., so the legality issue would not arise. This might be >> a good approach to take in broaching the subject with administrators. I >> haven't looked at RIPEM much but I'm sure the remailers could use it just >> as easily as PGP. Even non-encrypting remailers can provide basic >> anonymous posting and mail, if those would be more acceptable. I thought about this. The major problem is that once the PEM beta-testing period ends, all keys must be registered with "approved" (by RSA) central authorities. I highly doubt they'd issue pseudonymous keys, but maybe they would allow someone to set up a heirarchy especially for that purpose. I'm not convinced. Marc From dclunie at pax.tpa.com.au Fri Jan 15 00:05:55 1993 From: dclunie at pax.tpa.com.au (David Clunie) Date: Fri, 15 Jan 93 00:05:55 PST Subject: possible solution to the anonymous h Message-ID: <9301150805.AA01054@britt> > I thought about this. The major problem is that once the PEM > beta-testing period ends, all keys must be registered with "approved" > (by RSA) central authorities. I highly doubt they'd issue > pseudonymous keys, but maybe they would allow someone to set up a > heirarchy especially for that purpose. I'm not convinced. Who says ? RSA may wish this to happen, but surely anyone who wants to can set up their own key service. david From marc at MIT.EDU Fri Jan 15 00:32:18 1993 From: marc at MIT.EDU (Marc Horowitz) Date: Fri, 15 Jan 93 00:32:18 PST Subject: possible solution to the anonymous h In-Reply-To: <9301150805.AA01054@britt> Message-ID: <9301150831.AA02997@deathtongue.MIT.EDU> >> Who says ? RSA may wish this to happen, but surely anyone who wants to can >> set up their own key service. RSA has a patent on their algorithm. It's quite likely that I can't even create a key pair without their permission, let alone use it. Marc From dclunie at pax.tpa.com.au Fri Jan 15 00:38:16 1993 From: dclunie at pax.tpa.com.au (David Clunie) Date: Fri, 15 Jan 93 00:38:16 PST Subject: possible solution to the anonymous h Message-ID: <9301150837.AA01096@britt> > RSA has a patent on their algorithm. It's quite likely that I can't > even create a key pair without their permission, let alone use it. I am not familiar with the legal status of patents and software packages, but it seems to me that they can sell you a program and license you to use it, but forcing you to use one of their key servers instead of your own seems pretty far fetched. I would be very surprised if the law is clear cut on this issue, or has ever been tested. I gather software licenses are pretty hazy territory at the best of times without getting involved in patent law as well !@#$ david From Marc.Ringuette at GS80.SP.CS.CMU.EDU Fri Jan 15 00:56:06 1993 From: Marc.Ringuette at GS80.SP.CS.CMU.EDU (Marc.Ringuette at GS80.SP.CS.CMU.EDU) Date: Fri, 15 Jan 93 00:56:06 PST Subject: possible solution to the anonymous harrassment problem Message-ID: <9301150856.AA27483@toad.com> > RSA has a patent on their algorithm. It's quite likely that I can't > even create a key pair without their permission, let alone use it. You're poorly informed. As a condition of a grant from DARPA to RSADSI, RSAREF may be used noncommercially, for free, to do any of the following: - RSA encryption and key generation, as defined by RSA Data Security's Public-Key Cryptography Standards (PKCS) [4] - MD2 and MD5 message digests [3,5,6] - DES (Data Encryption Standard) in cipher-block chaining mode [7,8] Moreover, I believe you'll find that RSADSI has become much more helpful recently. For more information, anonymous ftp to rsa.com and look around. I've just gone over the RSAREF license agreement again. It seems to permit any sort of not-for-profit operation, including a public key service. -- Marc Ringuette (mnr at cs.cmu.edu) From mark at demon.co.uk Fri Jan 15 01:32:56 1993 From: mark at demon.co.uk (Mark Turner) Date: Fri, 15 Jan 93 01:32:56 PST Subject: /usr/lib/newsbin/ctl/newgroup: `news@math.fu-berlin.de (Math Department)' tried (fwd) Message-ID: <9301150930.aa08405@demon.demon.co.uk> You may be interested in this recent attempt to create a bogus newsgroup, especially if you've been following recent discussion in sci.crypt. Regards, Mark. According to news at dis.demon.co.uk.... > From dis.demon.co.uk!news Fri Jan 15 00:38:27 1993 > To: usenet at dis.demon.co.uk > Subject: /usr/lib/newsbin/ctl/newgroup: `news at math.fu-berlin.de (Math Department)' tried > Date: Fri, 15 Jan 93 0:33:57 GMT > From: news at dis.demon.co.uk > Sender: news at dis.demon.co.uk > Message-ID: <9301150033.aa12907 at dis.demon.co.uk> > > /usr/lib/newsbin/ctl/newgroup: `news at math.fu-berlin.de (Math Department)' tried > to create newsgroup `alt.fan.david-sternlight'. > Request was refused: component exceeds 14 characters. > === > Control: newgroup alt.fan.david-sternlight > Newsgroups: alt.fan.david-sternlight.ctl,control > Path: demon!pipex!bnr.co.uk!bnrgate!nott!torn!spool.mu.edu!yale.edu!ira.uka.de!math.fu-berlin.de!lkdfjilu!sternlight.com!nobody > From: dsfc at sternlight.org > Subject: newgroup alt.fan.david-sternlight > Message-ID: > Sender: news at math.fu-berlin.de (Math Department) > Organization: J. Random Site > Date: Wed, 13 Jan 1993 20:14:32 GMT > Approved: news > Lines: 21 > > > one mo' time... > > For your newsgroups file: > alt.fan.david-sternlight David Sternlight, sci.crypt crusader > > > This group is designed for the praise of the wit and wisdom of our > leader, David Sternlight, the man battling the evil use of > cryptography wherever it may lie. > > The group is being created entirely for the use of the David > Sternlight Fanclub, which holds the patent on this newsgroup and would > be forced to sue if anyone else tried to use it. Indeed, we would be > disgusted by the implicit lack of respect for intellectual property. > Also, this newsgroup may not be imported or exported from any eastern > block country in contravention of the ITARs. > > Thank you, > > The David Sternlight Fanclub > === -- /\/\ark Turner Demon Systems / Demon Internet Office: mark at demon.co.uk (+44 81 349 0063) 42 Hendon Lane, London Home: mt at kram.org (+44 831 823 212) N3 1TT, England ------------------ PGP version 2.0 Public Key available ------------------- *** IP level dial-up connectivity to the Internet for a tenner a month! *** From eric at parallax.com Fri Jan 15 01:40:12 1993 From: eric at parallax.com (Eric Messick) Date: Fri, 15 Jan 93 01:40:12 PST Subject: Details on return envelopes Message-ID: <9301150713.AA29658@parallax.com> As per Hal's suggestions, I've come up with a simpler example. I've also hardened it against an attack that he noticed, which has considerably changed the protocol. Hal writes: > Another general point, which may be important. Chaum emphasized that his > anonymous addresses should be use-once, because if two people send messages > to the same anonymous address, someone who has access to the mail going > into and coming out of the remailer will see identical address fields > coming out for the pair of messages. I think Eric's scheme has the same > property. While thinking about this weakness, I realized that everything gets a lot easier if each (re)mailer knows the public key of the next. This is public knowledge, so there's no need to hide the key once the next destination is known. If there was a complete database of public keys of remailers that each remailer had, the key could be found from the address. Since that database might not be up to date, the public key is transmitted along with the address. Consequently, I was able to remove all of the conventional keys from the protocol. All encryptions are now done with public keys. Of course, there is still the conventional encryption done for each public key encrypted packet. The protocol is strengthened against this attack by fresh encryptions at each stage which hide the constant string. Note that the remailer itself can still identify the set of messages that were sent using the same envelope. It would be nice to fix this, but it seems unlikely at this point. Any ideas anyone? --------------------------------------------------------------------- I've got two examples here: a paired down one, and a slightly fuller one. The first has no postage, which cuts down considerably on the excess. The second example is just the first with the postage added back in (just to show that it still works). The envelope specifies hosts &Z and &R. The sender routes the message through &Y before using the envelope. So, the message goes from &S to &Y to &Z to &R where it is delivered. The complete simplified transaction is reproduced below, starting with the initial envelope: Addr: &Z, z, z(&R, r, r(junk)) To: &Y Addr: y(y(&Z, z, z(&R, r, r(junk))), pad) Message: y(M, pad) To: &Z Addr: z(z(&R, r, r(junk)), pad) Message: z(M, pad) To: &R Addr: r(r(junk), pad) Message: r(M, pad) The sender basically ignores the contents of the envelope, but wraps it in the public key y for safe delivery to &Y. The message and the address info are both then padded and encrypted with y. The reason for encrypting the address info with y twice will become clear shortly. &Y receives the message labeled To: &Y above. The outer y encryptions are removed, followed by the inner y encryption on the address field. The message M, and the original envelope are thus revealed to &Y. &Y now knows to send the message to &Z, and knows the public key z. The message M is then padded and encrypted with z. There is already a portion of the address field that is encrypted with z. That portion contains all of the info that &Z needs to know, but this info, as Hal pointed out, is a constant string; an external observer could use this to associated a group of messages with a single envelope. To obscure this, the string is encrypted a second time with z. Recall that a random conventional key is generated each time a public key encryption is done, so a constant plaintext string will encrypt to a different cyphertext string each time. The padding helps keep the string from being identified by its length. To keep the protocol consistent, the original envelope had to be encrypted with y twice. The resulting message is sent to &Z, where the same processing is done. Let's trace it in detail this time, but without the extraneous padding. &Z has received: Addr: z(z(&R, r, r(...))) Message: z(M) Which looks to the outside world like: Addr: z(...) Message: z(...) But &Z can decrypt those z(...)'s to obtain, first: Addr: z(&R, r, r(...)) Message: M And then: Addr: &R, r, r(...) Message: M With r thus exposed, &Z can encrypt both M and r(...) with it to obtain: To: &R Addr: r(r(...)) Message: r(M) Which to the outside world looks like: To: &R Addr: r(...) Message: r(...) With everything nicely hidden. This is what gets sent to &R. Knowing r, &R can recover M. We're done. -------------------------------------------------------------------- I'll present the postage example without further comment, except to note that at each step, all fields are freshly encrypted with the next hop's public key. Addr: &Z, z, z(Sz, Qz, &R, r, r(junk)) Pneed: Pz, Amt_z, Pr, Amt_r To: &Y Addr: y(y(Sy, Qy, &Z, z, z(Sz, Qz, &R, r, r(junk))), pad) Post: y(Py($y, Pz($z, Pr($r))), pad) Pdue: y(Qs(stuff_s), pad) Message: y(M, pad) To: &Z Addr: z(z(Sz, Qz, &R, r, r(junk)), pad) Post: z(Pz($z, Pr($r)), pad) Pdue: z(Qy(stuff_y, Qs(stuff_s)), pad) Message: z(M, pad) To: &R Addr: r(r(junk), pad) Post: r(Pr($r), pad) Pdue: r(Qz(stuff_z, Qy(stuff_y, Qs(stuff_s))), pad) Message: r(M, pad) -eric messick From eric at parallax.com Fri Jan 15 01:40:12 1993 From: eric at parallax.com (Eric Messick) Date: Fri, 15 Jan 93 01:40:12 PST Subject: Details on return envelopes (padding) Message-ID: <9301150753.AA29918@parallax.com> Hal writes: > I did spot one possible problem. Remailer &V sends to &W an address > field that looks like: > > Addr: w(B), w(Sw, Qw, C, &X, x(C), x(...), pad) > > but I don't think &V has enough information to create the 2nd item here. > The reason for the A, B, etc. keys is, I think, to allow new padding to > be done as the message gets passed between each pair of remailers. > I think that may need to be used here as well. &V can't put padding into > the w(Sw,...) block. It may not be at all obvious or intuitive, but &V *CAN* put padding into the w(...) block. I'm no longer trying to do this (see my previous posting), but it could still be useful in some situations, so I'll try to explain it more clearly. PGP uses binary structures for all of this, but I'm going to pretend that it's all ascii, just so we can see what's going on easier. That block w(...) looks something like this: CTB: RSA <-- that's *C*ypher *T*ype *B*yte Length: 12345 bytes Key_ID: w IDEA_key: RSA(w, random_key) CTB: IDEA Length: 12315 CTB: Plain Text Length: 12300 Here we have 12300 characters. Note that all of the lines that are indented are encrypted with random_key using the IDEA cypher. ...End of the encrypted text. To add padding to this, simply append some cryptographically strong random bytes to the end, and adjust the unencrypted lengths by that much. No one can tell that your new bogus lengths don't match the length on the plaintext packet without actually being able to see the plaintext packet length field. The decryptor believes the plaintext packet length, and automatically throws away the bogus bytes that were decrypted. While writing this, I realized that when I tested this, I may have only changed the outermost length. It is possible (but I think it is highly unlikely) that PGP would get sick if you changed the second length value. Since I no longer need to do this, I don't have any incentive to check this out again. It's not that difficult, but I hate editing binary files... -eric messick From root at tnl.com Fri Jan 15 03:36:22 1993 From: root at tnl.com (Daniel Ray) Date: Fri, 15 Jan 93 03:36:22 PST Subject: need for more anon remailer sites Message-ID: <9301150402.AA07973@tnl.com> With the shutdown of PAX, if we are not going to roll over and let this type of site go away, what we need is a large new group of such sites. 20-50 or more anonymous remailer sites that each gets used randomly and occaisionally, with usernames that are not obvious such as "anon432", both in the U.S. and elsewhere in the world, are whats needed. the list of sites must remain fluid and unpredictable, and formats and conventions must also variate so that no one can get "a fix" on it. A person that wants to anonymously mail something can choose different sites each time, or perhaps there may be a subsystem that chooses this for them, WITHOUT the mail actually going there first, if a site is in charge of "ran- domizing" the traffic. I suggest using a truly covert approach of using non-account first names and other interesting words that are indistinguishable from regular usernames as anonymous temporary mailing names. This obviously is very tricky and would have to be worked out carefully, since it may, even in the future, conflict with an actual choice of a valid username for an anonymous site. But it can be done. and we need to spare the .sig at the bottom that advertises the anon service. that should be left to separate ads, not mixed in covert email itself. One of the things that has gotten to me is to do secret acts in overt ways, almost asking the Government to defy them! Secret things should be done secretly. Once, if in the future, cryptographic email is so common as to make this unnecessary, then we can relax it. But not completely. Secret should still always be DONE IN A SECRET WAY. I.e. using steganography and other covert procedures, fluid, nonfixed proce- dures, to ensure no disturbance with rerouted and/or encrypted email traffic. Yes this is security-by-obscurity, but it can work if it is just an adjunct to other strong methods such as good ciphers and procedures that use proper contingency planning. PAX, most likely, did no contingency planning for what happened to it. All things of this type need "what ifs" for every possible interference that can happen, not that all possibilities would be addressed. But they should all be looked at, if they can be thought of. Suppose the ante goes up and all this stuff becomes actively illegal. What then? If a large network is *already* in place, the risk is much lower than trying to do something after the fact. And it would be a more mature network of rerouting and encrypting sites, that have already learned from their mis- takes. we need --all--this-- to survive. otherwise it is all just a toy application of covert technology. norstar The Northern Lights, Troy NY | tnl dialins: +1 518 237-2163 @ 1200-2400 bps 8N1 $free ` | / ------------------------------------------------------- --- * --- Internet: norstar at tnl.com / | . Sysop of TNL Public Access UNIX | From norstar at tnl.com Fri Jan 15 03:36:26 1993 From: norstar at tnl.com (Daniel Ray) Date: Fri, 15 Jan 93 03:36:26 PST Subject: more on security/obscurity/reality Message-ID: <9301150610.AA09544@tnl.com> Thinking about everything some more, I have a few more things to say regarding my previous message stating the need for 20-50 new networked and "randomized" anon remailer sites, and the need to keep secret things secret. One thing I've really noticed over the 5 or 6 years I've been on the net is the real hatred people have for what is coined "security by obscurity." I think it is because of the terrible way people have gotten burned by relying on conceiled methods only, or secret algorithms as ciphers to protect their material. The method is discovered one way or another, and everything caves in on itself! Quite understandable. Yet I cringe at the way people have just turned their backs on the whole meta-philosophy of "coversion." If, for instance, you are to do battle with an unbearable, overwhelming power, such as the Government, then what is the only real way to "win?" Besides convincing them not to do battle with you? It is by staying conceiled, secret, untargetable. If they don't know to fight you, or, if they do know, but cannot find you, then you stay all right. Once it gets to a face-to-face confrontation, however, you lose, and you lose immediately, there is nothing you can bring to bear, since it is now just a force equation, and they have over 10,000 times the force you do. Or more... This is one of the applications of the secret side of life. Modern crypto- graphy has advanced, I think, by declaring all coversion as eventually discoverable, and only seeking algorithms that will suffice even if the enemy knows your methods. I agree with this. I guess I part company, however, when people totally throw out being secretive as a partial or adjunctive solution to something that is intrinsicly secret to begin with. The addition of conceilment, disinformation, invisibility, etc. can be a tremendous advantage when combined with strong methods (good ciphers that don't rely on coversion). It is a multilayered approach that first tries to not become a target, and, if it is a target is still hard to crack. When us little people try to maintain privacy against a Govt. that is REALLY PISSED OFF BY EVEN THE IDEA WE WANT TO STRONGLY PROTECT OURSELVES, a multi- layered, contingency-based approach is required. The most important part of it is not a strong cipher, but, not to become a detectable or locatable target. i.e. coversion and secrecy. People, in response to the PAX snafu, have advocated some kind of protest and demonstration as a solution. Sure, these can be tried. But no Govt. in its right mind will let this powerful privacy go on. It just cancels them out, and they will not have it. It'll get worse as time goes on. It applies equally to "free" and non-democratic Governments. To the world community itself. They will not have it. And we will not have them. So there you are. What to do? Create a fluid, "night"-based, invisible and unfixable multi- system of coversion and strong ciphers. So, if they get a part, the rest goes on as before. All parts of it well thought out. Everything subject to evolution, but, a base assumption that things are already quite bad. They are. I wish more of you actually lived an illegal life...you would know what I am saying without the need to say it. You need to have really faced a real risk against authority, with YOUR life on the line. And no amount of talk substitutes for experience here. Oh well. norstar The Northern Lights, Troy NY | tnl dialins: +1 518 237-2163 @ 1200-2400 bps 8N1 $free ` | / ------------------------------------------------------- --- * --- Internet: norstar at tnl.com / | . Sysop of TNL Public Access UNIX | From ncselxsi!drzaphod at ncselxsi.netcom.com Fri Jan 15 07:48:00 1993 From: ncselxsi!drzaphod at ncselxsi.netcom.com (DrZaphod) Date: Fri, 15 Jan 93 07:48:00 PST Subject: If People Were Honest Message-ID: <23669.drzaphod@ncselxsi> In Message Thu, 14 Jan 1993 18:56:47 -0500, Marc Horowitz writes: > Remember, if people were honest, we wouldn't need encryption, > either. Sigh. Being honest has nothing to do with wanting privacy. Every mail system should have, and NEEDS a way to be anonymous. That is all. TTFN! DrZaphod [AC/DC] / [DnA][HP] [drzaphod at ncselxsi.uucp] Technicolorized From ncselxsi!drzaphod at ncselxsi.netcom.com Fri Jan 15 07:48:00 1993 From: ncselxsi!drzaphod at ncselxsi.netcom.com (DrZaphod) Date: Fri, 15 Jan 93 07:48:00 PST Subject: Fans!? Message-ID: <23683.drzaphod@ncselxsi> In Message Fri, 15 Jan 1993 09:30:37 +0000 (GMT), Mark Turner writes: >> For your newsgroups file: >> alt.fan.david-sternlight David Sternlight, sci.crypt crusader >> The David Sternlight Fanclub Joke, Right???? DrZaphod [AC/DC] / [DnA][HP] [drzaphod at ncselxsi.uucp] Technicolorized From opac!brian%OPAC.osl.or.gov at CS.ORST.EDU Fri Jan 15 08:43:25 1993 From: opac!brian%OPAC.osl.or.gov at CS.ORST.EDU (BRIAN MCBEE) Date: Fri, 15 Jan 93 08:43:25 PST Subject: pax shutdown Message-ID: <00966A38.A1B67300.22879@OPAC.OSL.OR.GOV> > I agree that the PAX shutdown is an ominous development. Nobody's > internet access is perfectly free from the kinds of pressures that were > brought against PAX. What steps can we take to keep the same thing from > happening to us? > > I agree with Karl that a big step would be to spread remailers more widely. > Eric Hollander is running three remailers in addition to the ones Karl > mentioned - hh at soda.berkeley.edu, and two other machines which I don't > have handy. They don't encrypt but they forward, and that's good enough > for many purposes. > > Some time back, there was mention that the owner of the commercial Portal > system would run one. Could someone follow up on that who knows him? > > PGP is gradually disappearing from U.S. sites where it used to be > available. Recently it got taken off the EFF area on Compuserve. > We can't afford to see encryption and remailers be slowly strangled. > > Hal > 74076.1041 at compuserve.com If it turns out that pressure to shut down really did come from the official net hierarchy, there are other places on the net which should be nearly immune from that kind of pressure. There are thousands of UUCP sites which predate the Internet. And anyone getting their connectivity from one of the commercial providers (PSI, UUNET, ANS, etc.) can theoretically use those networks for whatever purposes they choose. ----- Brian McBee ----- (503)378-4276 ----- brian at opac.osl.or.gov ----- ----- Oregon State Library, State Library Building, Salem, OR 97310 ----- Plan globally, attack locally From gnu Fri Jan 15 09:15:32 1993 From: gnu (John Gilmore) Date: Fri, 15 Jan 93 09:15:32 PST Subject: need for more anon remailer sites In-Reply-To: <9301150402.AA07973@tnl.com> Message-ID: <9301151715.AA06478@toad.com> I suggest using a dictionary to come up with "names" of anonymous users: aback abacus abalone abandon abase abash abate abater abbas ... You could pick them in random order, or sequentially. > Suppose the ante goes up and all this stuff becomes actively illegal. What > then? If a large network is *already* in place, the risk is much lower than > trying to do something after the fact. And it would be a more mature network This technology is sufficiently cheap to replicate that it doesn't matter whether we set up a "covert" network before or after it becomes illegal (if ever). What matters is that we have experience at running such a network. Such experience is much easier to come by in the open -- since you can talk about it! While I applaud the efforts of some people to set up contingencies for "after we lose our liberties and need to actively oppose the government", please don't forget to actively oppose poor government policies *now*, before the loss of that liberty. In other words, there's plenty of work to be done today to *keep* this an open society. And it's much easier to keep one than to get one back. John Gilmore From uri at watson.ibm.com Fri Jan 15 09:27:02 1993 From: uri at watson.ibm.com (uri at watson.ibm.com) Date: Fri, 15 Jan 93 09:27:02 PST Subject: possible solution to the anonymous... In-Reply-To: <9301150739.AA02931@deathtongue.MIT.EDU> Message-ID: <9301151725.AA12991@buoy.watson.ibm.com> Marc Horowitz says: > >> I haven't looked at RIPEM much but I'm sure the remailers could use it > >> as easily as PGP. Even non-encrypting remailers can provide basic > >> anonymous posting and mail, if those would be more acceptable. > I thought about this. The major problem is that once the PEM > beta-testing period ends, all keys must be registered with "approved" > (by RSA) central authorities. Oh, NO! RSADSI will CERTIFY you keys, IF YOU WISH; and they'll certify your PERSONAL keys for free (unlike any other level of "confidence", which MAY cost money :-)... Where did you get this idea from? [Also it's my understanding, that one could use other certifying authorities besides RSADSI]. -- Regards, Uri uri at watson.ibm.com scifi!angmar!uri N2RIU ----------- >From cypherpunks-request Fri Jan 15 09:38:17 1993 From gnu Fri Jan 15 09:28:27 1993 From: gnu (John Gilmore) Date: Fri, 15 Jan 93 09:28:27 PST Subject: If People Were Honest In-Reply-To: <23669.drzaphod@ncselxsi> Message-ID: <9301151728.AA06697@toad.com> A few days ago I had a personal illustration of how even honest people need privacy. The Board of Directors of EFF had met to make some decisions. Some of these involved firing employees, closing offices, etc. (See comp.org.eff.news and .talk for all the details). It took a few days to finalize everything, though. During that time, we needed privacy in order to not hurt people (they might hear a false rumor that was the result of an intermediate stage in the decision; they might hear from some source other than us that they were losing their jobs, etc). We seriously had to consider whether to use email to work out the final details, since the system administrators had not yet been told. Cellular phones were right out. As it worked out, it was fine. The announcement was posted to the net slightly after the meeting in which we told all the employees what was happening. I won't say nobody was hurt -- we all were -- but we were all a lot less hurt than if the staff had "accidentally" found out, before anyone responsible for the decision had told them personally. John From pfarrell at cs.gmu.edu Fri Jan 15 09:30:59 1993 From: pfarrell at cs.gmu.edu (Pat Farrell) Date: Fri, 15 Jan 93 09:30:59 PST Subject: shrinking availability of PGP Message-ID: <9301151728.AA20322@cs.gmu.edu> On 14 Jan, Hal wrote: > >PGP is gradually disappearing from U.S. sites where it used to be >available. Recently it got taken off the EFF area on Compuserve. >We can't afford to see encryption and remailers be slowly strangled. > I agree that this would be terrible. Do you have any grounding for this generalized statement? I can understand CI$ backing off, as they were the only organization in the US making a profit from PGP. And they have the resources and assetts that could be a target if PKP wanted a test case. I just had archie look arround, and to me the number of places was about the same. For some reason, archie doesn't find it in two places I know it is: soda.berkeley.edu and phil.utmb.edu Archie did report that it is on wuarchive. I'm affraid that the legal cloud will remain over PGP for quite some time, and that the flawed PEM implementations will become the standard. Until there is someone with real assetts using PGP, PKP's lawyers will not bother to expose their patent to the possibility of being invalidated. I also don't expect to see those of us who are assett free changing from PGP to RIPEM/PEM just because it is free of the cloud. This cloud will make folks who are nervous about the changes that netwroks, communications, and encryption will bring more cautious. I expect that PGP will continue to move from site to site. Which is why archie and gopher are so important to all of us. Pat Pat Farrell, Grad Student pfarrell at cs.gmu.edu Department of Computer Science, George Mason University, Fairfax, VA PGP key available via finger or request #include standard.disclaimer From gnu at cygnus.com Fri Jan 15 09:36:17 1993 From: gnu at cygnus.com (gnu at cygnus.com) Date: Fri, 15 Jan 93 09:36:17 PST Subject: Whitfield Diffie gets award Message-ID: <9301151735.AA17487@cygnus.com> SUN ENGINEER RECEIVES INTERNATIONAL AWARD; FOUNDED NEW FIELD OF SCIENTIFIC RESEARCH MOUNTAIN VIEW, Calif. -- January 13, 1993 -- Whitfield Diffie, 48, Distinguished Engineer at Sun Microsystems Computer Corporation (SMCC), was recently awarded the degree of Doctor of Technical Sciences, Honoris Causa, by the Swiss Federal Institute of Technology. The award was given for founding a new field of scientific research, public key cryptography, which grew out of discoveries Diffie made at Stanford University in 1975. The Swiss Federal Institute of Technology, or ETH after the initials of its German name, is one of the most prestigious technical universities in the world. It counts among its alumni some of the foremost scientists of the 20th century, including Albert Einstein and John VonNeuman. Doctorates "by reason of honor" make up less than one tenth of the total number of doctoral degrees awarded by the ETH. They are granted for major scientific or engineering achievements and are given only after a nomination and review process taking two to three years. In conventional cryptography, encrypting and decrypting messages were inseparable; anyone who could create an encrypted message could also read it and vice versa. By separating these functions, public key cryptography allows people to guarantee the privacy of conversations with people they have never met before and to apply unforgeable "digital signatures" to their messages. In Diffie's words: it does what signatures and envelopes do for ordinary mail. At the time Diffie began his work in cryptography, he was one of only a handful of people not employed by government intelligence agencies who took a serious interest in the field. Today, the International Association for Cryptologic Research, of which he is one of the founding directors, has hundreds of members from industry and academia worldwide. Diffie joined Sun in the summer of 1991 with the title of Distinguished Engineer, although one of his inventions had already been used in the company's security products since 1987. In hiring Diffie, Sun recognized both the rising importance of security in computer communications and the critical role of cryptography in achieving that security. In the latest Sun(TM) Solaris(R) operating system, the original "secure RPC" has been improved, while more comprehensive applications of cryptography are planned for future versions of Solaris. Sun Microsystems Computer Corporation (SMCC) is the world's leading supplier of open client-server computing solutions. With headquarters in Mountain View, Calif., SMCC is an operating company of Sun Microsystems, Inc. ### Sun Microsystems, Sun Microsystems Computer Corp., Sun, the Sun logo, are trademarks or registered trademarks of Sun Microsystems, Inc. Solaris is a registered trademark of Sun Microsystems, Inc. From uri at watson.ibm.com Fri Jan 15 09:58:13 1993 From: uri at watson.ibm.com (uri at watson.ibm.com) Date: Fri, 15 Jan 93 09:58:13 PST Subject: possible solution to the anonymous... In-Reply-To: <9301150837.AA01096@britt> Message-ID: <9301151731.AA13017@buoy.watson.ibm.com> David Clunie says: > > RSA has a patent on their algorithm. It's quite likely that I can't > > even create a key pair without their permission, let alone use it. > > I am not familiar with the legal status of patents and software packages, > but it seems to me that they can sell you a program and license you to > use it, but forcing you to use one of their key servers instead of your > own seems pretty far fetched. Anyway, RSADSI released RSAREF toolkit free for non-commercial use. RIPEM (with RSAREF bundled in :-) allows you to create as many key pairs as your soul wishes. And surprise, you are allowed to use them... So let's face real problems, rather than RSA patent (which hopefully will expire by itself :-). -- Regards, Uri uri at watson.ibm.com scifi!angmar!uri N2RIU ----------- >From cypherpunks-request Fri Jan 15 15:51:35 1993 From 74076.1041 at CompuServe.COM Fri Jan 15 10:13:47 1993 From: 74076.1041 at CompuServe.COM (Hal) Date: Fri, 15 Jan 93 10:13:47 PST Subject: RIPEM vs PEM Message-ID: <930115175946_74076.1041_DHJ57-1@CompuServe.COM> There is a little confusion here between RIPEM and PEM. PEM is the "official" Internet standard for Privacy Enhanced Mail. An implementation is in beta test right now, and uses a centralized certificate hierarchy for all keys. Everyone has to have their keys signed by an agency which is authorized by RSADSI (at least according to the Internet drafts I have, which are several months old). Typically, that agency would be your company or your school, because they are in a position to vouch for your identity. There is a provision, though, for pseudonymous keys to be issued, although they would be clearly marked as such. RIPEM is Mark Riordan's public-key program. It is similar to PEM, but does not use the PEM certificates and therefore does not require people to have their keys signed by an agency. It is not really PEM compatible. It does use the RSAREF public-domain encryption package, so it is legal for non- commercial use in the U.S. and Canada. What I suggested was the use of RIPEM since it is available now, is legal, and is free. Note, though, that whether RIPEM or PGP is used, they are only for non- commercial use. A remailer that wanted to charge, such as the ones that Eric Messick is discussing, would probably have to license the technology from PKP directly to be legal. (I'm not sure whether PEM also is limited to non-commercial use.) Hal Finney 74076.1041 at compuserve.com From 74076.1041 at CompuServe.COM Fri Jan 15 10:39:53 1993 From: 74076.1041 at CompuServe.COM (Hal) Date: Fri, 15 Jan 93 10:39:53 PST Subject: more on security/obscurity/reality Message-ID: <930115183334_74076.1041_DHJ45-1@CompuServe.COM> I can understand Daniel Ray's proposing to keep a low profile in running remailers, using encryption and such. Pax was probably the highest profile service, at least in the Usenet groups I use, and look what happened to it. The problem is, how can a remailing service be secret? Its address has to be known in order for it to be used! The only way it could be secret that I can see would be for it to have only a small, select group of "clients" who use it, and who keep the address to themselves. But there is no such group; it's not like there's some kind of ring of privacy lovers out there who will want to use such services but who will be willing to keep the servers secret. If remailers are going to be useful, they _have_ to be public. People have to know how to reach them in order to use them. The real task, it seems to me, is to justify anonymous mail to the Internet public, so that people will not support these shutdowns, and, even better, so that people will routinely use encryption and even remailing when they communicate. Eric Hughes made the point here some time back that we should aim for a society where sending non-encrypted remail is considered rather eccentric: "What? You send your mail _exposed_? You don't mind if everyone reads it?" In the same way, sending mail in such a way that everyone can see who you are communicating with, and that everyone you send to can see your true address automatically, could become equally unusual. One other point I'd make regards the use of pseudonyms for replying. The Pax service created a pseudonym for each person who used the service which was put into the "From:" line of outgoing mail. Then people could reply to that pseudonym and it would go back to the original sender. The problem with this approach, as far as spreading remailers, is that you have to have privileges on your machine in order to create new user ID's. An individual user who doesn't own or run a machine is generally not able to create such pseudonyms. This means that the number of people who can run remailers which use such features is much smaller than the number who can run the simpler Cypherpunks remailers in their current versions. The Cypherpunks remailers do allow for anonymous return addresses, but they are quite cumbersome to use, not automatic like the Pax type. But they do have the advantage that anyone who has access to Unix, PGP and Perl can run them. This is probably a much larger population. Hal From jordan at imsi.com Fri Jan 15 11:18:55 1993 From: jordan at imsi.com (Jordan Hayes) Date: Fri, 15 Jan 93 11:18:55 PST Subject: pax shutdown Message-ID: <9301151813.AA26738@IMSI.COM> From: BRIAN MCBEE If it turns out that pressure to shut down really did come from the official net hierarchy ... There is no question: those who were paying for the (quite expensive, relatively low bandwidth) connection between the US & Australia found themselves with a saturated link and looked for a "good candidate" to shut off. It turns out that lots of the packets are mail, and a good number of the mail messages were going to/from the anonymous service. This was not a move against anonymous e-mail or the research into it. This was just an abuse of "someone elses money" that was easy to target. Next topic please ... this is getting tired. /jordan From warlord at MIT.EDU Fri Jan 15 11:19:09 1993 From: warlord at MIT.EDU (Derek Atkins) Date: Fri, 15 Jan 93 11:19:09 PST Subject: possible solution to the anonymous harrassment problem In-Reply-To: <9301150856.AA27483@toad.com> Message-ID: <9301151918.AA06316@toxicwaste.MEDIA.MIT.EDU> > You're poorly informed. As a condition of a grant from DARPA to RSADSI, > RSAREF may be used noncommercially, for free, to do any of the following: > - RSA encryption and key generation, as defined by RSA Data > Security's Public-Key Cryptography Standards (PKCS) [4] > - MD2 and MD5 message digests [3,5,6] > - DES (Data Encryption Standard) in cipher-block chaining mode > [7,8] > Moreover, I believe you'll find that RSADSI has become much more helpful > recently. For more information, anonymous ftp to rsa.com and look around. > > I've just gone over the RSAREF license agreement again. It seems to permit > any sort of not-for-profit operation, including a public key service. Uhh, this is not quite true. If you read closer, you will see that you need "special permission from RSADSI" to use non-published interfaces to RSAREF. At the end is an exerpt from the RSAREF documentation about its interface. If you want more functionality, you have to ask special permission! This means that without this permission, you CANNOT use "RSA encryption" in-and-of itself. -derek ---------- begin exerpt -------------- RSAREF is written entirely in C. Its application interface includes the following routines: R_SignPEMBlock computes a digital signature on a message R_VerifyPEMSignature verifies a digital signature on a message R_VerifyBlockSignature verifies a digital signature on a block of data such as a certificate R_SealPEMBlock computes a digital signature and encrypts a message R_OpenPEMBlock decrypts an encrypted message and verifies a digital signature R_DigestBlock computes a message digest on a message R_GeneratePEMKeys generates an RSA public/private key pair R_RandomInit initializes a random structure R_RandomUpdate mixes bytes into a random structure R_GetRandomBytesNeeded computes the number of mix-in bytes still needed to seed a random structure R_RandomFinal zeroizes a random structure From tribble at xanadu.com Fri Jan 15 11:35:19 1993 From: tribble at xanadu.com (E. Dean Tribble) Date: Fri, 15 Jan 93 11:35:19 PST Subject: random remailers Message-ID: <9301151822.AA13343@xanadu.xanadu.com> Has anyone thought about the consequence of randomly picking a remailing path instead of using the same one? It occurred to me yesterday that randomly picked paths could reveal more information to the remailer sites so that they could figure out the connection between a pseudonym and the eventual destination pretty well. It's just an intuition at this point, though. dean From uri at watson.ibm.com Fri Jan 15 12:19:29 1993 From: uri at watson.ibm.com (uri at watson.ibm.com) Date: Fri, 15 Jan 93 12:19:29 PST Subject: possible solution to the anonymous harrassment problem In-Reply-To: <9301151918.AA06316@toxicwaste.MEDIA.MIT.EDU> Message-ID: <9301152018.AA12839@buoy.watson.ibm.com> Derek Atkins says: > > I've just gone over the RSAREF license agreement again. It seems to permit > > any sort of not-for-profit operation, including a public key service. > Uhh, this is not quite true. If you read closer, you will see that > you need "special permission from RSADSI" to use non-published > interfaces to RSAREF. If you want more functionality, > you have to ask special permission! Well, their license says, that "they will grant permission for any reasonable request" for modification to RSAREF, or to access to those unpublished routines. I guess until somebody asks about such a permission and gets rejected, or granted - we'll never know... [BTW, I aske and got such permission for my own private needs...] Now, who's willing to volunteer? (:-) > This means that without this permission, you CANNOT use "RSA > encryption" in-and-of itself. Legally, you mean (:-). -- Regards, Uri uri at watson.ibm.com scifi!angmar!uri N2RIU ----------- From Marc.Ringuette at GS80.SP.CS.CMU.EDU Fri Jan 15 12:30:20 1993 From: Marc.Ringuette at GS80.SP.CS.CMU.EDU (Marc.Ringuette at GS80.SP.CS.CMU.EDU) Date: Fri, 15 Jan 93 12:30:20 PST Subject: possible solution to the anonymous harrassment problem Message-ID: <9301152030.AA10201@toad.com> > If you read closer, you will see that you need "special permission from > RSADSI" to use non-published interfaces to RSAREF. I thought their interface was good enough to do all of the obvious operations -- RSA block encrypt and decrypt being the most important -- and that this restriction was just to prevent bizarrelly hacked versions of their code from being confused with the original. > R_SignPEMBlock computes a digital signature on a message > R_VerifyBlockSignature verifies a digital signature on a block of > data such as a certificate Let me know if I'm wrong, but I don't think I am. -- Marc Ringuette (mnr at cs.cmu.edu) From matt at oc.com Fri Jan 15 12:40:13 1993 From: matt at oc.com (Matthew Lyle) Date: Fri, 15 Jan 93 12:40:13 PST Subject: resource for writing corp e-mail policy? Message-ID: <199301152036.AA27269@ra.oc.com> Can anybody out there point me towards some resources that could be used to write a good corporate e-mail privacy policy? -- Matthew Lyle (214) 888-0474 OpenConnect Systems matt at oc.com Dallas, TX "...and once you have tasted flight, you will walk the earth with your eyes turned skyward, for there you have been, and there you long to return..." From opac!brian%OPAC.osl.or.gov at CS.ORST.EDU Fri Jan 15 12:57:34 1993 From: opac!brian%OPAC.osl.or.gov at CS.ORST.EDU (BRIAN MCBEE) Date: Fri, 15 Jan 93 12:57:34 PST Subject: use of ripem instead of pgp Message-ID: <00966A50.87B655C0.23058@OPAC.OSL.OR.GOV> > RIPEM is Mark Riordan's public-key program. It is similar to PEM, but does > not use the PEM certificates and therefore does not require people to have > their keys signed by an agency. It is not really PEM compatible. It does > use the RSAREF public-domain encryption package, so it is legal for non- > commercial use in the U.S. and Canada. > > What I suggested was the use of RIPEM since it is available now, is legal, > and is free. > > Note, though, that whether RIPEM or PGP is used, they are only for non- > commercial use. A remailer that wanted to charge, such as the ones that > Eric Messick is discussing, would probably have to license the technology > from PKP directly to be legal. (I'm not sure whether PEM also is limited > to non-commercial use.) > > Hal Finney > 74076.1041 at compuserve.com Since the only reason we are talking about RIPEM is because of legality concerns about PGP, I thought I'd mention that it is (at least theoretically) illegal to export RIPEM from the US, annd therefore could not be legally used to correspond with persons overseas. I don't know if there is a legal way to do public key cryptography between persons inside the US and persons outside the US. ----- Brian McBee ----- (503)378-4276 ----- brian at opac.osl.or.gov ----- ----- Oregon State Library, State Library Building, Salem, OR 97310 ----- Plan globally, attack locally From uri at watson.ibm.com Fri Jan 15 13:26:42 1993 From: uri at watson.ibm.com (uri at watson.ibm.com) Date: Fri, 15 Jan 93 13:26:42 PST Subject: use of ripem instead of pgp In-Reply-To: <00966A50.87B655C0.23058@OPAC.OSL.OR.GOV> Message-ID: <9301152125.AA19820@buoy.watson.ibm.com> BRIAN MCBEE says: > Since the only reason we are talking about RIPEM is because of legality > concerns about PGP, I thought I'd mention that it is (at least theoretically) > illegal to export RIPEM from the US, annd therefore could not be legally used > to correspond with persons overseas. RSAREF isn't legally exportable - that's correct. But RIPEM certainly is. And there's nothing to prevent those overseas from using RIPEM with whatever RSA and DES implementations they wish (they have at least three good ones to choose from :-). > I don't know if there is a legal way to do public key cryptography between > persons inside the US and persons outside the US. a) If "they" teach PGP to understand PEM - we could use RIPEM here to talk to them (they will use PGP, naturally). b) If they get legal RIPEM and marry it with RSA/DES - we could talk with them using RIPEM on both ends. -- Regards, Uri uri at watson.ibm.com scifi!angmar!uri N2RIU ----------- From eab at msc.edu Fri Jan 15 13:34:11 1993 From: eab at msc.edu (Edward Bertsch) Date: Fri, 15 Jan 93 13:34:11 PST Subject: unsubscribe Message-ID: <9301152133.AA05997@wc.msc.edu> unsubscribe please From jthomas at kolanut.mitre.org Fri Jan 15 13:35:21 1993 From: jthomas at kolanut.mitre.org (Joe Thomas) Date: Fri, 15 Jan 93 13:35:21 PST Subject: use of ripem instead of pgp Message-ID: <9301152131.AA01479@kolanut> BRIAN MCBEE writes: >Since the only reason we are talking about RIPEM is because of legality >concerns about PGP, I thought I'd mention that it is (at least theoretically) >illegal to export RIPEM from the US, annd therefore could not be legally used >to correspond with persons overseas. >I don't know if there is a legal way to do public key cryptography between >persons inside the US and persons outside the US. What is illegal to export is the software implementations of strong cryptography, not messages encrypted with them, or even detailed specifications of how to implement compatible software. So, theoretically, if a group in each COCOM-complying country and a group out of the reach of COCOM each independently implemented software to do the public-key cryptography (the U.S. group is the only one that will have to worry about licensing PKP's patents), then trading encrypted mail would be unquestionably legal. It would also be a lot of wasted work and duplicated effort, and I don't see any reason to respect the laws that make exporting or importing this software illegal. RIPEM has no doubt escaped the U.S. since RSADSI put it up for anonymous FTP last week, and PGP is everywhere. Joe From Marc.Ringuette at GS80.SP.CS.CMU.EDU Fri Jan 15 13:39:48 1993 From: Marc.Ringuette at GS80.SP.CS.CMU.EDU (Marc.Ringuette at GS80.SP.CS.CMU.EDU) Date: Fri, 15 Jan 93 13:39:48 PST Subject: use of ripem instead of pgp Message-ID: <9301152139.AA11168@toad.com> Bear in mind that many countries have restrictions about shipping encrypted traffic across their borders. These restrictions will be almost impossible to enforce, true, but do exist. M. From warlord at MIT.EDU Fri Jan 15 13:41:59 1993 From: warlord at MIT.EDU (Derek Atkins) Date: Fri, 15 Jan 93 13:41:59 PST Subject: possible solution to the anonymous harrassment problem In-Reply-To: <9301152030.AA10201@toad.com> Message-ID: <9301152141.AA07098@toxicwaste.MEDIA.MIT.EDU> > I thought their interface was good enough to do all of the obvious > operations -- RSA block encrypt and decrypt being the most important -- > and that this restriction was just to prevent bizarrelly hacked > versions of their code from being confused with the original. > > > R_SignPEMBlock computes a digital signature on a message > > R_VerifyBlockSignature verifies a digital signature on a block of > > data such as a certificate > > Let me know if I'm wrong, but I don't think I am. You are wrong. The interface does *not* give you RSA Block De/Encrypt. -derek From eric at parallax.com Fri Jan 15 15:45:21 1993 From: eric at parallax.com (Eric Messick) Date: Fri, 15 Jan 93 15:45:21 PST Subject: random remailers In-Reply-To: <9301151822.AA13343@xanadu.xanadu.com> Message-ID: <9301152057.AA03932@parallax.com> I've been thinking about random remailing paths for a while now, and I must admit that I don't know if it's on the balance a positive or negative thing. My view is: give the user the option. The positive points: Traffic analysis *MAY* be more difficult. If you are receiving a large quantity of traffic, it won't all follow the same path, so it won't show up as a big spike in traffic between any two hosts. On the other hand, it will all need to converge on you anyway. You just need to hide the incoming traffic with bogus outgoing traffic. If you intend to receive a large amount of anonymous mail, it would be wise to run a popular remailer. New remailers get up to speed faster. With the remailer network handling the addition of new remailers automatically, an announcement of a new remailer could result in sufficient cover traffic quickly. If you have to wait for PEOPLE to decide to use the new remailer, it will ramp up much more slowly. On the other hand, cover traffic could be handled randomly, even with real messages always being staticly routed by people. Negative points: Your messages travel through more hosts, increasing the likelihood of having them encounter a compromised host. This is more pronounced since it is difficult to evaluate the reputations of hosts when you have only indirect control of their selection. On the other hand, we would like our systems to be immune to the compromise of even a moderately large portion of the remailers. A difficult question to be sure. That's why I advocate giving the choice to the user. -eric messick From honey at citi.umich.edu Fri Jan 15 17:18:58 1993 From: honey at citi.umich.edu (peter honeyman) Date: Fri, 15 Jan 93 17:18:58 PST Subject: random remailers In-Reply-To: <9301151822.AA13343@xanadu.xanadu.com> Message-ID: <9301160118.AA14215@toad.com> > Has anyone thought about the consequence of randomly picking a > remailing path instead of using the same one? what if the remailer flips a coin, choosing between final delivery and remailing through another of its ilk. "message delivery with probability one ..." imho, this beats source routing big time. easy to hack into the scripts, too. > It occurred to me > yesterday that randomly picked paths could reveal more information to > the remailer sites so that they could figure out the connection > between a pseudonym and the eventual destination pretty well. not sure what you mean. peter From tony at morgan.demon.co.uk Fri Jan 15 19:27:50 1993 From: tony at morgan.demon.co.uk (Tony Kidson) Date: Fri, 15 Jan 93 19:27:50 PST Subject: more on security/obscurity/reality (fwd) Message-ID: <1414@morgan.demon.co.uk> In message <9218 at eternity.demon.co.uk> you write: > Forwarded message follows: > > > From cypherpunks-request%toad.com at relay2.uu.net Fri Jan 15 12:52:47 1993 > > One thing I've really noticed over the 5 or 6 years I've been on the net > is the real hatred people have for what is coined "security by obscurity." > I think it is because of the terrible way people have gotten burned by > relying on conceiled methods only, or secret algorithms as ciphers to > protect their material. The method is discovered one way or another, and > everything caves in on itself! Quite understandable. > > Yet I cringe at the way people have just turned their backs on the whole > meta-philosophy of "coversion." If, for instance, you are to do battle with > an unbearable, overwhelming power, such as the Government, then what is the > only real way to "win?" Besides convincing them not to do battle with you? > > It is by staying conceiled, secret, untargetable. If they don't know to fight > you, or, if they do know, but cannot find you, then you stay all right. > Once it gets to a face-to-face confrontation, however, you lose, and you > lose immediately, there is nothing you can bring to bear, since it is now > just a force equation, and they have over 10,000 times the force you do. > Or more... > > This is one of the applications of the secret side of life. Modern crypto- > graphy has advanced, I think, by declaring all coversion as eventually > discoverable, and only seeking algorithms that will suffice even if the > enemy knows your methods. I agree with this. I guess I part company, however, > when people totally throw out being secretive as a partial or adjunctive > solution to something that is intrinsicly secret to begin with. The addition > of conceilment, disinformation, invisibility, etc. can be a tremendous > advantage when combined with strong methods (good ciphers that don't rely > on coversion). It is a multilayered approach that first tries to not become > a target, and, if it is a target is still hard to crack. > > When us little people try to maintain privacy against a Govt. that is REALLY > PISSED OFF BY EVEN THE IDEA WE WANT TO STRONGLY PROTECT OURSELVES, a multi- > layered, contingency-based approach is required. The most important part of > it is not a strong cipher, but, not to become a detectable or locatable > target. i.e. coversion and secrecy. While what you say is certainly true, it won't survive any kind of detailed attack. I'm all for the sentiment, but while there are so many mundane things going on round about, the best way to remain undetected is to remain undecipherable and to make sure that there is enough traffic about of the same sort. Press for encipherment of e-mail, that way, if everybody is doing it, who's to know what the underworld is doing? This is especially useful if you are not actually interested in violent revolution. You can then convince the powers that be that you are not worth monitoring. regards Tony ------------------+-------------------------------+--------------------------+ | Tony Kidson |`morgan' is an 8MB 486/33 Cat-| Voice +44 81 466 5127 | | Morgan Towers, |Warmer with a 670 MB Hard Disk.| E-Mail | | Morgan Road, |It resides at Morgan Towers in| tony at morgan.demon.co.uk | | Bromley, |Beautiful Down Town Bromley. | tny at cix.compulink.co.uk | | England BR1 3QE | -=<*>=- | 100024.301 at compuserve.com| +=================+===============================+==========================+ From banisar at washofc.cpsr.org Fri Jan 15 20:25:16 1993 From: banisar at washofc.cpsr.org (Dave Banisar) Date: Fri, 15 Jan 93 20:25:16 PST Subject: Released GSA Docs Slam FBI Wiretap Proposal Message-ID: <9301152322.AA47734@hacker2.eff.org> "GSA Memos Reveal that FBI Wiretap Plan was Opposed by Government's Top Telecomm Purchaser" The New York Times reported today on a document obtained by CPSR through the Freedom of Information Act. ("FBI's Proposal on Wiretaps Draws Criticism from G.S.A.," New York Times, January 15, 1993, p. A12) The document, an internal memo prepared by the General Services Administration, describes many problems with the FBI's wiretap plan and also shows that the GSA strongly opposed the sweeping proposal. The GSA is the largest purchaser of telecommunications equipment in the federal government. The FBI wiretap proposal, first announced in March of 1992, would have required telephone manufacturers to design all communications equipment to facilitate wire surveillance. The proposal was defeated last year. The FBI has said that it plans to reintroduce a similar proposal this year. The documents were released to Computer Professionals for Social Responsibility, a public interest organization, after CPSR submitted Freedom of Information Act requests about the FBI's wiretap plan to several federal agencies last year. The documents obtained by CPSR reveal that the GSA, which is responsible for equipment procurement for the Federal government, strongly opposed two different versions of the wiretap plan developed by the FBI. According to the GSA, the FBI proposal would complicate interoperability, increase cost, and diminish privacy and network security. The GSA also stated that the proposal could "adversely _affect national security._" In the second memo, the GSA concluded that it would be a mistake to give the Attorney General sole authority to waive provisions of the bill. The GSA's objections to the proposal were overruled by the Office of Management and Budget, a branch of the White House which oversees administrative agencies for the President. However, none of GSA's objections were disclosed to the public or made available to policy makers in Washington. Secrecy surrounds this proposal. Critical sections of a report on the FBI wiretap plan prepared by the General Accounting Office were earlier withhold after the FBI designated these sections "National Security Information." These sections included analysis by GAO on alternatives to the FBI's wiretap plan. CPSR is also pursuing a FOIA lawsuit to obtain the FBI's internal documents concerning the wiretap proposal. The GSA memos, the GAO report and others that CPSR is now seeking indicate that there are many important documents within the government which have still not been disclosed to the public. Marc Rotenberg CPSR Washington office rotenberg at washofc.cpsr.org Note: Underscores indicate underlining in the original text. Dashes that go across pages indicate page breaks. [Computer Professionals for Social Responsibility is a non- profit, public interest membership organization. For membership information about CPSR, contact cpsr at csli.stanford.edu or call 415/322-3778. For information on CPSR's FOIA work, contact David Sobel at 202/544-9240 (sobel at washofc.cpsr.org).] ------------------------------------------------------------- (#4A) Control No. X92050405 Due Date: 5/5/92 Brenda Robinson (S) After KMR consultations, we still _"cannnot support"_ Draft Bill. No. 118 as substantially revised by Justice after its purported full consideration of other agencies' "substantive concerns." Aside from the third paragraph of our 3/13/92 attachment response for the original draft bill, which was adopted as GSA's position (copy attached), Justice has failed to fully address other major GSA concerns (i.e., technological changes and associated costs). Further, by merely eliminating the FCC and any discussion of cost issues in the revision, we can not agree as contended by Justice that it now " ... takes care of kinds of problems raised by FCC and others ...." Finally, the revision gives Justice sole unilateral exclusive authority to enforce and except or waive the provisions of any resultant Iaw in Federal District Courts. Our other concerns are also shown in the current attachment for the revised draft bill. Once again OMB has not allowed sufficient time for a more through review, a comprehensive internal staffing, or a formal response. /Signature/ Wm. R. Loy KMR 5/5/92 Info: K(Peay),KD,KA,KB,KE,KG,KV,KM,KMP,KMR,R/F,LP-Rm.4002 (O/F) - 9C1h (2) (a) - File (#4A) ------------------------------------------------------------- ATTACHMENT REVISED JUSTICE DRAFT BILL DIGITAL TELEPHONY The proposed legislation could have a widespread impact on the government's ability to acquire _new_ telecommunications equipment and provide electronic communications services. _Existing_ Federal government telecommunications resources will be affected by the proposed new technology techniques and equipment. An incompatibility and interoperability of existing Federal government telecommunications system, and resources would result due to the new technological changes proposed. The Federal Communications Commission (FCC) has been removed from the legislation, but the Justice implementation may require modifications to the "Communications Act of 1934," and other FCC policies and regulations to remove inconsistencies. This could also cause an unknown effect on the wire and electronic communications systems operations, services, equipment, and regulations within the Federal government. Further, to change a major portion of the United States telecommunications infrastructure (the public switched network within eighteen months and others within three years) seems very optimistic, no matter how trivial or minimal the proposed modifications are to implement. In the proposed legislation the Attorney General has sole _unilateral exclusive_ authority to enforce, grant exceptions or waive the provisions of any resultant law and enforce it in Federal District Courts. The Attorney General would, as appropriate, only "consult" with the FCC, Department of Commerce, or Small Business Administration. The Attorney General has exclusive authority in Section 2 of the legislation; it appears the Attorney General has taken over several FCC functions and placed the FCC in a mere consulting capacity. The proposed legislation would apply to all forms of wire and electronic communications to include computer data bases, facsimile, imagery etc., as well as voice transmissions. The proposed legislation would assist eavesdropping by law enforcement, but it would also apply to users who acquire the technology capability and make it easier for criminals, terrorists, foreign intelligence (spies) and computer hackers to electronically penetrate the public network and pry into areas previously not open to snooping. This situation of easier access due to new technology changes could therefore affect _national security_. (1) ------------------------------------------------------------- The proposed legislation does not address standards and specifications for telecommunications equipment nor security considerations. These issues must be addressed as they effect both the government and private industry. There are also civil liberty implications and the public's constitutional rights to privacy which are not mentioned. it must be noted that equipment already exists that can be used to wiretap the digital communications lines and support court- authorized wiretaps, criminal investigations and probes of voice communications. The total number of interception applications authorized within the United States (Federal and State) has been averaging under nine hundred per year. There is concern that the proposed changes are not cost effective and worth the effort to revamp all the existing and new telecommunications systems. The proposed bill would have to have the FCC or another agency approve or reject new telephone equipment mainly on the basis of whether the FBI has the capability to wiretap it. The federal- approval process is normally lengthy and the United States may not be able to keep pace with foreign industries to develop new technology and install secure communications. As a matter of interest, the proposed restrictive new technology could impede the United States' ability to compete in digital telephony and participate in the international trade arena. Finally, there will be unknown associated costs to implement the proposed new technological procedures and equipment. These costs would be borne by the Federal government, consumers, and all other communications ratepayers to finance the effort. Both the Federal government and private industry communications regular phone service, data transmissions, satellite and microwave transmissions, and encrypted communications could be effected at increased costs. (2) ============================================================= Documents disclosed to Computer Professionals for Social Responsibility (CPSR), under the Freedom of Information Act December 1992 ============================================================= From mimir at u.washington.edu Fri Jan 15 23:16:32 1993 From: mimir at u.washington.edu (Al Billings) Date: Fri, 15 Jan 93 23:16:32 PST Subject: more on security/obscurity/reality In-Reply-To: <930115183334_74076.1041_DHJ45-1@CompuServe.COM> Message-ID: On 15 Jan 1993, Hal wrote: > One other point I'd make regards the use of pseudonyms for replying. > The Pax service created a pseudonym for each person who used the > service which was put into the "From:" line of outgoing mail. Then > people could reply to that pseudonym and it would go back to the > original sender. Does anyone have a copy of the software PAX used? From hibbert at xanadu.com Sat Jan 16 14:55:14 1993 From: hibbert at xanadu.com (Chris Hibbert) Date: Sat, 16 Jan 93 14:55:14 PST Subject: possible solution to the anonymous h In-Reply-To: <930115065840_74076.1041_DHJ55-1@CompuServe.COM> Message-ID: <9301162240.AA18137@entropy.xanadu.com> > A final point is that forwarding mail for another person can hardly be > made illegal in general. If I receive a message from person A asking me > to forward it on to person B, and I do so, this is clearly a legitimate > email message that I choose to send. To try to disallow this would be to > put intolerable restrictions on email content. So, if this is allowed, it > seems to me that I should be able to write a program to do what I am > allowed to do manually. I don't believe the analogy holds up. In dealing with it manually, police would expect that there's a chance that they could haul you into court and ask you for names and dates. In the manual situation, you are responsible as editor, a responsibility you're looking to get away from. The law would prefer that someone is responsible, so they may try to find a way to hold someone responsible. Chris From 74076.1041 at CompuServe.COM Sat Jan 16 17:48:21 1993 From: 74076.1041 at CompuServe.COM (Hal) Date: Sat, 16 Jan 93 17:48:21 PST Subject: Digital cash legality... Message-ID: <930117014230_74076.1041_DHJ26-1@CompuServe.COM> I've continued to try to learn about what laws might restrict the issuing of electronic money. Banking is controlled at both the state and the federal level. One question was whether one could engage in bank-like activities without calling yourself a bank. Denning's California Codes, Financial, has this definition: ------ Section 102. "Bank" The word "bank" as used in this division means any incorporated banking institution which shall have been incorporated to engage in commercial banking business or trust business. The soliciting, receiv- ing, or accepting of money or its equivalent on deposit as a regular business shall be deemed to be doing a commercial banking business whether such deposit is made subject to check or is evidenced by a certificate of deposit, a passbook, a note, a receipt, or other writing; provided, that nothing herein shall apply to or include money or its equivalent left in escrow, or left with an agent pending investment in real estate or securities for or on account of his principal. It shall be unlawful for any corporation, partnership, firm, or individual to engage in or transact a banking business within this state except by means of a corporation duly organized for such purpose. ------ This seems to say that it's illegal to do these bank-like activities unless you either are a corporation specifically chartered to be a bank (in which case the many banking laws apply to you), or unless you are an escrow agent or a real estate or securities agent (in which case many other laws apply to you). The California financial codes are three volumes long, so there is a considerable body of law that one would have to be familiar with to consider engaging in such activies. Another approach I have thought of would be to buy and sell digital cash, calling it something else. It's legal to buy and sell other bit patterns, such as computer-readable pictures and software, so it should be legal to buy and sell these cryptographic items. The idea would be that for $1.00 you will sell someone a #1.00 crypto- cash file, either through email or over the counter if you wanted (on a floppy). Then, if someone comes to you with one of these #1.00 digital cash files, you will buy it back for $1.00. At one level you are simply buying and selling items just like the local dealer in baseball cards, but at another level you are a "money changer", converting between U.S. dollars and crypto-credits. The credits thus receive backing through your willingness to redeem them for dollars at any time. One issue is how certain people can be that you actually will buy back this crypto-cash for its "face value". Given that you're not actually a bank, not actually a money dealer, and therefore not bound by any regulations, there is nothing to compel you to continue to accept the crypto money. You could arbitrarily decide at any time not to buy it back any more, just like the local baseball card dealer. This, I think, is what makes this whole activity legal - you're not making any promises to "depositers" that they can get their money back. But, by the same token, it may prevent the digicash from being accepted. It would basically come down to your reputation for being trustworthy and committed. Another problem is the issue of sales tax. Using this "seller of bit patterns" model, you will have to collect sales tax from your customers who are within the state. From my experience selling software, you don't have to collect it for out-of-state customers. I don't know whether the state would also expect another "cut" when you buy the bit patterns back. But it sounds like there will be at least a 7% transaction cost to turn dollars into digital cash, which is probably prohibitive. One solution might be to do this from a state which doesn't collect sales tax. (Coin dealers here in California have some exemptions from the sales tax requirements, but I doubt whether these exemptions could be stretched to cover what I am proposing here. In other respects, though, that business is rather similar to what I am talking about, in that they do a lot of selling and buying back.) A related issue is whether this should be thought of as a business at all, or whether it could be a hobby. The fact is, you could actually make a lot of money at this, even though you buy and sell at the same price, by investing the dollars you are paid until you have to use them to buy the digital cash back. Still, given the apparent need to infringe or license both RSA's and Chaum's patents, I think running it on a "non-commercial" basis would be more acceptable, if that could be done. I suppose if you were careful to segregate the dollars used to purchase crypto-cash into a non-interest-bearing account, so you didn't make any money on them, you could call it non- commercial. (Actually, it's not 100% clear to me that RSA's patents would apply to a digital cash implementation, since their patent is for a communications machine, even though the algorithm is the same.) I'll let people know as I continue to learn more. Hal From tcmay at netcom.com Sat Jan 16 23:45:44 1993 From: tcmay at netcom.com (Timothy C. May) Date: Sat, 16 Jan 93 23:45:44 PST Subject: Ideal Remailers In-Reply-To: <9301151822.AA13343@xanadu.xanadu.com> Message-ID: <9301170742.AA11487@netcom3.netcom.com> SOME PROPERTIES OF IDEAL REMAILERS Cypherpunks, It's been exciting seeing the work being done by so many of you on remailers! Not being either a PERL user or a UNIX box owner, I haven't had much to add to the debate these past several weeks. But on the issue of basic, primitive features of remailing networks, I want to make some points. I'll use Dean's message as a starting point. Dean Tribble writes: > Has anyone thought about the consequence of randomly picking a > remailing path instead of using the same one? It occurred to me > yesterday that randomly picked paths could reveal more information to > the remailer sites so that they could figure out the connection > between a pseudonym and the eventual destination pretty well. It's > just an intuition at this point, though. I assume Dean means that by analyzing some kind of characteristic of the message and enough of the routings, some "common factor" analysis might reveal the sender. This may be true in cases where the routing path is _visible_ (unencrypted at some or all nodes) to some or all of the remailer nodes. However, I think we all expect remailers to (eventually) have most or all of these properties: * All packets are encrypted to the public key of the remailer node: only the previous (n - 1) and next (n + 1) nodes in a remailer path are known to node n, except by collusion between remailers. * Some number of incoming messages are collected together before remailing in an order that gives no clues about the order received, e.g., lexicographic order. (I realize that at this stage of experimentation, such "accumulation" may not be practical.) * The remailer node n should "forget" the connection between incoming and outgoing paths. The Chaum "digital mix" idea, when implemented with tamper-resistant hardware, means a remailer can explicitly keep no record of the incoming and outgoing paths, making collusion at a later time (perhaps demanded by authorities) unproductive. * The tamper-resistant, fully-automated nature is very important. Running remailers on insecure boxes, or large Unix machines at corporate and university sites, is not a long-term situation! * Each originator of a piece of mail should, ideally, also operate a remailing service (at least at some low level). This will allow any message "traced back" (somehow) to a person to be "deniable"..."But I didn't write that message, I just remailed it! And, no, my remailer box doesn't keep any records." * Payment for remailing services can be done in several ways. Eventually, digital money can be used. A more immediately doable scheme may to use the equivalent of "stamps." Since "digital stamps" is confusing, call it "digtial postage." It may work as follows: -Tim's Remailing Service sells "rolls" (lists) of 50-digit numbers (large enough to make guessing unproductive) for perhaps $0.29 per number. Each number is a "promise to remail" for some typical-sized message, with more stamps needed for longer messages. - No crypto protocols are really needed. Forgery by copying is handled by simply saying that the first use of number is the only use...the buyer of numbers must keep his numbers secure (at his site, and in the remailing chain). The seller of numbers (e.g., Tim's Remailing Service) is not likely to try to cheat purchasers of stamps by denying he issued them (by standard reputation-based systems, independent auditing services, etc.). * Return envelopes can be handled by enclosing prepaid envelopes as part of the message. (No record need be kept of the path, obviously, as the return path through a web of remailers is independent of the initial path.) * It is very likely--almost certain, in fact--that various remailing services will have have various policies, prices, reputations, etc. Some will be cheap-but-not-secure, others will be secure-but-slow, and so on. As our "Crypto Game" revealed so clearly last September at our first Cypherpunks meeting, some remailer sites will be "narcs," some will sell their knowledge to others, and so on. This is to be expected, especially given that we will be operating in a nearly pure anarchocapitalist situation, with no "enforcement" by authorities...fortunately, free markets are quite efficient in correcting such problems (the topic of another essay, perhaps). But such a market will allow a user to select a remailing path, known only to him (if collusion is avoided, and if the remailers have the robust properties mentioned already). I mention these robust properties--what we can call the "ideal remailer"--because some of the existing or planned remailers do various "non-ideal" things, like keep logs of all mail, run on nonsecure machines, don't have strong encryption, and so on. These imperfect remailers are still useful, especially at this early, experimental stage. And they may exist even after more ideal remailers come into use. Of course, there "market value" is likely to be fairly low... The robust, ideal remailers are what we should be shooting for. And I think we're making amazingly fast progress. -Tim May -- .......................................................................... Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay at netcom.com | anonymous networks, digital pseudonyms, zero 408-688-5409 | knowledge, reputations, information markets, W.A.S.T.E.: Aptos, CA | black markets, collapse of governments. Higher Power: 2^756839 | PGP Public Key: by arrangement. From k.campbell14 at genie.geis.com Sun Jan 17 09:12:47 1993 From: k.campbell14 at genie.geis.com (k.campbell14 at genie.geis.com) Date: Sun, 17 Jan 93 09:12:47 PST Subject: No Subject Message-ID: <9301171714.AA14822@relay1.geis.com> i want to join the revolution. return to bablon. appreciated... From 74076.1041 at CompuServe.COM Sun Jan 17 10:53:20 1993 From: 74076.1041 at CompuServe.COM (Hal) Date: Sun, 17 Jan 93 10:53:20 PST Subject: Poor Man's Cash. Message-ID: <930117184744_74076.1041_DHJ40-1@CompuServe.COM> Tim May's message about remailers mentioned the possibility of a simple way of handling digital postage. This can be extended to be a replacement for digital cash which doesn't use any cryptography. As in Tim's suggestion, the "banker" (or "money changer" in the model I described yesterday) simply creates 50-bit numbers, each of which is a "piece of digital cash". The banker keeps a list of the specific numbers that are circulating. When someone presents one for payment, he checks to see if the number is on the list. If so, he honors it and then removes it from the list. As with regular digital cash, withdrawers keep the numeric values secret. Nobody can forge the cash because no one can create numbers which are on the banker's (secret) list. There are two problems with this system. The first is that there is no way for the seller in a seller/buyer transaction to verify that the random 50-bit numbers the buyer is offering him are actually valid pieces of digital cash. The only thing he could do is to send them to the bank and have the bank report back as to whether they are valid or not. But in at least the simpler cryptographic protocols, the same problem exists. In those protocols, it may be possible to use digital signatures to recognize that a particular piece of cash originally came from the bank, but you still have the problem that this cash may have been "spent" before. Digital cash can be reproduced trivially, so any seller must again check with the bank to make sure that the cash he is offered is still valid. (More complex schemes are intended to allow "incrimination" of a buyer who reuses cash, but I feel that they have problems as well.) So this problem is no worse than at least the simpler cryptographic schemes. The other problem is that this cash is not anonymous. When a seller sends in some cash he received from a buyer, the banker can recognize which buyer that cash came from. But there are several reasons why this might not be as bad as it seems. First, the buyer and seller may themselves be anonymous to the bank. The bank may know them only through an anonymous address of the type we have been discussing here. So, at best, the banker could deduce things like "account 1234 seems to be buying a lot from account 5678." This is not a direct loss of anonymity. Second, our own paper cash already has this problem, through the serial numbers printed on each bill. Although this is used occasionally by law enforcement to track criminals, it is not considered in general to be a threat to anonymity. And third, the banker could have a policy of not remembering which buyer received each outgoing digital cash number. This could be done by having the banker publicize the software which he is running, so that people can see that these records are not being kept, along with occasional audits by some third party to verify that the banker is actually running that software. There would still be an element of trust involved, but trust will always be a part of such relationships, and reputations will be important. This "poor man's digital cash" is not that interesting technically, because no cryptography is involved. But it does provide most of the features of crypto-cash, and it does so in a manner which is easy to understand and explain. It also violates no one's patents, so it would be that much easier to start experimenting with it safely. Hal From 74076.1041 at CompuServe.COM Sun Jan 17 10:53:24 1993 From: 74076.1041 at CompuServe.COM (Hal) Date: Sun, 17 Jan 93 10:53:24 PST Subject: Crypto trading cards. Message-ID: <930117184802_74076.1041_DHJ40-2@CompuServe.COM> Giving a little more thought to the idea of buying and selling digital cash, I thought of a way to present it. We're buying and selling "cryptographic trading cards". Fans of cryptography will love these fascinating examples of the cryptographic arts. Notice the fine way the bit patterns fit together - a mix of one-way functions and digital signatures, along with random blinding. What a perfect conversation piece to be treasured and shown to your friends and family. Plus, your friends will undoubtedly love these cryptographic trading cards just as much. They'll be eager to trade for them. Collect a whole set! They come in all kinds of varieties, from the common 1's, to the rarer 50's, all the way up to the seldom-seen 1000's. Hours of fun can be had for all. Your friendly cryptographic trading card dealer wants to join the fun, too. He'll be as interested in buying your trading cards back as in selling them. Try this fascinating and timely new hobby today! Hal From 74076.1041 at CompuServe.COM Sun Jan 17 20:48:33 1993 From: 74076.1041 at CompuServe.COM (Hal) Date: Sun, 17 Jan 93 20:48:33 PST Subject: Return envelopes. Message-ID: <930118044221_74076.1041_DHJ53-1@CompuServe.COM> I looked at Eric Messick's improved ideas for remailing with digital postage, and they look pretty good. I think it's especially good that Eric has been able to show that anonymous addresses can be used by more than one person without being incriminating. But there is still an attack which they are vulnerable to, which Eric mentions. The "Pneed" field of the anonymous address has information about the postage amounts which will be needed by each remailer in the chain. (But it doesn't reveal which specific remailers to use, of course.) It also has public keys to encrypt these amounts with, which are matched by secret keys hidden in the encrypted address. But the remailers themselves each see their corresponding postage secret keys as they process the message. This means that they know which envelope was used to send each message. That means that each remailer can find out if it is part of a given anonymous address, and it can find out what remailers are before and after it in the chain. It is especially unnerving that the last remailer in the chain can learn this information, as it will see your true address. The one consolation is that it won't _know_ that it is the last remailer in the chain, so it won't realize that it has actually broken the code and is seeing the true correspondance between the anonymous address and the real address. But if most anonymous addresses only go through no more than a handful of remailers, say 10, then that remailer must figure that it has at least a 10% chance of having "broken" your address. This degree of information is more than I would like to have revealed about my anonymous address. Based on this, I would be inclined to use non-postage-charging remailers. But even the non-postage remailers have the same flaw using Eric's protocol. Each remailer sees the "clear text" of the message M being passed along. If a remailer sent the message in the first place, it created M, so if it then sees message M come through later, it again knows the correspondance between an anonymous address and its own forwarding activities. Chaum's scheme avoided this problem by having M get encrypted at each point. Using Eric's notation, an anonymous address might be: Addr: &Z, z, z(&R, r, A, r(junk)) The new addition is A, a random conventional key. Z gets sent: To: &Z Addr: z(z(&R, r, A, r(junk)), pad) Message: z(M, pad) This is just like Eric's example. What Z sends is: To: &R Addr: r(r(junk), pad) Message: r(A(M), pad) The new feature is that Z encrypted M with A as it passed through. In this case we only had a one-step anonymous address, but if there were more than one step, each would use a different conventional key A, B, C, .... This way even a remailer which created M wouldn't recognize it when it passed through after at least one step. Using this idea along with Eric's idea of random padding and double encryption at each step, we have multiple-use return addresses for which no information can be learned at any point about the correspondence between anonymous and real addresses, as long as the return addresses use at least two hops. Hal From Rusty_H._Hodge at horizon.amgen.com Mon Jan 18 19:32:58 1993 From: Rusty_H._Hodge at horizon.amgen.com (Rusty_H._Hodge at horizon.amgen.com) Date: Mon, 18 Jan 93 19:32:58 PST Subject: possible solution to the anonymous harrassment problem Message-ID: <1993Jan14.123843.1227@horizon.amgen.com> >for example, i can send postal mail with high confidence >of anonymity, and can make anonymous phone calls (with care, >e.g., by using phone booths and moving around). What about that little old ladie that watches the PO Box and Phone Booth from her window? What about the postman who sees you place the letter in the mailbox? >privacy and honesty are orthogonal. I've often accidentially overheard things I wasn't suppost to. If people were totally honest, we wouldn't need such good encryption... From honey at citi.umich.edu Mon Jan 18 20:29:00 1993 From: honey at citi.umich.edu (peter honeyman) Date: Mon, 18 Jan 93 20:29:00 PST Subject: possible solution to the anonymous harrassment problem In-Reply-To: <1993Jan14.123843.1227@horizon.amgen.com> Message-ID: <9301190428.AA18683@toad.com> > >for example, i can send postal mail with high confidence > >of anonymity, and can make anonymous phone calls (with care, > >e.g., by using phone booths and moving around). > > What about that little old ladie that watches the PO Box and Phone Booth > from her window? What about the postman who sees you place the letter in > the mailbox? like i said, with care. just as i have to be careful that my sys admin isn't snoopy. but that's not my point. if you do exercise care, you can send anonymous mail, just like you can communicate anonymously with other media (if you are careful). remailers institutionalize anonymity, nothing more. > >privacy and honesty are orthogonal. > > I've often accidentially overheard things I wasn't suppost to. If people > were totally honest, we wouldn't need such good encryption... if your point is that dishonesty makes privacy necessary, i agree. but i do *not* agree that total honesty makes privacy unnecessary. peter From jpp at markv.com Mon Jan 18 21:47:16 1993 From: jpp at markv.com (Jay Prime Positive) Date: Mon, 18 Jan 93 21:47:16 PST Subject: Poor Man's Cash -> Poor Man's Wallet Message-ID: <9301182145.aa03856@hermix.markv.com> From: jpp at hermix To: CYPHERPUNKS at TOAD.COM In-reply-to: Hal's message of 17 Jan 93 13:47:45 EST <930117184744_74076.1041_DHJ40-1 at CompuServe.COM> Subject: Poor Man's Cash -> Poor Man's Wallet Here is a minor change which can be used with the Poor Man's Cash protocol to increase the burden on banks which wish to trace transactions. I will call it Poor Man's Wallet protocol. Rather than maintain accounts, have the bank maintain only a map from bills to values. The bank will support three kinds of transactions: Combine, Split, Validate. To check that a bill is good, I ask the bank to VALIDATE b1. It responds with v and b2. V is the value of b1, and b2 is a new bill that has the value of b1 (- bank fee). (Naturaly the new value of b1 will be 0.) Worthless bills b1 could result in either a b2 with a value of 0 (thus issueing a new 0 worth bill) or with no bill at all. To add money to my wallet, I ask the bank to COMBINE a bill b1 from somewhere else, to a bill b2 from my wallet. Both b1's and b2's value get zeroed, and a new bill b3 with value = to v(b1) + v(b2) (- bank fee) is returned to me. To break a bill down to more convinient sizes (perhaps when I wish to pay some one), I ask the bank to SPLIT a bill b1 into b2 and b3, where v(b3) = v(b1) - v(b2) (- bank fee). It may be better (as far as anonymity goes) to require the bank fees be paid with a seperate bill. It will be better to have many banks, and to have the banks each validate bills of other banks. Since in this case your anonymity is the maximum of the anonymities of the chain of banks involved. j' From ncselxsi!drzaphod at ncselxsi.netcom.com Tue Jan 19 07:32:36 1993 From: ncselxsi!drzaphod at ncselxsi.netcom.com (DrZaphod) Date: Tue, 19 Jan 93 07:32:36 PST Subject: This Honesty Thing Again Message-ID: <25637.drzaphod@ncselxsi> In Message Thu, 14 Jan 1993 12:38:43 PST, horizon.amgen.com!Rusty_H._Hodge at netcomsv.netcom.com writes: > If people were totally honest, we wouldn't need such good encryption... I think we've gone over this b4. DrZaphod [AC/DC] / [DnA][HP] [drzaphod at ncselxsi.uucp] Technicolorized From pmetzger at shearson.com Tue Jan 19 08:40:09 1993 From: pmetzger at shearson.com (Perry E. Metzger) Date: Tue, 19 Jan 93 08:40:09 PST Subject: possible solution to the anonymous harrassment problem Message-ID: <9301191535.AA05047@maggie.shearson.com> > From: Rusty_H._Hodge at horizon.amgen.com > > >for example, i can send postal mail with high confidence > >of anonymity, and can make anonymous phone calls (with care, > >e.g., by using phone booths and moving around). > > What about that little old ladie that watches the PO Box and Phone Booth > from her window? What about the postman who sees you place the letter in > the mailbox? Any postman who can distinguish your plain white envelope at a distance from the five thousand other plain white envelopes going into the mailbox likely has sufficient psychic powers that he doesn't need to watch at all. As for the compulsive payphone watchers, well, wear a disguise. Perry From Eric.Fogleman at analog.com Tue Jan 19 10:48:46 1993 From: Eric.Fogleman at analog.com (Eric Fogleman) Date: Tue, 19 Jan 93 10:48:46 PST Subject: Q: What's happening in cryptography? Message-ID: <9301191846.AA21685@ack.adstest.analog.com> I'm interested in finding out what is currently happening in cryptography. My (basement-level) knowledge of it has come from heavy mathematics-oriented texts; these books and articles make it seem as though all of the work in cryptography is done by Ph.Ds at universities. I suspect that's not the whole story... Questions: - What companies, universities are doing work in cryptography? Are there people who get paid to "do cryptography" that don't work for the NSA? If so, where do they work? - Does cryptography fall under mathematics or computer science at most universities? - Are the real developments in cryptographic algorithms coming from the universities, from companies or from cypherpunks? - Any suggestions on what to read, who to talk to, what to experiment with to move up from basement-level knowledge of cryptography? Thanks... Eric Fogleman From tcmay at netcom.com Tue Jan 19 11:36:09 1993 From: tcmay at netcom.com (Timothy C. May) Date: Tue, 19 Jan 93 11:36:09 PST Subject: Q: What's happening in cryptography? In-Reply-To: <9301191846.AA21685@ack.adstest.analog.com> Message-ID: <9301191933.AA11035@netcom3.netcom.com> Eric Fogleman writes: > I'm interested in finding out what is currently happening in > cryptography. My (basement-level) knowledge of it has come from heavy > mathematics-oriented texts; these books and articles make it seem as > though all of the work in cryptography is done by Ph.Ds at > universities. I suspect that's not the whole story... Well, you're on this list now, so you'll hear about some things that are happening. You should also read sci.crypt for miscellaneous news and chitchat about crypto technology and policy. > Questions: > > - What companies, universities are doing work in cryptography? Are > there people who get paid to "do cryptography" that don't work for the > NSA? If so, where do they work? RSA Data Security, Cylink, BBN, GE, Trusted Information Systems, M.I.T., Berkeley, Stanford, Montreal, are just a few of the many companies and universities doing crypto work. The list is really too long to go into. Many crypto functions lie outside the domain of the NSA (though not necessarily by their choice!): computer security, ATM machines and banking networks, personal indentification systems, electronic documents, locks and keys, etc. > - Does cryptography fall under mathematics or computer science at most > universities? Some of each, and sometimes under Electrical Engineering. Number theory, elliptic functions, etc., is generally in math, while complexity theory, algorithm analysis, etc. is generally under CS. > - Are the real developments in cryptographic algorithms coming from the > universities, from companies or from cypherpunks? Again, a mixture. "Cypherpunks" cannot claim, yet, to have had any breakthroughs. Perhaps someday. > - Any suggestions on what to read, who to talk to, what to experiment > with to move up from basement-level knowledge of cryptography? 1. This list and its FAQ (coming soon). 2. sci.crypt 3. The several articles on crypto that have appeared in IEEE Spectrum, Communications of the ACM, Scientific American, and so on. Use your library's resources to find them. 4. More than a dozen good crypto books exist. One recent one, "Contemporary Cryptology," edited by Gus Simmons, has good review articles in many of the new areas. Good luck. -Tim May -- .......................................................................... Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay at netcom.com | anonymous networks, digital pseudonyms, zero 408-688-5409 | knowledge, reputations, information markets, W.A.S.T.E.: Aptos, CA | black markets, collapse of governments. Higher Power: 2^756839 | PGP Public Key: by arrangement. From root at tnl.com Tue Jan 19 16:34:37 1993 From: root at tnl.com (Daniel Ray) Date: Tue, 19 Jan 93 16:34:37 PST Subject: no to DES Message-ID: <9301190748.AA07434@tnl.com> Maybe the general swing of some of you is to go with the "safer" RIPEM since it is less legally contested... But I won't trust it til it uses IDEA or triple DES or something much sounder than a 56 bit cipher. It is just too likely that this is readable by our big brother Nat Samuel Adams. dan From root at tnl.com Tue Jan 19 16:34:46 1993 From: root at tnl.com (Daniel Ray) Date: Tue, 19 Jan 93 16:34:46 PST Subject: random remailers Message-ID: <9301190827.AA08003@tnl.com> >... >A difficult question to be sure. That's why I advocate giving the >choice to the user. > >-eric messick > DEFINATELY! Have a good, redundant system in place. Then let the chips--the users--and the usage--fall where it may... This makes things far more complex than any singularly organized method. dan From root at tnl.com Tue Jan 19 16:35:51 1993 From: root at tnl.com (Daniel Ray) Date: Tue, 19 Jan 93 16:35:51 PST Subject: need for more anon remailer sites Message-ID: <9301190731.AA07288@tnl.com> > >I suggest using a dictionary to come up with "names" of anonymous users: > >aback >abacus >abalone >abandon >abase >abash >abate >abater >abbas >... > >You could pick them in random order, or sequentially. > > ... > John Gilmore > certainly dictionary words are good, randomly, not in sequential order. But also usernames such as cs135 and anything else. The point is not to form any pattern distinguishable from the actual distribution of usernames in the real world. So some would even look like univ. course accounts, even with a couple "anon"-looking usernames thrown in! an analysis of actual usernames should be in order for this, and the actual types and probabilities.... in other words, take this situation full throttle! and of course, we need not give up our legal rights to use email. but we must, IN ADVANCE, be prepared and be already fully set for anything! dan From root at tnl.com Tue Jan 19 16:36:16 1993 From: root at tnl.com (Daniel Ray) Date: Tue, 19 Jan 93 16:36:16 PST Subject: more on security/obscurity/reality Message-ID: <9301190839.AA08188@tnl.com> > >While what you say is certainly true, it won't survive any kind >of detailed attack. I'm all for the sentiment, but while there >are so many mundane things going on round about, the best way to >remain undetected is to remain undecipherable and to make sure >that there is enough traffic about of the same sort. Press for >encipherment of e-mail, that way, if everybody is doing it, who's >to know what the underworld is doing? This is especially useful >if you are not actually interested in violent revolution. You can >then convince the powers that be that you are not worth >monitoring. > >regards > >Tony this is dead on true. the whole problem of all this is our "transition period" until encryption is matter-of-course. and the possibility that serious opposition will actually arise to delay that day even further. once everyone does it, most of (but not all of) the special contingencies are unnecessary. what I am trying to address is how things are now, and how they may change one way, or another. and to find the best multi-solution for most of these possibilities....until that happy day you speak of. dan From deltorto at aol.com Tue Jan 19 19:32:35 1993 From: deltorto at aol.com (deltorto at aol.com) Date: Tue, 19 Jan 93 19:32:35 PST Subject: Who Me? Paranoid? Naaaah... Message-ID: <9301192229.tn56425@aol.com> Hmmmm... I'm beginning to wonder if we shouldn't someday be able to run public email in a sort of "parallel universe," an entirely separate mail system complete with built-in RSA encryption on every piece of mail. That way, we would no longer rely on the Internet, which, unless I am completely off the mark, basically still exists at the pleasure of ARPA and could be completely infiltrated and controlled by the NSA for all we know. Along similar lines, has anyone heard the latest status on the gigabytes of email generated by the Bush White House which are currently in danger of being erased before anyone can get a peek at them? Imagine the damning evidence that exists in those documents! I had heard something about a voluntary freeze on the erasure until the matter can be decided in some Federal Court, but that strikes me like suing your local City Government in Municipal Court after being hit by a Municipal Bus - Bush's cronies will probably invoke some executive priviledge and weasel off with 'em. I wonder if such stuff will ever be released under the Freedom of Information Act (probably not in our lifetimes, but just the threat would make me happy)? Hey, a guy can _dream_ can't he? dave From shipley at tfs.COM Tue Jan 19 20:57:02 1993 From: shipley at tfs.COM (shipley at tfs.COM) Date: Tue, 19 Jan 93 20:57:02 PST Subject: Who Me? Paranoid? Naaaah... In-Reply-To: <9301192229.tn56425@aol.com> Message-ID: <9301200455.AA17238@edev0.TFS> >Hmmmm... > >I'm beginning to wonder if we shouldn't someday be able to run public email >in a sort of "parallel universe," an entirely separate mail system complete >with built-in RSA encryption on every piece of mail. That way, we would no >longer rely on the Internet, which, unless I am completely off the mark, >basically still exists at the pleasure of ARPA and could be completely >infiltrated and controlled by the NSA for all we know. Personaly (mostly before pgp) I used to set up direct uucp connections to people I *had* have secure email with (I once had some sensitive email intercepted thus causing *much* trouble for me). Since alot of my friends have unix boxes (Sun/SCO/386bsd/etc...) uucp is alot easer. -Pete PS: If anyone wants a uucp connection send me email PPS: once I get my sendmail.cf cleaned up I can add people to my domain and I will set up a remailer. From marc at Athena.MIT.EDU Tue Jan 19 21:29:07 1993 From: marc at Athena.MIT.EDU (Marc Horowitz) Date: Tue, 19 Jan 93 21:29:07 PST Subject: Who Me? Paranoid? Naaaah... In-Reply-To: <9301192229.tn56425@aol.com> Message-ID: <9301200528.AA23701@portnoy.MIT.EDU> >> That way, we would no longer rely on the Internet, which, unless I am >> completely off the mark, basically still exists at the pleasure of >> ARPA and could be completely infiltrated and controlled by the NSA for >> all we know. You are completely off the mark. Much of the Internet is privately owned and controlled, and most of what is government controlled (including the backbone) is controlled by the NSF, not DARPA. What is military controlled is essentially an island. None of our packets traverse that part of the net. (Of course, the NSA could still be watching our packets, and there is much speculation that they actively do so on international links. But the domestic links are not owned by the DoD directly.) And what parallel universe would you use. The Telcos? The FBI wiretap proposal should show you how good an idea that is. Unless you want to run your own physically secure wire (intractable), you need encryption, so you might as well use the Internet. Even if it is NSA-controlled, which I doubt. Marc From 74076.1041 at CompuServe.COM Wed Jan 20 00:04:41 1993 From: 74076.1041 at CompuServe.COM (Hal) Date: Wed, 20 Jan 93 00:04:41 PST Subject: Digital cash legality... Message-ID: <930120075819_74076.1041_DHJ46-2@CompuServe.COM> Continuing my research on the legality of digital cash... I found something interesting. As I posted before, one of the obstacles to free printing of private bank notes is a 10% per year tax on the circulation of bank notes from state-chartered banks. This law took effect on July 1, 1866. According to "Monetary Decisions of the Supreme Court", by Dunne, "The tax has become a permanent fixture in federal law. Its latest form is sections 4881-4886 of the Internal Revenue Code of 1954." That book is a little old, so I went tonight to look up these sections of the 1992 IRC. They don't exist. There is a note saying: "Prior sections 4881 to 4886, Act Aug. 16, 1954, c. 736, 68A Stat. 587-589, imposed a tax on the circulation of banks. "Repeal effective on the first day of the first month which begins more than 90 days after Oct. 4, 1976." So, it appears that these provisions have been repealed! It's possible that the same requirement has been re-enacted in some other form, but I looked around a bit in the index and contents and although there are many unusual taxes I could not find anything similar to this. ----- I also got an email suggestion to look up the codes related to barter exchanges. It does appear that many of these suggestions for digital cash could be construed to be covered by such laws. Here is an excerpt from the Code of Federal Regulations, 1.6045-1(f5): "(i) A credit is an amount on the books of the barter exchange that is transferable from one member or client of the barter exchange to another such member or client, or to the barter exchange, in payment for property or services; "(ii) Scrip is a token issued by the barter exchange that is transferable from one member or client of the barter exchange to another such member or client, or to the barter exchange, in payment for property or services; and "(iii) Property does not include a credit or scrip." The "credit" provision seems to cover "digital checking accounts", and the "scrip" definition seems to cover digital cash. A barter exchange itself is defined in 1.6045-1(a): "(4) The term 'barter exchange' means any person with members or clients that contract either with each other or with such person to trade or barter property or services either directly or through such person. The term does not include arrangements that provide solely for the informal exchange of similar services on a noncommercial basis." Even though the crypto banker/money-changer may not be trading property or services (just exchanging scrip for dollars), the larger system composed of the banker and the users of digital cash (who presumably are buying and selling property and services from each other using the cash/scrip) seems to match this definition pretty closely. I noticed the exception for noncommercial use, but the only example they give is for people in a carpool, who exchange the service of driving each other to work. It's not clear whether a digital cash money exchange, even if not operated for profit, would qualify. If you are a barter exchange, and there are more than 100 transactions occuring per year, you have to keep the taxpayer ID number of all the customers on file, and send them all a form 1099 describing their transactions and the market value of the transfers, as well sending information directly to the IRS. This doesn't sound like it will lead to much anonymity, crypto or otherwise. Hal 74076.1041 at compuserve.com From nobody at pmantis.berkeley.edu Wed Jan 20 00:13:14 1993 From: nobody at pmantis.berkeley.edu (nobody at pmantis.berkeley.edu) Date: Wed, 20 Jan 93 00:13:14 PST Subject: ILF Brings You Gilmore in Sci Am Message-ID: <9301200813.AA13985@pmantis.berkeley.edu> The Information Liberation Front brings you this article from the February, 1993 "Scientific American." Electronic Envelopes? The uncertainty of keeping e-mail private Recent legislative efforts to mandate remote wiretapping attachments for every telephone system and computer network in the U.S. may have been the best thing that ever happened for encryption software. "We have mostly the FBI to thank," says John Gilmore of Cygnus Support in Palo Alto, Calif. Gilmore is an entrepreneur, hacker and electronic civil libertarian who helped to found the Electronic Frontier Foundation (EFF). He is now watching closely the development of two competing techniques for keeping electronic mail private. As matters now stand, computers transmit messages from one user to another in plain text. If a geneticist m Boston sends e-mail to a molecular biologist in San Diego, any of the half a dozen or so intermediary machines that forward the letter could siphon off a copy- -and so could any of the dozens of workstations that might be attached to the local-area network at the sender's or recipient's university or company. The Electronic Privacy Act of 1986 prohibits snooping by public e- mail carriers or law-enforcement officials, except by court order. Nevertheless, many people are becoming uncomfortable with the electronic equivalent of mailing all their correspondence on postcards and relying on people to refrain from reading it. They are turning to public-key encryption, which allows anyone to encode a message but only the recipient to decode it. Each user has a public key, which is made widely available, and a closely guarded secret key. Messages encrypted with one key can be decrypted only with the other, thus also making it possible to "sign" messages by encrypting them with the private key [see "Achieving Electronic Privacy," by David Chaum; SCIENTIFIC AMERICAN, August 1992]. Two programs--and two almost diametrically opposed viewpoints embodied in them--are competing for acceptance. Privacy Enhanced Mail (PEM) is the long-awaited culmination of years of international standard setting by computer scientists. Pretty Good Privacy (PGP) is a possibly illegal work of "guerrilla freeware" originally written by software consultant Philip Zimmermann. The philosophies of PEM and PGP differ most visibly with respect to. key management, the crucial task of ensuring that the public keys that encode messages actually belong to the intended recipient rather than a malevolent third party. PEM relies on a rigid hierarchy of trusted companies, universities and other institutions to certify public keys, which are then stored on a "key server" accessible over the Internet. To send private mail, one asks the key server for the public key of the addressee, which has been signed by the appropriate certification authorities. PGP, in contrast, operates on what Zimmermann calls "a web of trust": people who wish to correspond privately can exchange keys directly or through trusted intermediaries. The intermediaries sign the keys that they pass on, thus certifying their authenticity. PGP's decentralized approach has gained a wide following since its initial release in June 1991, according to Hugh E. Miller of Loyola University in Chicago, who maintains an electronic mailing list for discussion among PGP users. His personal "keyring" file contains public keys for about 100 correspondents, and others have keyrings containing far more. As of the end of 1992, meanwhile, a final version of PEM had not been officially released. Gilmore, who subscribes to the electronic mailing list for PEM developers, says he has seen "only five or 10" messages actually encrypted using the software. Although PGP's purchase price is right--it is freely available over the Internet and on electronic bulletin boards throughout the world--it does carry two liabilities that could frighten away potential users. First, U.S. law defines cryptographic hardware and software as "munitions." So anyone who is caught making a copy of the program could run afoul of export-control laws. Miller calls this situation "absurd," citing the availability of high-quality cryptographic software on the streets of Moscow. Worse yet, RSA Data Security in Redwood City, Calif., holds rights to a U.S. patent on the public-key encryption algorithm, and D. James Bidzos, the company's president, asserts that anyone using or distributing PGP could be sued for infringement. The company has licensed public-key software to corporations and sells its own encrypted-mail package (the algorithm was developed with federal support, and so the government has a royalty-free license). When Bidzos's attorneys warned Zimmermann that he faced a suit for developing PGP, he gave up further work on the program. Instead PGP's ongoing improvements are in the hands of an international team of software developers who take advice from Zimmermann by e-mail. The U.S. is the only nation that permits the patenting of mathematical algorithms, and so programmers in the Netherlands or New Zealand apparently have little to fear. U.S. residents who import the program could still face legal action, although repeated warnings broadcast in cryptography discussion groups on computer networks have yet to be superseded by legal filings. Meanwhile, Gilmore says, the only substantive effect of the patent threat is that development and use of cryptographic tools have been driven out of the U.S. into less restrictive countries. --Paul Wallich -- From norm at xanadu.com Wed Jan 20 17:56:08 1993 From: norm at xanadu.com (Norm Hardy) Date: Wed, 20 Jan 93 17:56:08 PST Subject: Communications Policy Message-ID: <9301210133.AA08802@xanadu.xanadu.com> I hear concern over privacy and also over erasure of White House tapes. I pose the following question: Should an institution have the right to private communication? Is the White House an institution? Notice that I say "should" not "does". Which sort of world would you rather live in. I have mixed feelings. If we say that all computer communications should be accessible to courts then the effect will be to displace some communications from computers. From tcmay at netcom.com Thu Jan 21 00:33:49 1993 From: tcmay at netcom.com (Timothy C. May) Date: Thu, 21 Jan 93 00:33:49 PST Subject: Communications Policy In-Reply-To: <9301210133.AA08802@xanadu.xanadu.com> Message-ID: <9301210830.AA21995@netcom3.netcom.com> Norm Hardy raises an important issue: > I hear concern over privacy and also over erasure of White House tapes. > I pose the following question: Should an institution have the right > to private communication? Is the White House an institution? > Notice that I say "should" not "does". > Which sort of world would you rather live in. I have mixed feelings. > If we say that all computer communications should be accessible to courts > then the effect will be to displace some communications from computers. Individuals, corporations, clubs, and perhaps even government agencies should have the right to secure and private communications. The only caveat with the "perhaps" for the government is that it, in theory, belongs to "us." I find it unsettling when people of one political party are screaming for access to the private diaries and papers of members of the other party. Citing Ollie North's crimes is no excuse. If e-mail records are automatically seized and subject to archiving and dissection, then e-mail just won't be used. Historians are already becoming apoplectic at the vanishing of written records, letters, notes, and the like...this may reduce even electronic records. Strong crypto means even Ollie North can fully protect his records. (Of course, he presumably already had access to reasonably strong crypto, had he chosen to use it. And his e-mail was uncovered through the very common method of finding the archived copies of IBM's "PROFS" e-mail system kept by sysadmins. Sort of like the archives being kept by some of the so-called anonymous remailers!) -Tim May -- .......................................................................... Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay at netcom.com | anonymous networks, digital pseudonyms, zero 408-688-5409 | knowledge, reputations, information markets, W.A.S.T.E.: Aptos, CA | black markets, collapse of governments. Higher Power: 2^756839 | PGP Public Key: by arrangement. From julf at penet.FI Thu Jan 21 01:47:25 1993 From: julf at penet.FI (Johan Helsingius) Date: Thu, 21 Jan 93 01:47:25 PST Subject: Communications Policy In-Reply-To: <9301210830.AA21995@netcom3.netcom.com> Message-ID: <9301211119.aa20785@penet.penet.FI> Tim May writes: > crypto, had he chosen to use it. And his e-mail was uncovered through > the very common method of finding the archived copies of IBM's "PROFS" > e-mail system kept by sysadmins. Sort of like the archives being kept > by some of the so-called anonymous remailers!) Hmmmm.... I find the accusation about anonymous remailers pretty strong. If you have proof of stuff like that happening, or even reasonable cause for suspicions, I feel the accusations and names of the sites should be published as widely as possible. That is the only way we can stop such unethical behavior. Julf (an0 at anon.penet.fi) Johan Helsingius Kuusikallionkuja 3 B 25 02210 Espoo Finland Yourp net: julf at penet.fi bellophone: int. +358 0400 2605 fax: int. +358 013900166 From david.brooks at cutting.hou.tx.us Thu Jan 21 04:04:28 1993 From: david.brooks at cutting.hou.tx.us (David Brooks) Date: Thu, 21 Jan 93 04:04:28 PST Subject: PGP on BBS Message-ID: <10417.143.uupcb@cutting.hou.tx.us> I have been mulling over the idea of a BBS door which allows users to send PGP encrypted messages to other users using a system pubkey file. The implimentation seems easy enough except for the problem of the secret key. I don't see a way to do it without the sender having to transfer (at least temporarily) his secret key to the host system. Obviously no one in his right mind would ever consider doing such a thing. Has this kind of a program been tried before? If so, how? If not, does anyone have any ideas? Seems to me it would be a handy door for a BBS to have, but not at the expense of compromised privacy... David david.brooks at cutting.hou.tx.us * Q-Blue v0.7 [NR] * ---- +---------------------------------------------------------------------+ | The Cutting Edge BBS (cutting.hou.tx.us) A PCBoard 14.5a system | | Houston, Texas, USA +1 713 466 1525 running uuPCB | +---------------------------------------------------------------------+ From Eric.Fogleman at analog.com Thu Jan 21 05:57:24 1993 From: Eric.Fogleman at analog.com (Eric Fogleman) Date: Thu, 21 Jan 93 05:57:24 PST Subject: Communications Policy Message-ID: <9301211355.AA27670@ack.adstest.analog.com> Responding to the following from Norm Hardy: > I hear concern over privacy and also over erasure of White House tapes. > I pose the following question: Should an institution have the right > to private communication? Is the White House an institution? > Notice that I say "should" not "does". > Which sort of world would you rather live in. I have mixed feelings. > If we say that all computer communications should be accessible to courts > then the effect will be to displace some communications from computers. Institutions -- individuals, groups of individuals, companies -- should have the right to private communication. (In terms of e-mail, this means that one knows where all copies of their letters are and has the power to erase them?) The right of government employees to private communication is limited by one important factor: many of these individuals are empowered to use force against citizens, and they responsibile for justifying the use of this force. (Examples of what I mean by force: arresting and putting people in jail, searching, seizing, impounding, levying taxes, wiretapping, shooting alleged criminals). Anyone given this kind of power has a heavy burden of proof and had better be able to prove beyond a shadow of doubt that their actions are justified. The burden should not be on individuals to constantly be open to scrutiny to demonstrate their innocence, but on those with the power to suspend individual rights. =================================================================== Eric Fogleman eric.fogleman at analog.com Analog Devices Semiconductor Voice: (617) 937-2275 804 Woburn Street Fax: (617) 937-2024 Wilmington, MA 01887-3462 =================================================================== From barrus at tree.egr.uh.edu Thu Jan 21 06:15:39 1993 From: barrus at tree.egr.uh.edu (Karl L. Barrus) Date: Thu, 21 Jan 93 06:15:39 PST Subject: PGP on BBS In-Reply-To: <10417.143.uupcb@cutting.hou.tx.us> Message-ID: <9301211414.AA02759@tree.egr.uh.edu> David Brooks writes: > I have been mulling over the idea of a BBS door which allows users to >send PGP encrypted messages to other users using a system pubkey file. The >I don't see a way to do it without the sender having to transfer (at least >temporarily) his secret key to the host system. Obviously no one in his Well, you could always allow the users to download the public key file and do the encryption on their home machine, and then upload the mail file. That way their secret key stays off the BBS... /-----------------------------------\ | Karl L. Barrus | | barrus at tree.egr.uh.edu (NeXTMail) | | elee9sf at menudo.uh.edu | \-----------------------------------/ From hughes at soda.berkeley.edu Thu Jan 21 08:14:31 1993 From: hughes at soda.berkeley.edu (Eric Hughes) Date: Thu, 21 Jan 93 08:14:31 PST Subject: PGP on BBS In-Reply-To: <10417.143.uupcb@cutting.hou.tx.us> Message-ID: <9301211612.AA01687@soda.berkeley.edu> The scenario David Brooks outlines is extremely common: one host computer providing information services to another computer which acts as a terminal. This may be a BBS, Compuserve, Lexis, or any number of other services. If there exists an implementable mechanism which does not require trust of the host, then it should be implemented. In the case of cryptography, this means that secret information should not be transmitted to the host. Hence all operations which use secret information must be performed on the terminal computer. These operations include session key generation and signing of messages. The solution is cooperative processing systems, where both the host and the terminal cooperate to perform some task. Unfortunately, there is precious little software infrastructure to support such a development. Terminal programs on PC's are still for the most part acting as dumb terminals, with the notable exception of file transfer protocols such as zmodem. I believe that cooperative communication software will be necessary for widespread use of cryptography--not just pleasant, but a precondition to large scale deployment. Although this topic is not directly related to cryptology, it is certainly appropriate for discussion on this list. It is the cypherpunk goal for widespread use of crypto by the masses, and the exact nature of the infrastructure necessary for that task should be debated, then implemented, then deployed. Onward. Eric From hughes at soda.berkeley.edu Thu Jan 21 08:38:55 1993 From: hughes at soda.berkeley.edu (Eric Hughes) Date: Thu, 21 Jan 93 08:38:55 PST Subject: random remailers In-Reply-To: <9301160118.AA14215@toad.com> Message-ID: <9301211636.AA02255@soda.berkeley.edu> >> Has anyone thought about the consequence of randomly picking a >> remailing path instead of using the same one? >what if the remailer flips a coin, choosing between final delivery >and remailing through another of its ilk. "message delivery with >probability one ..." This is an excellent suggestion. I have to think about the mathematical properties some more, but a few spring to mind. Assume, for discussion, that there is constant probability of delivery at each hop, say p. First, the expected number of hops is 1/p. To see this just sum the following series. $ E(p) = \Sum_{n=1}^{\infinity} n p (p-1)^{n-1} $ Thus the syntax for routing can be extremely simple, just specifying the expected number of hops wanted. If you want to have guaranteed minimum delivery, you can manually route through a few hops, then randomize. Eric From hughes at soda.berkeley.edu Thu Jan 21 08:44:20 1993 From: hughes at soda.berkeley.edu (Eric Hughes) Date: Thu, 21 Jan 93 08:44:20 PST Subject: possible solution to the anonymous harrassment problem In-Reply-To: <9301151918.AA06316@toxicwaste.MEDIA.MIT.EDU> Message-ID: <9301211642.AA02369@soda.berkeley.edu> >If you read closer, you will see that >you need "special permission from RSADSI" to use non-published >interfaces to RSAREF. I asked Jim Bidzos about this last Friday. He states that the purpose of this clause is to avoid the situation where modifications to the package decrease its cryptographic security. I gather that such special permission should not be too hard to get. Eric From hughes at soda.berkeley.edu Thu Jan 21 08:48:34 1993 From: hughes at soda.berkeley.edu (Eric Hughes) Date: Thu, 21 Jan 93 08:48:34 PST Subject: RIPEM vs PEM In-Reply-To: <930115175946_74076.1041_DHJ57-1@CompuServe.COM> Message-ID: <9301211646.AA02423@soda.berkeley.edu> Hal writes: >A remailer that wanted to charge, such as the ones that >Eric Messick is discussing, would probably have to license the technology >from PKP directly to be legal. A note on licensing: PKP is the holder of the patents. The Partners are RSA Data Security, Cylink, MIT, and Stanford. PKP has a staff of two. RSADSI is also entitled to license the technology. Most people go through them. IBM dealt with PKP directly, evidently. Eric From hughes at soda.berkeley.edu Thu Jan 21 08:52:29 1993 From: hughes at soda.berkeley.edu (Eric Hughes) Date: Thu, 21 Jan 93 08:52:29 PST Subject: possible solution to the anonymous h In-Reply-To: <9301150739.AA02931@deathtongue.MIT.EDU> Message-ID: <9301211650.AA02533@soda.berkeley.edu> >I thought about this. The major problem is that once the PEM >beta-testing period ends, all keys must be registered with "approved" >(by RSA) central authorities. I highly doubt they'd issue >pseudonymous keys, but maybe they would allow someone to set up a >heirarchy especially for that purpose. I'm not convinced. I found out last Friday at the RSA conference that RSADSI itself is going to issue "persona" (i.e. no attempt to find out who it really is) certificates for free. That's right. No charge. Eric From tcmay at netcom.com Thu Jan 21 09:19:04 1993 From: tcmay at netcom.com (Timothy C. May) Date: Thu, 21 Jan 93 09:19:04 PST Subject: Communications Policy In-Reply-To: <9301211119.aa20785@penet.penet.FI> Message-ID: <9301211716.AA27162@netcom3.netcom.com> Johan Helsingius writes: > Tim May writes: > > > crypto, had he chosen to use it. And his e-mail was uncovered through > > the very common method of finding the archived copies of IBM's "PROFS" > > e-mail system kept by sysadmins. Sort of like the archives being kept > > by some of the so-called anonymous remailers!) > > Hmmmm.... I find the accusation about anonymous remailers pretty strong. > If you have proof of stuff like that happening, or even reasonable cause > for suspicions, I feel the accusations and names of the sites should be > published as widely as possible. That is the only way we can stop > such unethical behavior. > > Julf (an0 at anon.penet.fi) This was well-debated about a month or so back. Some remailers are archiving mail for debugging, others for legal protection (in case threats, blackmail, etc., used), and others are simply automatically archiving by site policies. In a note I wrote back then, which did not name the particular site involved, I reported that after sending a piece of "anonymous" mail, I got a letter of "support" for my position from the remailer operator! After I mentioned this to the Cypherpunks list, it came out that other sites were also keeping various forms of archives (for some or all of the reasons listed above). Anyway, such human-operated remailers, running on UNIX boxes in unsecure conditions, have many nonideal characteristics. -Tim -- .......................................................................... Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay at netcom.com | anonymous networks, digital pseudonyms, zero 408-688-5409 | knowledge, reputations, information markets, W.A.S.T.E.: Aptos, CA | black markets, collapse of governments. Higher Power: 2^756839 | PGP Public Key: by arrangement. From tribble at xanadu.com Thu Jan 21 09:21:13 1993 From: tribble at xanadu.com (E. Dean Tribble) Date: Thu, 21 Jan 93 09:21:13 PST Subject: Communications Policy In-Reply-To: <9301211119.aa20785@penet.penet.FI> Message-ID: <9301211642.AA10997@xanadu.xanadu.com> Date: Thu, 21 Jan 93 11:38:45 +0200 From: Johan Helsingius > by some of the so-called anonymous remailers!) Hmmmm.... I find the accusation about anonymous remailers pretty strong. If you have proof of stuff like that happening, or even reasonable cause for suspicions, I feel the accusations and names of the sites should be published as widely as possible. That is the only way we can stop such unethical behavior. The service of anonymous remailing is separate from the the guaranteed anonymity of a remailers that don't keep logs. You'll note that the remailing aspects can be observed externally, whereas guaranteeing that logs are not being kept is extremely hard. One remailer operator I know keeps logs because you have to assume that everyone keeps logs, and try to be secure anyway. You can be sure that the NSA remailers will keep logs :-) The right thing to do is run a remailer of your own, and send everything encrypted through remailers, etc. dean From tribble at xanadu.com Thu Jan 21 09:56:24 1993 From: tribble at xanadu.com (E. Dean Tribble) Date: Thu, 21 Jan 93 09:56:24 PST Subject: PGP on BBS In-Reply-To: <9301211612.AA01687@soda.berkeley.edu> Message-ID: <9301211702.AA11275@xanadu.xanadu.com> The solution is cooperative processing systems, where both the host and the terminal cooperate to perform some task. Unfortunately, there is precious little software infrastructure to support such a development. Terminal programs on PC's are still for the most part acting as dumb terminals, with the notable exception of file transfer protocols such as zmodem. What would the two systems be cooperating about? I'm not sure to what you are pointing. Although this topic is not directly related to cryptology, it is certainly appropriate for discussion on this list. It is the cypherpunk goal for widespread use of crypto by the masses, and the exact nature of the infrastructure necessary for that task should be debated, then implemented, then deployed. I of course map these suggestions into Joule (the language I'm developing). Does that resemble what you're thinking of? dean From tcmay at netcom.com Thu Jan 21 09:58:24 1993 From: tcmay at netcom.com (Timothy C. May) Date: Thu, 21 Jan 93 09:58:24 PST Subject: Communications Policy (fwd) Message-ID: <9301211755.AA27771@netcom3.netcom.com> After sending the attached message to Johan Helsingius, I decided it might be of general interest to the Cypherpunks list. It's a message I sent out in December, originally, and which got debated. Johan's concern about my "accusations" suggests there may be enought newcomers to the list to justify republication of posts. --Tim From: tcmay (Timothy C. May) Subject: Re: Communications Policy To: julf at penet.FI (Johan Helsingius) Date: Thu, 21 Jan 93 9:49:00 PST > > e-mail system kept by sysadmins. Sort of like the archives being kept > > by some of the so-called anonymous remailers!) > > Hmmmm.... I find the accusation about anonymous remailers pretty strong. > If you have proof of stuff like that happening, or even reasonable cause > for suspicions, I feel the accusations and names of the sites should be > published as widely as possible. That is the only way we can stop > such unethical behavior. Johan, Attached below is the message I sent to the Cypherpunks list in December, about remailers keeping logs. As I said in my message today to the list, there was a debate about this, and an admission by several remailers that they keep archives. From: tcmay at netcom.com (Timothy C. May) Message-Id: <9212140649.AA12228 at netcom.netcom.com> Subject: A minor experimental result To: cypherpunks at toad.com Date: Sun, 13 Dec 92 22:49:45 PST One of the purposes of setting up remailers is to experiment with them, see what kind of emergent behavior appears, see what kind of flaws and obstacles arise, see how they break, etc. Here's one: the compromise of my "anonymity" by one of the folks running a remailer. (Who and where don't matter, just the phenomenon itself.) I used a single bounce without any encryption to send a message and got a query from the owner of the remailer saying "I couldn't help looking through my remailer archives and noticing...." and requesting more information from me!! Hoist by my own petard! Several lessons: * Multiple bounces help, even without encryption, as then the remailer sysop can't be sure who originated the message. * Encryption is of course even more desirable, though a hassle (especially for Mac users). * Remailer sysops should make a point to _not_ look at their remailer archives. In fact, they should discard them immediately (for their own legal protection, and for slightly greater trust amongst users, though this is a hazy area...). (Recall that the "mix" on which our software-based remailers are loosely patterned are "memoryless," i.e., the tamper-resistant modules that implement the receive-decrypt-store-forward protocol have no memory of the mapping between incoming and outgoing messages. In fact, the outside world cannot possibly compromise the protocols to get at this information.) So, my laziness in using only a single bounce, combined with the curiosity of a remailer sysop, breaks the anonymity. Neither surprising nor profound, but I thought you folks would like to know. --Tim May -- .......................................................................... Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay at netcom.com | anonymous networks, digital pseudonyms, zero 408-688-5409 | knowledge, reputations, information markets, W.A.S.T.E.: Aptos, CA | black markets, collapse of governments. Higher Power: 2^756839 | PGP Public Key: by arrangement. From eric at parallax.com Thu Jan 21 13:32:16 1993 From: eric at parallax.com (Eric Messick) Date: Thu, 21 Jan 93 13:32:16 PST Subject: random remailers Message-ID: <9301212047.AA04073@parallax.com> >> Has anyone thought about the consequence of randomly picking a >> remailing path instead of using the same one? > >what if the remailer flips a coin, choosing between final delivery >and remailing through another of its ilk. "message delivery with >probability one ..." The problem with this is that every site along the way has to know the final delivery address, at least of this subset of the address chain. Better to just send it directly, and add some load balancing traffic. -eric messick From deltorto at aol.com Thu Jan 21 14:37:37 1993 From: deltorto at aol.com (deltorto at aol.com) Date: Thu, 21 Jan 93 14:37:37 PST Subject: public servant privacy Message-ID: <9301211631.tn66179@aol.com> In response and affirmation of Eric Fogleman's note on Communications Policy, I have to concur. ALL documents produced by a public official operating an email system on public time and in pursuit of public policy (e.g. a White House official) should be subject to scrutiny and should not be considered as that person's private property. If such a person wants to have private communications with other private citizens, they should do it on their OWN time and with their OWN money. HOWEVER, if such persons then turn around and abuse this freedom by abusing the public trust in those contexts (i.e. if Ollie North started communicating with NSA officials through CompuServe to order illegal shipments of money to CIA agents in Peruvian cocaine cartels), they should, by virtue of their positions of public trust be subject to the same (presumably high) levels of scrutiny as they are now - Congressional, OMB, GSA, FBI investigations, etc. >>The burden should not be on individuals to constantly be open to scrutiny to >>demonstrate their innocence, but on those with the power to suspend individual >>rights. Yes, private citizens should not be subject to the same sorts of investigations unless there is direct evidence of criminal intent or activity in which case there should be a search warrant and notification of intent to search. Tim May notes (appropriately) that: >>Strong crypto means even Ollie North can fully protect his records. Yes, but shouldn't he be _required_ to "open" his files if he is under criminal investigation just like a drug-dealer who's required to open the locked trunk of his car? I'm sure my opinion is open to development, but this is my gut-level response. dave From deboni at diego.llnl.gov Thu Jan 21 14:59:21 1993 From: deboni at diego.llnl.gov (Tom DeBoni) Date: Thu, 21 Jan 93 14:59:21 PST Subject: privacy vs. public servants Message-ID: <9301212254.AA01411@diego.llnl.gov> This is a very interesting thread. But should university academicians working for state-supported institutions be subject to the same constraints on privacy and freedom from arbitrary search and seizure in their email and computer files as high federal governmental officials? I submit that the amount of (real or potential) oversight should be somehow proportional to the potential for harm or abuse of power available to the individual involved. Surely Ollie North or Richard Nixon had much greater abilities to subvert the democratic process or otherwise break the law than Professor Smith of the Chemistry Dept. of State U. Tom DeBoni (a state and federal employee with no power whatsoever) From thug at phantom.com Thu Jan 21 15:20:09 1993 From: thug at phantom.com (Murdering Thug) Date: Thu, 21 Jan 93 15:20:09 PST Subject: public servant privacy In-Reply-To: <9301211631.tn66179@aol.com> Message-ID: deltorto at aol.com writes: > > Yes, private citizens should not be subject to the same sorts of > investigations unless there is direct evidence of criminal intent or activity > in which case there should be a search warrant and notification of intent to > search. > > Tim May notes (appropriately) that: > >>Strong crypto means even Ollie North can fully protect his records. > > Yes, but shouldn't he be _required_ to "open" his files if he is under > criminal investigation just like a drug-dealer who's required to open the > locked trunk of his car? Well, there are really two conflicting issues here: 1) The Fifth Amendment - the right not to testify against yourself, hence the Miranda warning when you're arrested. You can claim that being forced to decrypt your hard disk by the cops violates your Fifth Amendment rights, and refuse to decrypt it. 2) Obstruction of Justice - by not handing over the key to your hard disk, you may be obstructing an investigation. By not decrypting your hard disk under court order, you maybe be held in contempt of court. Number 2 may work for law enforcement if they are investigation a third party and ask to see your hard disk in order to help their investigation. A good example is an Internet site that is being used as a telnet launch-pad by some hacker. If that site refuses to cooperate and keeps their files encrypted, the police/court may charge you with obstruction of justice or contempt of court. HOWEVER, if you feel that by decrypting these files, you would be providing testimony/evidence against yourself, you can plead the 5th, and tell them to go screw themselves. Thug From jcoryell%nwu.edu at UICVM.UIC.EDU Thu Jan 21 15:43:41 1993 From: jcoryell%nwu.edu at UICVM.UIC.EDU (John Coryell.) Date: Thu, 21 Jan 93 15:43:41 PST Subject: possible solution to the anonymous harrassment problem In-Reply-To: <9301211642.AA02369@soda.berkeley.edu> Message-ID: <9301212343.AA21192@toad.com> Are there any citations of instances of this happening? John Coryell. From julf at penet.FI Thu Jan 21 15:48:46 1993 From: julf at penet.FI (Johan Helsingius) Date: Thu, 21 Jan 93 15:48:46 PST Subject: Communications Policy In-Reply-To: <9301211716.AA27162@netcom3.netcom.com> Message-ID: <9301220100.aa01285@penet.penet.FI> Tim May writes: > This was well-debated about a month or so back. Ooops. Sorry. Must have been just before I joined the list. Always putting my foot in the wrong place... > In a note I wrote back then, which did not name the particular site > involved, I reported that after sending a piece of "anonymous" mail, I > got a letter of "support" for my position from the remailer operator! Urgh! > After I mentioned this to the Cypherpunks list, it came out that other > sites were also keeping various forms of archives (for some or all of > the reasons listed above). Double urgh! > Anyway, such human-operated remailers, running on UNIX boxes in > unsecure conditions, have many nonideal characteristics. Agree. Julf From jthomas at access.digex.com Thu Jan 21 17:03:28 1993 From: jthomas at access.digex.com (Joe Thomas) Date: Thu, 21 Jan 93 17:03:28 PST Subject: public servant privacy In-Reply-To: Message-ID: On Thu, 21 Jan 1993, Murdering Thug wrote: > deltorto at aol.com writes: > > > > Tim May notes (appropriately) that: > > >> > > >>Strong crypto means even Ollie North can fully protect his records. [Jeez, I feel like taking this to alt.cascade...] > > > > Yes, but shouldn't he be _required_ to "open" his files if he is under > > criminal investigation just like a drug-dealer who's required to open the > > locked trunk of his car? > > Well, there are really two conflicting issues here: > > 1) The Fifth Amendment - [legal summary elided] > > 2) Obstruction of Justice - [again] . . . > > Number 2 may work for law enforcement if they are investigation a third > party and ask to see your hard disk in order to help their investigation. > A good example is an Internet site that is being used as a telnet launch-pad > by some hacker. If that site refuses to cooperate and keeps their files > encrypted, the police/court may charge you with obstruction of justice or > contempt of court. HOWEVER, if you feel that by decrypting these files, > you would be providing testimony/evidence against yourself, you can plead > the 5th, and tell them to go screw themselves. I believe the only way for the autorities to get around that is to grant you immunity for whatever you reveal (if giving crypto keys is held to be more like giving testimony against one's self than like opening a car trunk). They did it for Ollie North, and he used that to get a later conviction thrown out. To bring this back to crypto, the ability of authorities to compel testimony from people by granting them immunity is a _great_ argument for remailers not even keeping records. Joe From ncselxsi!drzaphod at ncselxsi.netcom.com Thu Jan 21 20:47:20 1993 From: ncselxsi!drzaphod at ncselxsi.netcom.com (DrZaphod) Date: Thu, 21 Jan 93 20:47:20 PST Subject: random remailers Message-ID: <73148.drzaphod@ncselxsi> In Message Thu, 21 Jan 93 12:47:35 PST, Eric Messick writes: >The problem with this is that every site along the way has to know the >final delivery address, at least of this subset of the address chain. >Better to just send it directly, and add some load balancing traffic. > >-eric messick What about letting every remailer see the second to last system in the remailing process, another remailer. Other remailers would route the message around for a specified # of times +/- a small random # [users choice with a max. limit set by remailers]. The second to last remailer would recognize the last remailer from it's public key encrypted message [::Request-Remailing-To: FinalDestination] and send it on down to the last remailer which would decrypt the final remailing block using it's secret key and send the intended message to it's final destination. This would provide random remailing routes without compromising the ending not originating location. The first remailer wouldn't know if it had just received a message from a person, or another remailer. TTFN! DrZaphod [AC/DC] / [DnA][HP] [drzaphod at ncselxsi.uucp] Technicolorized From parish at cactus.org Thu Jan 21 21:35:17 1993 From: parish at cactus.org (Tom Parish) Date: Thu, 21 Jan 93 21:35:17 PST Subject: unsubscribe Message-ID: <9301220516.AA15042@cactus.org> Please remove me from the mailing list. Thank you Tom From thug at phantom.com Thu Jan 21 21:52:44 1993 From: thug at phantom.com (Murdering Thug) Date: Thu, 21 Jan 93 21:52:44 PST Subject: the bill of rights hasn't been revoked. not yet, anyway. Message-ID: I've been thinking about this a bit, and it seems that the Constitution's Bill of Rights has all the provisions required to implement and legally use digital money, secure encryption, and anonymous communication networks. Specifically, the First, Fourth, and Fifth Ammendments can be used as one's defense in implementing any of the above. The First Ammendment can be seen as allowing encryption. Freedom of Speech does not preclude the government or anybody for that matter having to understand what I am saying. I can just as easly say "blardi blahr oof aarf bloo arrr foo barr arrh blard foobaaaaah" or "010110101101101011101.." to anyone I like and be protected by the First Amendment. Only those that can decode my speech will understand it, those that can't won't. I am free to speak to whoever I like (freedom of association / assembly). I am free to speak anonymously provided I break no law (copyright, slander/libel, etc.). Even if I do break a law, the next two paragraphs will show that I cannot be prosecuted for such a crime very easily. The Fourth Ammendment protects us from illegal search and siezure. If the government can get a warrant, they can search my place and sieze all my encrypted files. They can intercept my encrypted communications. They can have them, it won't do them any good. But it is their duty to decode it, not mine, and the Fifth Amendment basically says that.. The Fifth Ammendment is the tastiest one of all when it comes to encryption. By pleading the Fifth, you do not have to decrypt anything for the prosecution. The Fifth Ammendment gives you the right not to testify or provide evidence that would incriminate you. Providing a key to decrypt your hard disk would incriminate you, and you don't have to do it. In short the 1st & 5th ammendments + Secure Encryption can be used make even a completely legal search or wiretap warrant against one self worthless. Hence, not enough evidence for prosecution, hence no prosecution. They can't force you to decrypt any of your communcations or stored files, because you merely plead the Fifth amendment. This is assuming one encrypts everything, and has no accomplices/conspiritors who offer to testify for the prosecution. Even then, with public key encryption, the most that people who rat on you can give to the prosecutors are messages that you sent to them (the rat). And assuming all messages that you have sent out are sufficiently vague/obscure as to be non-incriminating, you are fairly safe there too. Assuming all messages from you were sent anonymously to a list, they can't even prove you sent them. Thus if they cannot force you to decrypt your hard disk, you should be relatively safe from successful prosecution for whatever, whether it be drug running or running a anonymous digital money bank / barter house. I guess now you can see why the government is so scared of encryption. Widespread use of encryption on the part of the criminal class would simultaneously obsolete all police, the FBI, CIA, Secret Service, and Department of Justice, or at the very least make their jobs several thousand orders of magnitude more difficult. For example, a child pornography ring that trades anonymously in encrypted .gifs using truly anonymous remailers would be impossible to take down by just taking down one member of the ring. Furthermore, it may be impossible to prosecute even that one member. Thug From deltorto at aol.com Thu Jan 21 22:36:26 1993 From: deltorto at aol.com (deltorto at aol.com) Date: Thu, 21 Jan 93 22:36:26 PST Subject: ...and other Trials Message-ID: <9301220135.tn69465@aol.com> >> Tom DeBoni adds: >>should university academicians working for state-supported institutions be subject >>to the same constraints on privacy and freedom from arbitrary search and seizure in >>their email and computer files as high federal governmental officials? That's a tough one. I suppose there would have to be a body that decided on a case by case (or a class by class) basis what accounts would be subject to heavy scrutiny. Unfortunately, this begins to create a overseeing body so huge and convolute as to render the entire process unwieldly approaching on the absurd. I read Kafka's "The Trial" and I don't want to face that sort of Juggernaut any time soon. On the other hand, if you don't lump _every_ friggin' state and federal employee (and I didn't) into the picture and only consider those persons with a dangerous largesse inherent in their positions (sorry, but that swell fella Ollie North somehow once again comes to mind), the whole thing takes on a more manageable (notice I said "more") appearance. Hey, this is a tough ethical dilemma. I ain't got all the answers, just an opinion (just like assholes... everyone's got one, right?). Basically, I worry about abuse of email systems by knowledgable/sinister government officials. When you consider how hard it is for the general public to conceive of abuse on paper memos, imagine how much damage and subversion a savvy individual could do with a "computer" (gwarsh, Mickey! Whut's a kum-pee-you-ter?) to the democratic process before anyone would pay attention to a cypherpunk crying "wolf!" Encryption to the Masses! dave From deltorto at aol.com Thu Jan 21 22:36:27 1993 From: deltorto at aol.com (deltorto at aol.com) Date: Thu, 21 Jan 93 22:36:27 PST Subject: Preferably a screw with BIG threads Message-ID: <9301220135.tn69466@aol.com> I dig Thug's comment about the "two conflicting issues here" (The Fifth Amendment & Obstruction of Justice). Especially the part about "tell[ing] them to go screw themselves." : ) I suppose that certain "specially designated' accounts belonging to certain "specially designated" officials should be open to complete scrutiny by the 'balancing' arms of Government, i.e. the Executive Branch should be 'checkable' by the Legislative, etc, etc. That begins to sound more Democratic, don't it? At least it sounds "democratic" as we hope it would be (maybe not as we know it to be). dave From Marc.Ringuette at GS80.SP.CS.CMU.EDU Thu Jan 21 23:08:40 1993 From: Marc.Ringuette at GS80.SP.CS.CMU.EDU (Marc.Ringuette at GS80.SP.CS.CMU.EDU) Date: Thu, 21 Jan 93 23:08:40 PST Subject: the bill of rights hasn't been revoked. not yet, anyway. Message-ID: <9301220708.AA26798@toad.com> > I've been thinking about this a bit, and it seems that the Constitution's > Bill of Rights has all the provisions required to implement and legally > use digital money, secure encryption, and anonymous communication networks. I agree, but only if you do all the public key encryption inside your head. :-) :-( You're interpreting the first amendment much more liberally than current legal practice would warrant. Just because something is an act of communication doesn't mean it's protected speech under the first amendment. -- Marc Ringuette (mnr at cs.cmu.edu) From jgarner at netcom.com Fri Jan 22 03:08:33 1993 From: jgarner at netcom.com (Jason Garner) Date: Fri, 22 Jan 93 03:08:33 PST Subject: Does anyone know of any specific cases Message-ID: <9301221108.AA14072@netcom2.netcom.com> Does anyone know of any specific legal cases which have tested or are testing this issue of a conflict between the 5th amendment and Obstruction of Justice? Seems I read about something like this recently in a California newspaper but I cant seem to remember the case. From hughes at soda.berkeley.edu Fri Jan 22 07:48:48 1993 From: hughes at soda.berkeley.edu (Eric Hughes) Date: Fri, 22 Jan 93 07:48:48 PST Subject: crypto, NSA, gnu, and cypherpunks in Boardwatch magazine Message-ID: <9301221546.AA24473@soda.berkeley.edu> Jack Rickard was kind enough to send me the following. A new member of the list told me he had found out about the list from this article. Eric ----------------------------------------------------------------------------- From: jack.rickard at boardwatch.com Date: Wed Jan 20 09:57:55 1993 Subject: CYPHERPUNKS COVERAGE The following article appeared in the February, 1993 issue of Boardwatch Magazine, a monthly publication covering electronic bulletin boards, online information services, and networking issues. Boardwatch Magazine is published monthly at an annual subscription rate of $36. Boardwatch Magazine, 7586 West Jewell Ave., Suite 200, Lakewood CO 80232; (303)973-6038 voice; (303)986-8754 fax; (303)973-4222 data. Internet: jack.rickard at boardwatch.com. FRONTAL ATTACK ON THE PUZZLE PALACE by Lance Rose A privately funded attack is underway against a little-known government agency that has devoted itself to the control of privacy in this country (who gets to have privacy, who doesn't, and how much privacy can anyone have?). If successful, it may begin to unravel decades of surreptitious information control so effective most of us have not been aware of its operation. The agency in question is the National Security Agency, or NSA. It was established in 1952 by President Harry Truman to monitor signal transmissions that might affect the security of the United States. Since that time, the NSA has steadily cast a pall over public use and knowledge of cryptography, and generally regulated the limits of privacy in this country. It has done so with 40,000 or more active employees, and funding not readily discernible from inspecting Congressional budget lines. Those not already familiar with the NSA might be surprised at the depth and extent of its influence. For instance, rumor has it that NSA monitors much of the digital telephone activity in this country, even though it is authorized only to monitor foreign transmissions. NSA is also in charge of regulating the export of cryptographic devices to other countries, which are officially deemed such a great security risk they are dealt with as "munitions" under the U.S. export control laws. Any device or software intended for export and using encryption techniques (which are usually included to aid in the privacy or security of personal or business communications, such as in cellular phones) must be reviewed by the State Dept., which generally passes on the review to the NSA. These review processes are so slow and nitpicking that they choke off almost all international trade in effective encryption devices from the U.S. The ultimate effect of this process, as pointed out by John Barlow of the EFF, is to inhibit development of strong encryption devices even within the U.S., since manufacturers are often reluctant to make two different versions of their goods, one for domestic use and one for export. Well-known, powerful encryption techniques subject to close NSA export control include devices based on the DES algorithm, and public key devices based on the RSA algorithm. In addition, NSA is actively involved, along with such cohorts as the FBI and the Justice Department, in ongoing legislative efforts to keep effective new cryptography and privacy techniques out of the public's hands. Last year, proposed Senate Bill 266 would have made it illegal to use a cryptographic technique unless the government had been provided a "back door" enabling it to easily extract the plain text from any message encrypted through that technique. Apparently, brute force cipher-cracking by the NSA was wasting a little too much of the taxpayers' dollars (albeit through untraceable budget lines) so we would all get a break if the government's obligatory snooping and code-cracking activities cost a lot less. Luckily, this bill was kept from enactment, in large part through the efforts of the Electronic Frontier Foundation. NSA and FBI came back this year with a new variation - a bill that would require all phone companies to set up special wiretap stations for official eavesdropping, so agents would not have to waste taxpayer dollars figuring out how to tap those nasty optical fiber lines without being detected. It's ironic that in the face of a federal statute (the Electronic Communications Privacy Act) with strong legal obstacles to discourage officials who seek to monitor private telephone activities, those same officials want to install facilities giving them the practical ability to wiretap as easily as you or I might open the faucet for a glass of water. Another NSA tactic has been massive removal of texts on cryptography from public access through classifying them as secret government documents. Again, slowing down the transmission of knowledge on cryptography in this manner has placed a drag on development of publicly useful encryption methods. The advent of the Freedom of Information Act (FOIA) threatened this regime, with its provisions for requesting declassification of government documents. However the NSA, like many other federal agencies, discovered a fairly effective antidote to FOIA requests: ignore the requests, and when it could ignore them no longer, make the requesting party drag the NSA bodily into court over and over in escalating legal procedures to compel production of the requested documents. This process was such a burden on the requesting parties that it weeded out all but the most dedicated and well-financed attempts to fetch documents on cryptography out of the black hole of NSA classification. Such conduct was also literally illegal, since it involved failure to meet statutory time limits to respond to FOIA document requests. The NSA appeared to be deliberately not meeting the time limits, and basically thumbing its nose at those who sought the documents under its control. One of those who encountered the NSA's monumental heel- dragging in releasing cryptography-related documents was John Gilmore. Gilmore runs a software house named Cygnus Support, was one of the founders of the Electronic Frontier Foundation, and is a vocal and impassioned supporter of individual privacy rights against the modern encroachments of the state. Gilmore and his attorney, Lee Tien, decided to challenge certain NSA practices head-on, specifically the practices of overclassifying documents in the area of cryptography, and the NSA's unwillingness to release cryptographic materials into the public domain regardless of whether the materials actually have strategic military value justifying their classification. In July, 1992, Gilmore requested, under the FOIA, copies of the books "Military Cryptanalysis" by Friedman, volumes 3-4 (earlier volumes were already declassified) and "Military Cryptanalytics" by Friedman and Callimahos, volume 3 onward (the exact number of volumes is not publicly known). The Friedman books dated from the 1930's, the ones with Callimahos from the 1950's - not likely state of the art stuff. To add a little irony, Friedman had been one of the founders of the NSA. To no one's surprise, the NSA did not respond to Gilmore's FOIA request for the books. Gilmore appealed the decision administratively, but again was unable to obtain the materials, forcing him to the next step of filing a suit against NSA in federal court in the Northern District of California. Here is an example of an administrative setup ripe for abuse, being played for all it's worth by the NSA. In an ordinary court action, a party who does not respond within a time limit set by statute can lose the case by default. Here, however, the NSA did not lose anything by not responding to the FOIA requests in the administrative agency setting. In fact it actually gained an advantage, forcing Gilmore to put more energy and resources first into a pointless administrative appeal, and then finally starting a federal court action from scratch. Some time after beginning the FOIA procedure, Gilmore tracked down the Friedman volumes from the '30's at a couple of public repositories in California. Amazingly, when the NSA found out he had the books, they told him the books were still classified or should be classified, and threatened him with a criminal action if he dared to show the books to anyone else. This received some press attention in the S.F. Examiner and elsewhere, to the NSA's great displeasure. Not only was the NSA getting publicity, which it shuns, but it looked like NSA was trying to bury ancient materials already fully accessible to the public, and threatening to jail someone who dared assert the public had a right to such materials. The attention had a salutary effect on the NSA's actions, however. They recently declassified the old Friedman volumes, making it perfectly legal for Gilmore to distribute them. Score one for the libertarians. They have started the NSA backpedalling. As we go to press, Gilmore's case against the NSA is still proceeding for purpose of obtaining the remaining Military Cryptanalytics volume(s), as well as a "pattern and practice" claim against the NSA. This last legal claim is particularly important. As described above, the NSA drags its heels on FOIA requests, outlasting all but the most resolute opponents. But any time a hardy soul manages to push his case close to a court decision, the NSA can turn around at the last moment and say, "here are the materials you requested." The case would then officially become moot because the request was finally honored, and no court decision stating that the NSA engages in obstructive and delaying practices would ever issue. This sorry result can be avoided by the claim that NSA engages in a "pattern and practice" of obstructing and delaying FOIA requests for cryptographic materials. It will survive any such "mooting" move by the NSA, and if Gilmore perseveres, may result in a judicial decision laying some of the NSA's practices bare on the public record. If Gilmore and his attorney Lee Tien succeed, they could end up chipping off a big piece of the NSA wall of darkness. From the look of things, they may still have some arduous going ahead. No matter the decision on the trial court level, the NSA will have many court appeals left, and doubtless ot getting to UUCICO:USERLOG:d:\tbbs\userlog.inx Those interested in cryptography issues may find a new Internet mailing list of interest. A group is physically meeting in John Gilmore's Silicon Valley facilities and has started a mailing list under moderation of Timothy C. May (tcmay at netcom.com). The group includes John Draper (Cap'n Crunch), Tom Jennings, and others interested in cryptography, anonymous mail forwarding techniques, encryption, the Pretty Good Privacy program, and other privacy issues. You can join this mailing list from any service allowing Internet e-mail by sending a message to CYPHERPUNKS-REQUEST at TOAD.COM. [Lance Rose is an attorney practicing high-tech, computer and intellectual property law in the New York City area, and is available on the Internet at elrose at well.sf.ca.us and on CompuServe at 72230,2044. He works with shareware publishers, software authors, system operators, technology buyers, interactive media developers, on-line database services and others in the high technology area. He is also author of the book SYSLAW, a legal guide for bulletin board system operators, available from PC Information Group (800)321-8285. - Editor]  From hughes at soda.berkeley.edu Fri Jan 22 08:11:25 1993 From: hughes at soda.berkeley.edu (Eric Hughes) Date: Fri, 22 Jan 93 08:11:25 PST Subject: PGP on BBS In-Reply-To: <9301211702.AA11275@xanadu.xanadu.com> Message-ID: <9301221609.AA24776@soda.berkeley.edu> I wrote: >>The solution is cooperative processing systems, where both the host >>and the terminal cooperate to perform some task. Dean asks: >What would the two systems be cooperating about? I'm not sure to what >you are pointing. Here are two basic examples: 1. Session key creation. I regularly log in remotely to my account at soda. I'd like to have that modem link encrypted, with session keys generated on the fly. So I'll want to use some implementation of Diffie-Hellman key exchange to make a session key. The nature of this protocol means that both my terminal program and my host have to do calculations and exchange data. Therefore I need software on my PC at home and software on the host that work together. 2. Digital signatures. I read and send my e-mail on the host. When I send PGP-encrypted mail, I have to compose the message on the PC, encrypt it with a PGP command line, upload it to the host with zmodem, and read it in to my mailer. I'm certainly not going to put my secret key on the host. What would be ideal is a cooperative protocol that initiated (in the background, away from my main connection) a channel, sent just the data to be signed (an IDEA key, for example), have my PC sign the data and send it back. This not only entails software on each end, but also a line multiplexer so that the signing can take place on a separate channel. If it doesn't occur on a separate channel, then I have to see it, probably move to the shell in order to start it properly, and in general make it non-automatic. Eric From thug at phantom.com Fri Jan 22 09:39:03 1993 From: thug at phantom.com (Murdering Thug) Date: Fri, 22 Jan 93 09:39:03 PST Subject: the bill of rights hasn't been revoked. not yet, anyway. In-Reply-To: <199301221440.AA05524@ra.oc.com> Message-ID: Matthew Lyle writes: > In a recent message, Murdering Thug said: > | The Fifth Ammendment is the tastiest one of all when it comes to > | encryption. By pleading the Fifth, you do not have to decrypt anything > | for the prosecution. The Fifth Ammendment gives you the right not to > | testify or provide evidence that would incriminate you. Providing a > | key to decrypt your hard disk would incriminate you, and you don't > | have to do it. > > What the government has to do in this case is to give you immunity from > prosecution. They can then order you to decrypt your hard disk. You can't > refuse based on the 5th ammendment because you have been given immunity from > prosecution. They can't use the hard drive against you, but they then can > in anybody elses prosecution. Agreed. I guess if you refuse after that point, they can hold you in contempt of court or cite you for obstruction of justice. BUT, what if they "crime" involves only you. Then they (the prosecutors) are up shit's creek, pardon the language. You're immune, and there's no one left to prosecute. Okay, let's assume the crime involves a conspiracy, and they give you immunity and force you to decrypt your hard disk. What good would this do them if all your communications between your conspirators took place anonymously and the messages from your conspirators are so vague/obscure as to be worthless as evidence. Now, they have already given you immunity, and now they can't even go after your conspirators because they may not even know who those conspirators are or even what the hell those conspirators were talking about in their vague/obscure messages to you. Even if the prosecutors know what the messages are in reference to, they still have to prove that in a court of law, beyond a reasonable doubt. Since they cannot go back on their promise of immunity to you, the prosecutors are again up shit's creek. All this will only work providing the prosecutors have no other evidence against you (ie: voice wire taps, physical evidence (notes, cancelled checks, survielance video, stashed cash, etc.)). If you conduct EVERYTHING via encrypted and anonymous communications and keep all records encrypted, they really cannot touch you. Don't you just love crypto-anarchy? I know I do. Thug From fen at genmagic.genmagic.com Fri Jan 22 10:22:09 1993 From: fen at genmagic.genmagic.com (Fen Labalme) Date: Fri, 22 Jan 93 10:22:09 PST Subject: the bill of rights hasn't been revoked. not yet, anyway. Message-ID: <9301221821.AA12809@> > Murdering Thug writes: > If you conduct EVERYTHING via encrypted and anonymous communications and > keep all records encrypted, they really cannot touch you. > > Don't you just love crypto-anarchy? I know I do. So do I! I get the feeling that MT is attempting to display some of the dangers of crypto-anarchy via sarcasm. (I really can't be sure, as such intonations are really difficult to convey or pick up on in ascii.) While it is true that in a free society, someone could buy a gun and kill all their neighbors and possible even get away without a trace, I would rather live in that free society than one that disallows the purchase of the gun to begin with. (The fact that I support strong gun control measures is not contradictory to this.) In the same way, I would like to encourage everyone, even the Ollie Norths, to encrypt their communications. Sure, there will be conspiracies that take their toll upon society, but I feel that one of the biggest causes of violence is the feeling of dis-empowerment caused by conventional laws. Note, for example, that the countries that are less uptight about nudity generally have less sex crimes. Laws take power away from people. Encryption affords people the capability to gain access to the information they want and disseminate it to those they want to without fear of recrimination. This empowering technology will, imho, empower the many to cause less harm to the few, and empower the few to get what they want while protecting themselves from the wrath of the many. Hope that you find some of these ideas worthwhile... Fen From marc at MIT.EDU Fri Jan 22 10:26:42 1993 From: marc at MIT.EDU (Marc Horowitz) Date: Fri, 22 Jan 93 10:26:42 PST Subject: the bill of rights hasn't been revoked. not yet, anyway. In-Reply-To: Message-ID: <9301221825.AA23938@tla.MIT.EDU> The major problem is that in any case which the government will be interested, money is involved. The problem with anonymous banking is that it can't look like banking, because the reporting laws for banks are extrememly tight. No matter what the bill of rights says, certain things (such as cash transactions over a certain amount) must be reported. Interest must be reported by federal taxpayer ID. (Ok, we don't pay interest. This is the cost of privacy, I guess.) And I'm not convinced that if the banks records were seized, that you could avoid being traced. you have to get the money to and from them somehow. And even if I'm unkown by name to them, I'll be damned if I'm going to put *money* into a bank which I (or my agent) can't walk up to and do business if I so choose. Marc From Marc.Ringuette at GS80.SP.CS.CMU.EDU Fri Jan 22 10:33:25 1993 From: Marc.Ringuette at GS80.SP.CS.CMU.EDU (Marc.Ringuette at GS80.SP.CS.CMU.EDU) Date: Fri, 22 Jan 93 10:33:25 PST Subject: the bill of rights hasn't been revoked. not yet, anyway. Message-ID: <9301221833.AA06301@toad.com> > Agreed. I guess if you refuse [ to decrypt your files] after that > point, they can hold you in contempt of court or cite you for > obstruction of justice. Oh yeah, this reminds me of a scheme by my friend Fuzzy. Create an encryption system which compresses and encrypts two files in the space of one (more or less) using two different keys, the "real" one and the "innocent" one. When you encrypt something, you also encrypt a similar-sized hunk of innocuous text. When they ask for the key, you give them the one that spits out the fake stuff. True, it's security by obscurity. But I thought you might be interested. -- Marc Ringuette (mnr at cs.cmu.edu) From Eric.Fogleman at analog.com Fri Jan 22 10:50:13 1993 From: Eric.Fogleman at analog.com (Eric Fogleman) Date: Fri, 22 Jan 93 10:50:13 PST Subject: privacy vs. public servants Message-ID: <9301221847.AA01967@ack.adstest.analog.com> Responding to Tom DeBoni's message concerning whether or not government officials should have a right to secure communications. > I submit that the amount of (real or potential) oversight should be > somehow proportional to the potential for harm or abuse of power > available to the individual involved. Surely Ollie North or Richard > Nixon had much greater abilities to subvert the democratic process or > otherwise break the law than Professor Smith of the Chemistry Dept. of > State U. Agreed! I agree with Dave Deltorto's idea about "a body that decided on a case by case (or a class by class) basis what accounts would be subject to heavy scrutiny". Or perhaps limiting certain public servants (the chief executive, Oliver North's successor, etc) to a set of "open" computing systems and communication paths. (Similar to limiting people with security clearances to sets of closed computing systems, communication paths.) Dave says: > Unfortunately, this begins to create a overseeing body so > huge and convolute as to render the entire process unwieldly > approaching on the absurd. I read Kafka's "The Trial" and I don't > want to face that sort of Juggernaut any time soon. Unwieldy? Kafka-esque? Expensive? Possibly, but it doesn't have to be that way. As Bongo says: "The price of freedom is eternal vigilance." How much do you want to pay? Eric Fogleman From ld231782 at longs.lance.colostate.edu Fri Jan 22 15:24:53 1993 From: ld231782 at longs.lance.colostate.edu (ld231782 at longs.lance.colostate.edu) Date: Fri, 22 Jan 93 15:24:53 PST Subject: the bill of rights hasn't been revoked. not yet, anyway. In-Reply-To: Message-ID: <9301222323.AA05827@longs.lance.colostate.edu> The Thug brings up some useful ideas of the constitution guaranteeing the right to encryption. The point that communication and encryption are very similar is a very crucial idea. However, he goes astray: >I guess now you can see why the government is so scared of encryption. >Widespread use of encryption on the part of the criminal class would >simultaneously obsolete all police, the FBI, CIA, Secret Service, and >Department of Justice, or at the very least make their jobs several >thousand orders of magnitude more difficult. For example, a child >pornography ring that trades anonymously in encrypted .gifs using >truly anonymous remailers would be impossible to take down by just >taking down one member of the ring. Furthermore, it may be impossible >to prosecute even that one member. This makes it sound as if criminals will suddenly find no obstacle to their deviant behavior with the use of cryptography, a ridiculous assertion. Law enforcement will be made more difficult but arguably the government has never legitimately had the "right" to wiretap, and law enforcement will of course will never be "obsoleted" by technology. We must separate the activity of spying from the activity of law enforcement (the agencies noted are in both categories). The former will be perhaps "thousand orders of magnitude more difficult" but the latter will not be significantly affected, I'd wager (most criminals are low tech). A Murdering Thug will be caught, eventually, when he murders somebody regardless of his use of cryptography. BTW, it annoys me that anyone thinks that law enforcement will be made impossible when cryptography becomes widespread. This extreme idea is absolutely absurd. Definitely, it will be affected, and perhaps some "criminals" will not be caught that once might have. But I suspect that the criminals perpetrating the worst crimes, the ones civilized people find most abhorrent and heinous, will be largely unaffected. There are far better ways to improve the currently inefficient and often ineffective law enforcement techniques than by improving wiretapping techniques. Its funny how totalitarian governing systems (the logical extent of completely outlawing cryptography) often manage to find "criminals" where previously none existed. From ld231782 at longs.lance.colostate.edu Fri Jan 22 16:02:13 1993 From: ld231782 at longs.lance.colostate.edu (ld231782 at longs.lance.colostate.edu) Date: Fri, 22 Jan 93 16:02:13 PST Subject: public privacy, NSA resources In-Reply-To: <9301221546.AA24473@soda.berkeley.edu> Message-ID: <9301230001.AA06625@longs.lance.colostate.edu> Some ideas on just how "public" public servants' communication is have been raised here. >I have to concur. ALL documents produced by a public official operating an >email system on public time and in pursuit of public policy (e.g. a White >House official) should be subject to scrutiny and should not be considered as >that person's private property. (deltorto at aol.com) I'd like to take this a bit further. The new emerging technology of global networking is a means for previously uninfluential citizens to take back control of our governments. Is it just me, or does it seem like the US version is way out of control? Growing uncontrollably like a cancerous tumor? As a citizen of this country I am vehemently irate at public servants who use their positions and influence to thwart their own laws (e.g. Congress is exempt from many laws it passes). There seems to be a real undercurrent of stonewalling everywhere, and the insideous attitude that the public is not who you serve, but who you mislead to get more money or power. Why shouldn't every budget of every federal agency be public knowledge? I could see where MY TAX MONEY is being spent. Why shouldn't I be able to determine what any given US public official (elected or unelected) is doing on a given day? What a given agency is accomplishing? Because its impractical? Because it's not my business? HAH! It is not only practical, but will eventually happen. Imagine if all this information were stored in a single unified public database...! As accessable as a library book? Imagine the horrors we would uncover! (Interesting: technology will greater polarize the distinctions of "public" and "private" information.) The possibility of greater control over tax money is here too. Some presidential candidate (I forget who, Perot?) suggested having a box on the tax form that would allow constituents to direct money directly to the federal deficit. Of course, in today's atmosphere of complete fiscal irresponsibility and obfuscation such an idea is completely meaningless. But in the government of tomorrow, we will have must broader control over directing where our tax money will go. Imagine that I was required to spend a certain amount of money on government services (my total taxes) but that I could redirect the actual amounts to agencies (in broad categories) that serve me best. Suppose that even *private companies* could compete for this money on my tax form! It would almost be as if the federal government didn't even exist--our government would be nothing but a method of reallocating money in the most efficient way possible. (Hm, I think I'll give $0.001 to the NSA this year, hehe.) Regarding inefficiency, note the sheer obstacles that "whistleblowers" encounter in our government. Most are lucky to just be demoted. Others are harassed and threatened and fired, or worse. All this for potentially saving money and making an organization more efficient! We need to elevate the whistleblower to heroic status, and encourage every member of the US population to be one if possible. I'm not advocating paranoia or violent revolution, just that we increase our vigilance by increasingly exercising our rightful control with the aid of fresh technological developments. - - - >FRONTAL ATTACK ON THE PUZZLE PALACE >by Lance Rose >Since that time, the NSA >has steadily cast a pall over public use and knowledge of cryptography, and >generally regulated the limits of privacy in this country. It has done so with >40,000 or more active employees, and funding not readily discernible from >inspecting Congressional budget lines. 40,000? Is this for real? Does anyone know how this would compare to FBI or CIA? Also, does anyone have a clue on the black budget? The author seems to hint here that while it is not "readily discernible" it might be inferrable. There were a lot of files maintained by the FBI on suspected communists during the McCarthy era. I wonder what delicious little morsels have been squirreled away in the bowels of our massive behemoth? Esp. with the scarily massive capabilities of archival possible with today's storage technologies... From lefty at apple.com Fri Jan 22 16:28:59 1993 From: lefty at apple.com (lefty at apple.com) Date: Fri, 22 Jan 93 16:28:59 PST Subject: Communications Policy Message-ID: <9301230027.AA13100@apple.com> >I hear concern over privacy and also over erasure of White House tapes. >I pose the following question: Should an institution have the right >to private communication? Is the White House an institution? A _private_ institution should have a right to private communications. The White House is _not_ a _private_ institution. -- Lefty (lefty at apple.com) C:.M:.C:., D:.O:.D:. From pfarrell at cs.gmu.edu Fri Jan 22 17:44:33 1993 From: pfarrell at cs.gmu.edu (Pat Farrell) Date: Fri, 22 Jan 93 17:44:33 PST Subject: public privacy, NSA resources Message-ID: <9301230140.AA12628@cs.gmu.edu> A fellow cypherpunk lister says about the number of employees at NSA: >40,000? Is this for real? Does anyone know how this would compare to >FBI or CIA? Also, does anyone have a clue on the black budget? The >author seems to hint here that while it is not "readily discernible" it >might be inferrable. > The number of employees at the FBI is public info. I don't have it at hand. CIA employment used to be secret, and may still be. Of course you can buy a picture from SPOT and count the cars for an estimate. At both agencies, there are a significant number of contract employees, who are not on the employment rolls, but are efectively the same as government employees. They aren't counted in public info. I can't guess at the number of NSA folks. But I can relate an story.... I gave a paper at this year's National Computer Security Conference, in Baltimore. Like all conferences, it had a registration area, vendor's booths, etc. Following form, it had nice folks behind counters with signs over the top, with the usual: Prepaid A-F | Prepaid G-M | .... | Walkup | Press | ... sections. What surprized me was the row of counters labeled: NSA A-E | NSA F-H | ..... NSA W-Z There were as many NSA booths as all the rest combined. (ok, +- 10%) Another aside. The NCSC is essentially a front for the NSA. NCSC exists but has no more than two employees, one is the secretary to an NSA official. Pat Pat Farrell, Grad Student pfarrell at cs.gmu.edu Department of Computer Science, George Mason University, Fairfax, VA PGP key available via finger or request #include standard.disclaimer From jpp at markv.com Fri Jan 22 20:01:10 1993 From: jpp at markv.com (Jay Prime Positive) Date: Fri, 22 Jan 93 20:01:10 PST Subject: An ebank's vulnerability. Message-ID: <9301221959.aa06199@hermix.markv.com> From: jpp at hermix To: cypherpunks at toad.com Subject: An ebank's vulnerability. I think that the physical location of an ebank's value reserve (be it gold, corn, stock certificates, whatever) is really the trickyest problem. At that location the bank can be attacked by governments (or other crooks). [enter fantasy... Person with gun says "Well, if all this money is your's, then you sure owe us taxes (protection). Don't pay and you're going to jail (to the bottom of the river). If it ain't your's, then (I'll just take it for myself) you're a bank, and you're going to jail." ...leave fantasy] One solution I see is to not have any physical deposit at all. This is what most governments do isn't it? But without a physical resource for reference the question of the value, or the origin of ecreds becomes tricky (at least for my limited economic knowledge). Suppose I create a really great joke and try to sell it. Where does the buyer get the ecreds from? If I wanted to buy a taco, would the vendor take ecreds? Would they take ecreds *I* printed up? Another solution is to use the banking system of a country which *ALREADY* has anonymous value storage as a comodity for sale. Supose some enterprising Swiss citizen wanted to set up ebanking, I bet they could do it. I wouldn't mind my ecreds being denominated in Swiss francs either. But I suspect the Swiss government might drop by the bank every year to collect some taxes from the accounts. At what tax rate would this become unacceptable? Someone could always set up an ungoverned value storage location. Smuggling gold (or other valuables) into, with in, and out of governed areas shouldn't cost too much, since valuables generaly have at least the value/weight and value/volume than marijuana has. The cost of smuggling, and defending the valuables becomes the limiting factor. How much could be "lost" to smuggling and defense befor this becomes unacceptable? j' From tcmay at netcom.com Fri Jan 22 21:04:06 1993 From: tcmay at netcom.com (Timothy C. May) Date: Fri, 22 Jan 93 21:04:06 PST Subject: crypto, NSA, gnu, and cypherpunks in Boardwatch magazine In-Reply-To: <9301221546.AA24473@soda.berkeley.edu> Message-ID: <9301230501.AA07629@netcom3.netcom.com> Eric Hughes passed along an article he got, which originally appeared in "Boardwatch": (lots of stuff elided) > FRONTAL ATTACK ON THE PUZZLE PALACE > by Lance Rose (and if you read all the way to the end...) > Those interested in cryptography issues may find a new Internet mailing list of > interest. A group is physically meeting in John Gilmore's Silicon Valley > facilities and has started a mailing list under moderation of Timothy C. May ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > (tcmay at netcom.com). The group includes John Draper (Cap'n Crunch), Tom > Jennings, and others interested in cryptography, anonymous mail forwarding > techniques, encryption, the Pretty Good Privacy program, and other privacy > issues. You can join this mailing list from any service allowing Internet > e-mail by sending a message to CYPHERPUNKS-REQUEST at TOAD.COM. > > [Lance Rose is an attorney practicing high-tech, computer and intellectual Needless to say to all of you, I don't moderate the list! Jeez, where do they get this stuff? I haven't talked to this guy, so I have no idea where he got this idea. Perhaps he thought my posts were more moderate than others? Obviously he never saw my "Crypto Anarchist Manifesto"! -- .......................................................................... Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay at netcom.com | anonymous networks, digital pseudonyms, zero 408-688-5409 | knowledge, reputations, information markets, W.A.S.T.E.: Aptos, CA | black markets, collapse of governments. Higher Power: 2^756839 | Public Key: waiting for the dust to settle. From marc at MIT.EDU Fri Jan 22 23:40:06 1993 From: marc at MIT.EDU (Marc Horowitz) Date: Fri, 22 Jan 93 23:40:06 PST Subject: perl scripts for PGP In-Reply-To: <9301221257.AA10121@cs.gmu.edu> Message-ID: <9301230738.AA01650@deathtongue.MIT.EDU> >> Marc, >> when you were here in DC, you mentioned some perl scripts that processed >> PGP output. Can you please send me a copy? yeah, and I'm cc'ing cypherpunks, since I think you all might be interested, too. This script has three functions. All take the output of pgp -kvv as input. 1) it "inverts" a pgp file, listing all the keys signed by a given key, as compared to giving all the keys which have signed a given key. 2) given -kvv output (and it can merge several files of input automatically, since it hashes on key id), it lists all the keys which you (or any other key) have a path of signatures to, and the length of the shortest such path. So, the specified key has a path length 0. All keys signed by that key have a path length 1, all keys signed by those keys have path length 2, etc. 3) Optionally, it will list one of these paths for each key you can reach. There may be many paths, so this is only for interest; to enumerate all paths would be painful. The most interesting use for this script is to see what your "radius" is (maximum distance to any key), and to see how big your "world" is. Needless to say, I wouldn't trust keys which have a long path length too much, if at all. There are 155 keys in my "world" (out of a keyring of about 350). My current radius is 7. Tom, if you're in Boston anytime, my radius would decrease to 5 if I signed your key. That would be cool :-) Marc #!/afs/athena/contrib/perl/perl # # $Id: pgputil.pl,v 1.7 1993/01/23 07:29:27 marc Exp $ # ## pgputil.pl. Copyright 1993, Marc Horowitz ## ## This program may be freely redistributed and used as long as the RCS ## Id, copyright, and this message are left intact. It may also be used ## as the basis for other programs, as long as this program is ## acknowledged in the code and documentation, and it is made clear that ## the new program is a derivative work, and not the original. Although ## not required, it would be nice if any modifications were sent back to ## me. $save = ""; sub next { local($ret); return() if !defined($save); while(1) { $_ = $save || <>; $save = ""; if (! $_) { undef $save; return($ret); } elsif (/^\s/) { $ret .= $_; } elsif ($ret) { $save = $_; return($ret); } else { $ret = $_; } } } sub parsekvv { local($keyid,$ring,$lastpub); while($_ = &next()) { if (/^Key ring:\s+'(.*)'$/) { $ring = $1; } elsif (m!^pub\s+\d+/([0-9A-F]+)\s+\d+/\d+/\d+\s+!) { $lastpub = $1; $publine{$lastpub} = $_; ($pubindent{$lastpub} = $_) =~ s!\d{4}/\d\d/\d\d!$& !; } elsif (/^sig\s+([0-9A-F]+)/) { $keyid = $1; $sigindent{$keyid} = $_; ($sigline{$keyid} = $_) =~ s/^(sig\s+[0-9A-F]{6})\s\s/$1/; $siglist{$keyid} .= $lastpub." " if $siglist{$keyid} !~ /$lastpub/; } } } sub findsigned { local($level, at from) = @_; local($tmp, at next); foreach $hash (@from) { next if (defined $depth{$hash}); $depth{$hash} = $level; for $nexth (split(' ',$siglist{$hash})) { push(@next,$nexth); $signedby{$nexth} = $hash if !defined $signedby{$nexth}; } } if (@next) { &findsigned($level+1, at next); } } ($zero = $0) =~ s!^.*/([^/]+)$!$1!; sub usage { die "usage: $zero signators [ file ... ]\n" ," $zero recurse [ -v ] [ file ... ]\n"; } sub signators { &parsekvv(); print "Type bits/keyID Date User ID\n"; foreach $hash (keys %siglist) { next if ($sigline{$hash} =~ /Unknown signator/); print $sigline{$hash}; foreach $pubhash (split(' ',$siglist{$hash})) { print $pubindent{$pubhash}; } } } sub recurse { for (@ARGV) { if (/^-v/) { $verbose++; } else { push(@newargv, $_); } } @ARGV = @newargv; $keyid = shift(@ARGV); if ($keyid !~ /^[0-9A-F]{6}$/) { &usage; } &parsekvv(); $signedby{$keyid} = ""; &findsigned(0, $keyid); foreach $pubhash (keys %depth) { $out{sprintf("%02d%s",$depth{$pubhash},$pubhash)} = sprintf("%2d %s",$depth{$pubhash},$publine{$pubhash}); } foreach $k (sort keys %out) { print $out{$k}; if ($verbose) { $sig = $signedby{substr($k,2,6)}; while($sig) { ($x = $pubindent{$sig}) =~ print " ",$x; $sig = $signedby{$sig}; } } } } ## dispatch $cmd = shift(@ARGV) || &usage(); if ($cmd =~ /^s/) { &signators(); } elsif ($cmd =~ /^r/) { &recurse(); } else { &usage(); } From IH23%UTEP.BITNET at ricevm1.rice.edu Sat Jan 23 13:21:37 1993 From: IH23%UTEP.BITNET at ricevm1.rice.edu (Juggler) Date: Sat, 23 Jan 93 13:21:37 PST Subject: No Subject Message-ID: <23JAN93.15495907.0008.MUSIC@UTEP> COuld you sub me to the cypherpunk list? Thanks. -Juggler -------------------------------------------- | Juggler | Insert cool | | IH23 at utep.BITNET | saying here. | | IH23 at utepvm.ep.utexas.edu|Long live sigs!| |******************************************| | Sysop of Three Ring Circus (915)564-0026 | -------------------------------------------- My school doesn't have opinions.... From deltorto at aol.com Sat Jan 23 13:27:32 1993 From: deltorto at aol.com (deltorto at aol.com) Date: Sat, 23 Jan 93 13:27:32 PST Subject: a few good weasels Message-ID: <9301231627.tn05014@aol.com> Eric.Fogleman at analog.com contributes his view that: >>I agree with Dave Deltorto's idea about "a body that decided on a case >>by case (or a class by class) basis what accounts would be subject to >>heavy scrutiny". Or perhaps limiting certain public servants (the >>chief executive, Oliver North's successor, etc) to a set of >>"open" computing systems and communication paths. (Similar to limiting >>people with security clearances to sets of closed computing systems, >>communication paths.) >> >>Dave says: >> >>> Unfortunately, this begins to create a overseeing body so >>> huge and convolute as to render the entire process unwieldly >>> approaching on the absurd. I read Kafka's "The Trial" and I don't >>> want to face that sort of Juggernaut any time soon. >> >>Unwieldy? Kafka-esque? Expensive? Possibly, but it doesn't have to >>be that way. As Bongo says: "The price of freedom is eternal >>vigilance." How much do you want to pay? Well, Eric, I take your point, and I'm willing to 'pay' quite a bit for freedom, especially if I have pals like you to help out in the biz of watchfulness. :-) I guess what I was trying to get at here was that the process could become so convolute that it would no longer be _technically feasible_ to keep an eye on the dangerous character(s) such as the President's National Security Advisor, the Joint Chiefs of Staff, the twisted geeks at the CIA, their cronies at the FBI, Hillary Clinton (whoops, she's probably OK) etc, etc, ad nauseam. This doesn't mean I wouldn't _like_ to make sure they're carefully monitored, I just look at the volume of paperwork/electronic files generated by even the most lowly federal agencies and imagine that such a watchdog agency might be logistically incapable of doing the job properly, assuming it could do it in an unobstructed and non-compromised way in the first place. There would have to be a highly selective, maybe viciously random way of keeping potential abusers in line. And who watches the watchdog? Kevin Costner? Speaking of which, has anyone seen this movie "A Few Good Men?" Jack Nicholson plays this meansumnabitch Marine Colonel who basically takes the law into his own hands, blinded by his self-righteous view of his job to protect "us" to the point where he has a young Marine murdered (Jack's great in this one, guys, go check out the bargain matinee). Now, I'm not saying that all government agents are that sick and perverse in the zealous pursuit of their goals, but I acknolwedge that such people can and probably do exist and that if we remain divided and unguarded, we all live at their mercy. I figure the only things that keep us safe at night are pure luck and the few government dudes who let a few details slip into the hands of say, the few crypto-anarchists who can balance things out. A world of absolutes is not a fun world and it's not a safe world. Someone's gotta break the rules every once in a while or we all go down the tubes. Of course, I _personally_ would _never_ break any of the fine laws of our beloved nation, but I know deep in my heart (but not anywhere on my hard disks) that such brave people exist and that the effect of their less-than-legal efforts is the delicate equilibrium in which we continue to prosper and innovate. I have more to say in this, but it's almost dawn and I have to flitter back to my coffin. dave From Eric.Forste at f33.n125.z1.FIDONET.ORG Sat Jan 23 14:49:39 1993 From: Eric.Forste at f33.n125.z1.FIDONET.ORG (Eric Forste) Date: Sat, 23 Jan 93 14:49:39 PST Subject: digicash fundamentals Message-ID: <4565.2B601C59@fidogate.FIDONET.ORG> I came into this discussion fairly late and most of what I've been able to read has been good stuff about anonymous remailers. However, there are many tantalizing bits dropped here and there about digital cash, including some recent discussion of a form that requires no encryption. However, I missed all the groundwork discussion on digicash, and I'd really like to understand the digital cash protocols more thoroughly. Can someone here please direct me to a text file with the basics of Chaum's digital-cash ideas presented in it? I am not a cryptographer, but I consider myself proficient in the use of PGP and I've read PGP's docs thoroughly and understand them, and have pretty good background in LAN communication protocols, so that's about the technical level I'm at. Thanks. -- Eric Forste - via FidoNet node 1:125/555 UUCP - ...!uunet!hoptoad!kumr!fidogate!33!Eric.Forste INTERNET - Eric.Forste at f33.n125.z1.FIDONET.ORG From ld231782 at longs.lance.colostate.edu Sat Jan 23 16:24:21 1993 From: ld231782 at longs.lance.colostate.edu (ld231782 at longs.lance.colostate.edu) Date: Sat, 23 Jan 93 16:24:21 PST Subject: public privacy, NSA resources In-Reply-To: <9301230140.AA12628@cs.gmu.edu> Message-ID: <9301240022.AA21591@longs.lance.colostate.edu> >Another aside. The NCSC is essentially a front for the NSA. >NCSC exists but has no more than two employees, one is the >secretary to an NSA official. Extremely interesting. What does NCSC stand for? I am doubtful of the 40,000 figure even with contract employees. That's a small army. What the hell could keep that many people busy? (shudder) Do you know much about MITRE? It has a high net profile and I was wondering if it is a cover for something else too. From jim at tadpole.com Sat Jan 23 16:53:57 1993 From: jim at tadpole.com (Jim Thompson) Date: Sat, 23 Jan 93 16:53:57 PST Subject: public privacy, NSA resources Message-ID: <9301240052.AA18559@tadpole.tadpole.com> > >Another aside. The NCSC is essentially a front for the NSA. > >NCSC exists but has no more than two employees, one is the > >secretary to an NSA official. > > Extremely interesting. What does NCSC stand for? tadpole 11 whois -h nic.ddn.mil ncsc.mil. National Computer Security Center (NCSC-DOM1) 9800 Savage Road Fort George G. Meade, MD 20755-6000 Fort Meade *is* the main NSA campus. docmaster.arpa (nee: docmaster.ncsc.mil) is one of the infamous Internet spook hangouts. :-) > I am doubtful of the 40,000 figure even with contract employees. That's > a small army. What the hell could keep that many people busy? (shudder) You should take a look at the campus sometime, its big. Lots of big-sheilded buildings. Lots of big satellite antennas. I have no trouble accepting the 40k figure, it is, after all a bureaucracy. Jim From ghsvax!hal at uunet.UU.NET Sat Jan 23 17:29:09 1993 From: ghsvax!hal at uunet.UU.NET (Hal Finney) Date: Sat, 23 Jan 93 17:29:09 PST Subject: Digital cash redux Message-ID: <9301240115.AA11642@nano.noname> Here is an excerpt from a description of one version of Chaum's digital cash, which I posted on Nov. 25: > There are lots of proposals for electronic cash in the literature, > mostly very complex. I think one of Chaum's simpler proposals would be > adequate for email "banking". This proposal, from the beginning of > his paper "Untraceable Electronic Cash" in Crypto 88(?), goes like > this: > > 1. Alice chooses a random x and r, and supplies the bank with > B=r^3*f(x) mod n, where f is a one-way function (like MD5), and n is > the modulus for the bank's public key. > > 2. The bank takes the third root of B (e.g. via an RSA decryption) and > sends it back to Alice: D = r * f(x)^(1/3), and withdraws one dollar from > her account. > > 3. Alice extracts C = f(x)^(1/3) by dividing D by r. (Note that > division can be done mod n without knowing the factors of n, but it's > rather complicated.) > > 4. To pay Bob one dollar, Alice gives him (x, C). > > 5. Bob can verify that C = f(x)^(1/3), but he still has to send (x, C) > to the bank in order to make sure that x hasn't been used before. > Otherwise Alice could spend (x, C) twice. The bank increases Bob's > account by one dollar. > > This scheme is pretty simple and provides untraceability - the bank > saw B and D but not C, so although it can verify that (x, C) is legit, > it can't correlate that with Alice's withdrawal. > > The main disadvantage of this approach is that Bob has to send (x, C) > to the bank right away (or at least before sending Alice anything in > return for her cash) to verify that the cash hasn't been used before. > But in email, where turnarounds of a day or more aren't unusual, this > should be tolerable. > > Alice and Bob could be pseudonyms, using anonymous addresses to > communicate with each other and with the bank. > > Different denominations of cash could correspond to different > exponents than "3" in the example above. (That is, $1 would use > C=f(x)^(1/3), $2 would use C=f(x)^(1/5), $4 would use C=f(x)^(1/7), > and so on.) > > Technically, this would be quite easy to implement, using the code in > PGP for the arithmetic, and MD5 for the one-way function. We'd need > to define a few message formats. The RFC1113 ascii encoding from PGP > could be used as well. > > The "social" problems are more challenging, it seems to me. What is > the backing for this electronic money? Why do people care what their > bank balances are? Is this stuff really worth anything? > > One possibility is to base digital cash on real money. People would > open a pseudonymous account via email, then postal-mail dollars to the > bank, enclosing their account number so the bank would know whom to > credit with the deposit. Later, if someone wanted to withdraw "real > money" from their account they would have to give a real postal > address where it could be mailed. Now the electronic money is worth > real dollars. Even if people didn't deposit or withdraw very often, > it still has value because of the backing. > > Unfortunately, this approach would currently be illegal (at least, > unless you actually were a real bank!). If there were some way the > bank itself could be anonymous, it might survive, but I don't see how > to mail it money while keeping the anonymity. Still, we could > consider experimenting with this on a small scale with accounts of no > more than a few dollars. As long as it was clearly an experiment I > doubt that any prosecutions would result even if it attracted > government attention, because the expense involved in court costs > would be so disproportionate to the few dollars involved in this > technically illegal act. > > Another approach would be not to try backing the digital cash at all, > or rather backing it implicitly by the determination of various people > to accept it and perform services or supply goods in return for it. > Tim's offer to Xerox papers in return for digital cash would be one > example. Perhaps others could provide some other services. It would > be great if some shareware author would accept digital cash as a > symbol of support for crypto anonymity. > > One problem that I see with this approach is how you determine the > size of the money supply. Or, in other words, how does new digital > cash get started circulating? How do people get new accounts, and how > much money is in them? > > If these problems can be solved, a big advantage of this approach is > that the banker can be anonymous. He would be known only by his > anonymous address and his public key(s). This would provide some > safety in the event that even a small-scale experiment like this > was targetted for a crackdown. > > Another issue is the prospect of multiple "banks", each issuing their > own (incompatible) cash. How would they compete? Perhaps in terms of > rapid turnaround? Some might choose to be anonymous, others would go > public. The latter would have the advantage that people might trust > them more, but OTOH there is more chance of your bank account > disappearing after a crackdown for a public bank than an anonymous > one. > > Lots to think about here! > > Hal > 74076.1041 at compuserve.com From david.brooks at cutting.hou.tx.us Sat Jan 23 18:33:50 1993 From: david.brooks at cutting.hou.tx.us (David Brooks) Date: Sat, 23 Jan 93 18:33:50 PST Subject: PGP on BBS Message-ID: <10496.143.uupcb@cutting.hou.tx.us> David Brooks writes: DB> > I have been mulling over the idea of a BBS door which allows users DB> to DB> >send PGP encrypted messages to other users using a system pubkey file. DB> >I don't see a way to do it without the sender having to transfer (at DB> least DB> >temporarily) his secret key to the host system. Karl L. Barrus responds: KLB> Well, you could always allow the users to download the public key file KLB> and do the encryption on their home machine, and then upload the mail KLB> file. KLB> That way their secret key stays off the BBS... Well, yeah, that's the way we do it now, use the BBS as a Public Key Certification office...) I was sort of hoping for something a bit more direct... David david.brooks at cutting.hou.tx.us * Q-Blue v0.7 [NR] * ---- +---------------------------------------------------------------------+ | The Cutting Edge BBS (cutting.hou.tx.us) A PCBoard 14.5a system | | Houston, Texas, USA +1 713 466 1525 running uuPCB | +---------------------------------------------------------------------+ From david.brooks at cutting.hou.tx.us Sat Jan 23 18:34:09 1993 From: david.brooks at cutting.hou.tx.us (David Brooks) Date: Sat, 23 Jan 93 18:34:09 PST Subject: PGP on BBS Message-ID: <10497.143.uupcb@cutting.hou.tx.us> Eric Hughes speaks: EH> The solution is cooperative processing systems, where both the host EH> and the terminal cooperate to perform some task. Unfortunately, there EH> is precious little software infrastructure to support such a EH> development. Terminal programs on PC's are still for the most part EH> acting as dumb terminals, with the notable exception of file transfer EH> protocols such as zmodem. EH> I believe that cooperative communication software will be necessary EH> for widespread use of cryptography--not just pleasant, but a EH> precondition to large scale deployment. You've hit the nail on the head here, Eric. If public key encryption is REALLY going to be for the masses, we are going to need something like this... But it seems I'm going to have to code the damned thing myself, eh? Anyone want to help? EH> Onward. Indeed! David david.brooks at cutting.hou.tx.us * Q-Blue v0.7 [NR] * ---- +---------------------------------------------------------------------+ | The Cutting Edge BBS (cutting.hou.tx.us) A PCBoard 14.5a system | | Houston, Texas, USA +1 713 466 1525 running uuPCB | +---------------------------------------------------------------------+ From 74076.1041 at CompuServe.COM Sat Jan 23 21:23:07 1993 From: 74076.1041 at CompuServe.COM (Hal) Date: Sat, 23 Jan 93 21:23:07 PST Subject: Re. PGP on BBS Message-ID: <930124051435_74076.1041_DHJ67-1@CompuServe.COM> One thing I didn't follow about this was the supposed need to put the private key onto the BBS in order to send encrypted mail. This is not necessary. The private key is only used for signing messages. For privacy purposes in many cases encryption is sufficient. PGP could be run on the BBS to do encryption. Of course, the local sysop could see your message as you compose it or upload it to the BBS, but if you're then sending it through a BBS network it can travel privately. Hal 74076.1041 at compuserve.com From phiber at eff.org Sat Jan 23 21:55:16 1993 From: phiber at eff.org (Phiber Optik) Date: Sat, 23 Jan 93 21:55:16 PST Subject: This list... Message-ID: <199301240554.AA16927@eff.org> I'm not one to overlook the obvious. Is it desireable that any Tom, Dick, or Harry can telnet to toad's SMTP port, and use the sendmail expand command to list everyone on this mailing list? I'm sure less net-savvy users on this list are unaware, and it should be said. From marc at Athena.MIT.EDU Sat Jan 23 22:58:53 1993 From: marc at Athena.MIT.EDU (Marc Horowitz) Date: Sat, 23 Jan 93 22:58:53 PST Subject: PGP on BBS In-Reply-To: <10497.143.uupcb@cutting.hou.tx.us> Message-ID: <9301240657.AA14069@m16-034-15.MIT.EDU> What you are all talking about here is a solved problem. Many such network protocols exist. SLIP is probably the best example. If you use SLIP to connect to the BBS instead of a dumb terminal connection, you get a real network link which supports multiple connections to multiple destinations. And free SLIP implementations exist. The author of one of the most popular is on this list, in fact. Of course, this requires that your "terminal" be somewhat intelligent, but even a lowly 8088 PC running DOS can run SLIP. If you do this, all you need is a BBS which supports network services, instead of the current menu-based sort of systems we have now. If you want to encrypt, you do so locally. In fact, you'd probably do almost everything locally. Marc From pfarrell at cs.gmu.edu Sun Jan 24 10:00:14 1993 From: pfarrell at cs.gmu.edu (Pat Farrell) Date: Sun, 24 Jan 93 10:00:14 PST Subject: NUpop is the answer was Re: PGP on BBS Message-ID: <9301241756.AA14778@cs.gmu.edu> I don't know if the sources are available, NorthWestern's NUpop is the key to making PGP acceptable to masses of not-very-computer-literate users. Ask archie for nupop103.zip NUpop is a PC (MS-DOS) program that uses the PC as a computer. It uses SMTP to send mail and receives mail via POP. It works on networks and thru dialup. It works with SLIP and more simply over a reliable ASCII connection. It is a great program. CUA, mouse, folders, auto sigs, etc. All it needs is to have a "encryption outgoing" flag in its "group" (alias) directory, and pump the message thru PGP in filter mode. On receipt, find the PGP headers, push thru the filter, and show the clear text. I haven't looked for either the PGP or NUpop sources, but I'd expect this to be a near trivial hack. It may even be already done. NUpop (and its Mac equivalent Eudora) are the right way to get users on the net. Using a PC as a VT100 to login to a full blown Unix system, using vi to edit mail, etc. is near criminal. NUpop makes it easy enuff for econ profs. (Seriously, I set up NUpop for an econ prof here last weekend. He loves it. He is definitely not a Unix wizard.) If NUpop source is not available, then we'll have to reverse engineer something similar. I've learned how NUpop does the communications, and it is straight-forward (also in the RFCs if you care to look) I thought about doing a Windows-only program, but wonder if we really have to support diehard DOS users on ATs and less. I've been meaning to ask about source availablity. I'll do so now, and probably have an answer tomorrow. Pat Farrell, Grad Student pfarrell at cs.gmu.edu Department of Computer Science, George Mason University, Fairfax, VA PGP key available via finger or request #include standard.disclaimer Write PKP. Offer money for a personal use license for RSA. From pfarrell at cs.gmu.edu Sun Jan 24 11:40:23 1993 From: pfarrell at cs.gmu.edu (Pat Farrell) Date: Sun, 24 Jan 93 11:40:23 PST Subject: Rational PC mail , was Re: PGP on BBS Message-ID: <9301241935.AA14956@cs.gmu.edu> Marc at mit.edu writes: > >What you are all talking about here is a solved problem. Many such >network protocols exist. SLIP is probably the best example. If you >use SLIP to connect to the BBS instead of a dumb terminal connection, >you get a real network link which supports multiple connections to >multiple destinations. And free SLIP implementations exist. The >author of one of the most popular is on this list, in fact. It is a solved problem. It doesn't even require SLIP. I spent lots of hours over the past year trying to get SLIP to work with the GMU computers. it is officially "not supported" With NUpop and Eudora, SLIP is optional. The NUpop docs say that SLIP slows down the transfer, and recommends simple ASCII async connection using a reliable modem (MNP or V42/V.42bis) >Of course, this requires that your "terminal" be somewhat intelligent, >but even a lowly 8088 PC running DOS can run SLIP. > >If you do this, all you need is a BBS which supports network services, >instead of the current menu-based sort of systems we have now. If you >want to encrypt, you do so locally. In fact, you'd probably do almost >everything locally. Using a computer as a computer is clearly the way to go. There are a number of low-cost or free Unix providers, I expect that they do, or can be talked into supporting POP. I expect that current terminal/menu based BBSes will disapear once folks realize how much better easier, faster, and all around better programs that use computers as computers work. Pat Pat Farrell, Grad Student pfarrell at cs.gmu.edu Department of Computer Science, George Mason University, Fairfax, VA PGP key available via finger or request #include standard.disclaimer From tcmay at netcom.com Sun Jan 24 12:25:25 1993 From: tcmay at netcom.com (Timothy C. May) Date: Sun, 24 Jan 93 12:25:25 PST Subject: public privacy, NSA resources In-Reply-To: <9301240022.AA21591@longs.lance.colostate.edu> Message-ID: <9301242022.AA12398@netcom3.netcom.com> someone with a long net address, included in the "To:" field, writes: (quoting someone else) > >Another aside. The NCSC is essentially a front for the NSA. > >NCSC exists but has no more than two employees, one is the > >secretary to an NSA official. > > Extremely interesting. What does NCSC stand for? National Computer Security Center. Send a letter requesting to be added to the distribution list of the "Orange Book"-related materials (frequent updates to a set of guidelines on computer security protocols, the most famous being one with an orange cover, hence the name), and you will start receiving a lot of stuff from them. The address: The INFOSEC Awareness Office can be reached at: Department of Defense National Security Agency ATTN: S332 9800 Savage Road Ft. George Meade, MD 20755-6000 or phone 301-766-8729 (these are the numbers I used a couple of years ago...your mileage may vary.) > I am doubtful of the 40,000 figure even with contract employees. That's > a small army. What the hell could keep that many people busy? (shudder) NSA occupies two very large office buildings, including the longest corridor in the world (a mile, if I recall correctly, but my copy of "The Puzzle Palace" is not handy). I went and took a look, and can confirm the parking lot is _huge_. The 40,000 figure may or may not be accurate, as the NSA won't say. Some say the employment is closer to 100,000. Certainly it is much higher than that of the CIA. Bear in mind that they are the nation's primary SIGINT facility, operating the various listening posts in conjunction with military personnel (via Army Security Agency, Naval Security Group, Air Forc, etc.). As always, read James Bamford's "The Puzzle Palace," which gets referred to a lot on this list. > Do you know much about MITRE? It has a high net profile and I was > wondering if it is a cover for something else too. MITRE, derived from "MIT REsearch," is one of several defense-oriented think tanks, the others being RAND Corporation ("R & D," not Ayn Rand!), Institute for Defense Analysis (IDA), etc. The Communications Research Division of IDA, located at Princeton, was formed in 1956 to help the NSA. Lots of famous mathematicians, including Barkley Rosser, Andrew Gleason, and others. This shadowy world of defense think tanks is a subject unto itself. -- .......................................................................... Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay at netcom.com | anonymous networks, digital pseudonyms, zero 408-688-5409 | knowledge, reputations, information markets, W.A.S.T.E.: Aptos, CA | black markets, collapse of governments. Higher Power: 2^756839 | Public Key: waiting for the dust to settle. From ASTMWILL%STETSON.bitnet at CUNYVM.CUNY.EDU Sun Jan 24 13:32:05 1993 From: ASTMWILL%STETSON.bitnet at CUNYVM.CUNY.EDU (Matt Willis) Date: Sun, 24 Jan 93 13:32:05 PST Subject: Neuvo-Crypto Message-ID: <01GTWJC6AX9S0000HM@stetson.bitnet> I'm researching fractals here at glorious Stetson University and it crossed my mind that there are possibilities in the combination of fractals with current encryption standards... for instance, using a piece of the mandelbrot set as a key or a Julia set with a standard center and radius, thereby reducing a key to a sort of x,y,z,F() coordinate... And if you and a friend established a standard equation... that would make it a sort of three-key system. On a simpler level, couldn't the RSA method be converted to use the Complex number system... (which is the base of fractal mathematics) Anyone follow? +-------Matt-Willis--------------------------------+ | Matt Willis ASTMWILL at STETSON.BITNET | elsewhere: | Matt Willis Head of the Underground | mwill at mindvox.phantom.com | Matt Willis Robotech PBM List | +-------Matt-Willis--------------------------------+ "Absolutely alone in awareness of the mechanism." -Agrippa by WG From avalon at coombs.anu.edu.au Sun Jan 24 16:08:48 1993 From: avalon at coombs.anu.edu.au (Darren Reed) Date: Sun, 24 Jan 93 16:08:48 PST Subject: no subject (file transmission) (fwd) Message-ID: <9301250007.AA00793@coombs.anu.edu.au> CFP'93 The Third Conference on Computers, Freedom and Privacy 9-12 March 1993 San Francisco Airport Marriott Hotel, Burlingame, CA The CFP'93 will assemble experts, advocates and interested people from a broad spectrum of disciplines and backgrounds in a balanced public forum to address the impact of computer and telecommunications technologies on freedom and privacy in society. Participants will include people from the fields of computer science, law, business, research, information, library science, health, public policy, government, law enforcement, public advocacy and many others. Some of the topics in the wide-ranging CFP'93 program will include: ELECTRONIC DEMOCRACY - looking at how computers and networks are changing democratic institutions and processes. ELECTRONIC VOTING - addressing the security, reliability, practicality and legality of automated vote tallying systems and their increasing use. CENSORSHIP AND FREE SPEECH ON THE NET - discussing the problems of maintaining freedom of electronic speech across communities and cultures. PORTRAIT OF THE ARTIST ON THE NET - probing the problems and potential of new forms of artistic expression enabled by computers and networks. DIGITAL TELEPHONY AND CRYPTOGRAPHY - debating the ability of technology to protect the privacy of personal communications versus the needs of law enforcement and government agencies to tap in. HEALTH RECORDS AND CONFIDENTIALITY - examining the threats to the privacy of medical records as health care reform moves towards increasing automation. THE MANY FACES OF PRIVACY - evaluating the benefits and costs of the use of personal information by business and government. THE DIGITAL INDIVIDUAL - exploring the increasing capabilities of technology to track and profile us. GENDER ISSUES IN COMPUTING AND TELECOMMUNICATIONS - reviewing the issues surrounding gender and online interaction. THE HAND THAT WIELDS THE GAVEL - a moot court dealing with legal liability, responsibility, security and ethics of computer and network use. THE POWER, POLITICS AND PROMISE OF INTERNETWORKING - covering the development of networking infrastructures, domestically and worldwide. INTERNATIONAL DATA FLOW - analyzing the issues in the flow of information over the global matrix of computer networks and attempts to regulate it. The conference will also offer a number of in-depth tutorials on subjects including: * Information use in the private sector * Constitutional law and civil liberties * Investigating telecom fraud * Practical data inferencing * Privacy in the public and private workplace * Legal issues for sysops * Access to government information * Navigating the Internet INFORMATION For more information on the CFP'93 program and advance registration call, write or email to: CFP'93 INFORMATION 2210 SIXTH STREET BERKELEY, CA 94710 (510) 845-1350 cfp93 at well.sf.ca.us A complete electronic version of the conference brochure with more detailed descriptions of the sessions, tutorials, and registration information is also available via anonymous ftp from sail.stanford.edu in the file: /pub/les/cfp-93 or from sunnyside.com in the file: /cfp93/cfp93-brochure or via email from listserv at sunnyside.com by sending email with this text: GET CFP93 CFP93-BROCHURE From nowhere at bsu-cs.bsu.edu Sun Jan 24 19:12:03 1993 From: nowhere at bsu-cs.bsu.edu (Chael Hall) Date: Sun, 24 Jan 93 19:12:03 PST Subject: Rational PC mail , was Re: PGP on BBS In-Reply-To: <9301241935.AA14956@cs.gmu.edu> Message-ID: <9301250307.AA18287@bsu-cs.bsu.edu> >Using a computer as a computer is clearly the way to go. There >are a number of low-cost or free Unix providers, I expect that >they do, or can be talked into supporting POP. I agree that it's the best way to go, but as you will see below it's not (IMHO) what's best for everyone. >I expect that current terminal/menu based BBSes will disapear >once folks realize how much better easier, faster, and all >around better programs that use computers as computers work. I think a wide variety of services need to be provided in order to allow each person to use computer systems in their own way. For example, the following are all popular types of systems that each have a large following: CompuServe, Prodigy, GEnie, etc. Bulletin Board Systems (dial-up, non-Internet related) VMS UNIX If BBSes were eliminated in the long run, many users would have to learn the more difficult UNIX or resort to CI$ et al or VMS. I personally use BBSes, UNIX, and VMS (in no particular order) and enjoy each for its special abilities. BBSes are a totally different environment than UNIX, thus I think they will stick around for quite a while. They allow the sysadm to provide much more personality and creativity than UNIX with very little knowledge of the underlying operating system by comparison. Chael Hall -- Chael Hall nowhere at bsu-cs.bsu.edu, 00CCHALL at LEO.BSUVC.BSU.EDU, CHALL at CLSV.Charon.BSU.Edu (317) 285-3648 after 4 pm EST From mark at Panix.Com Sun Jan 24 20:33:57 1993 From: mark at Panix.Com (Phiber Optik) Date: Sun, 24 Jan 93 20:33:57 PST Subject: e-mail... Message-ID: <199301250432.AA07927@sun.Panix.Com> To the genius (Matthew Sean Pardo, mpaf1216 at pelham.med.unc.edu), who thought he was being clever by sending what he thought was "anonymous" mail to me (by telnetting to port 25), you missed my point. There's no need for the EXPN command to be used remotely. I can only suggest that John Gilmore disable it at toad, though it probably doesn't matter anymore. If anonymity and privacy are as key as people are making them out to be on this list, I find it ironic that privacy is lacking on such a simple level. From marc at MIT.EDU Sun Jan 24 21:12:41 1993 From: marc at MIT.EDU (Marc Horowitz) Date: Sun, 24 Jan 93 21:12:41 PST Subject: signature trades Message-ID: <9301250511.AA09784@deathtongue.MIT.EDU> I'm going to be in New York City on Wednesday, January 27. I'll be available in the evening if people want to get together somewhere and trade signatures face-to-face. I know some people on this list are in that area. Email me personally; I'll coordinate and send mail to everyone who expresses an interest. If you have a good idea for a place to meet, please make a suggestion, since I don't know all that many places to meet. Marc PGP key in case you want to encrypt: -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.1 mQBNAirbf1kAAAEB/jCF0mjoZe7YYWpSxOJFlfr6F+39KvuL0k5DptL4A0C95Pqh dpkbGbD3kolxy469SyQiB6Xlx2V5zIvlrIy0uVEABRG0HE1hcmMgSG9yb3dpdHog PG1hcmNAbWl0LmVkdT6JAI0CBRArV5t3QvCl/Jcp1JsBAW75A79O9ZXpSCIAlk/V bVmdFJ2uXBpmJj1KdP8FInk+6zTwFSVjphtZ8WCGo0U8UPP509zeOpk9Pd+0FVv0 9j9vnJcFjCrXJq4rbxCimFpqpXZaMsF4AQ0ry6wi7MdhOZXrkTTEsKRo1MPhAQg6 yUFb95nKrl1Ub5STZ7OJAJUCBRArV5thVN1fojxmJGcBAZKzA/9gobjB0g2ECwhO wZweiGu0oivh2u++njPW5VgLtHgqLU4blTew1YdOgIe053pifdEblTBnXPri8vDs 0GBoPjXNlhPz/l/JZvhaPYnAPpJ2Q3sE8La4pcs1o5UTlKmOE8rtu8fIMB6Lz5gC v6jo0KhRQpcGepkJGEk8gdKzdmVY2okAVQIFECsztFcfWxp2jm/yjQEBDwoCAINK AcYmW1lm4F5T/pegjD+CZHyrlGDwDGRKOMMbLhBuZbxbBlQsFGO5bcviiJSMyLIE UUQcbDUC+uKU6zpIEhSJAJYCBRArKWOyr3CNl7EvuMEBAeaWBAICCWysNgLatvry zPnAxZICFQP4Qwm8JuP5x/uguyqDEnpnD6g+iZEV6NKsL8Z09XAec2/8KAg7yKYu it8oQe8/yMJH26Iv1BLCjXN6kgFkeCt3usezBH22/yBQ6vsU9KMIRCfx30XD9MpV jUle75y3B8IN0vEQVPGQSs7KBJKeowKJAJUCBRArFJoTpsOAT/N2gT0BAQrYA/0c BKMxFlvQMacpPR2/O7ZNlJhRoTp8q3mQNl5fW2+gY6uOEfR3Q5OmgR/HQOQmx01+ PmmqrCpeDYE4hNZN+KnHw8OQlTwe7RCtNisl+0HcSxweprbSJgVEUAWMCLwkg3bF 2NP9kXO+btZBFXtaF2FFHu7Sd11Ud4qllY6eix95TIkAdQIFECruHvx1Eb4Sc5bT twEBTXsC/i3l36A4j5OwBsTUBOcRCCZaGtwOMVR/Gf1LKkzbDQK4MMbKWeNCeDrr p9WMad2sPzgn3qb1xPxW2TJs7KPzaKY/44NJNRTaUedNTok1/g+JECl8kO5hlcxF 5GBIpasyc4kAlQIFECsMey1cv+w5Zs6JtwEB+VAD/ReV12oKmYPDGoYdmi18EZ6E bBF67LlQYVzeTAj1gX+QZOI8cqsHeiKTpY2UUSaTVtmXD8bzKW7RQrlK4eT5YPBS 9UF4czyhYh3ZVcVQzjDRLP29x0+yUX7o0l9VhMO9JMNaTlsfuwZoNY6gabHN7bMu JdyB9JC41CU82xw2zAGEiQBVAgUQKwx5YQeIzKyfnzi7AQH2cwH/cpWg2vHeJJL4 ZzFDg/+3ijvxjHDQCmvF9F2SjEX9IVAeBAy+AShkcD+adce0nLxdKCYBWYPb0xtZ iI3PFgDPa4kAlQIFECsKculuC7y+W0FWIQEBAU0D/0uhXjhGgHP0P3Bjq8onmN7H goLQHjZML0kzinLzGsa7tWJzNafEDnEsxZX1XrTeV6JEsf31T7EN09vSHtcJEjSy IyTHIWnXqgTnvoBmBQNSzEIDF1XVUdTa95SG8HU0os98exo64hutBCP8yVihe/1J PpGBtEMQWuh1UbAP1iWxiQBuAgUQKtxRRDh0K1zBsGrxAQE2UwLFF7GJeCwfBJg4 ILXqll0zRmLnBIx42RG5fJwHs5m/uZt8qp7qYXK0D6pqgtypFJavdfVGbC+A4Dhh Vw7WKjSQRuXrvhd5Yje+qal6aEpTOD+zDaOZxccTosmJAFUCBRAq24DnVQVm+k0M TuEBAflaAf9M33fLLs1VFZLjDAZWQzkFMl5toykd32uRQBW55REMIRWO1A+mQBmn IcOHC7RL9wdWwmKGkC0YxFGnCRRdSZi0iQBVAgUQKtuCsMyL5ayMtLlRAQF8nAH9 GVgelMbV7O1oUqop644DSoeoGHgWU2koqshXLta/55dx43Lw9o1PVY90Oap+oCVs Ys0xE5TlSQOc4GGJP/HtoQ== =37CN -----END PGP PUBLIC KEY BLOCK----- From pmetzger at shearson.com Mon Jan 25 12:20:09 1993 From: pmetzger at shearson.com (Perry E. Metzger) Date: Mon, 25 Jan 93 12:20:09 PST Subject: This list... In-Reply-To: <199301240554.AA16927@eff.org> Message-ID: <9301251834.AA07145@maggie.shearson.com> >From: Phiber Optik >I'm not one to overlook the obvious. Is it desireable that any Tom, Dick, or >Harry can telnet to toad's SMTP port, and use the sendmail expand command to >list everyone on this mailing list? Welcome to TCP/IP. You've told us what most of us already know. (By the way, its the SMTP EXPN command, not the "sendmail" one, as sendmail is just one MTA -- there are many other implementations). The whole point of this list is to develop techniques to ensure privacy -- most of us understand that there isn't much right now. Perry From mjr at netcom.com Mon Jan 25 12:34:55 1993 From: mjr at netcom.com (Matthew Rapaport) Date: Mon, 25 Jan 93 12:34:55 PST Subject: Coupled programs and security by obfuscation Message-ID: <9301252034.AA21595@netcom2.netcom.com> **** Pat Farrel writes >I expect that current terminal/menu based BBSes will disapear >once folks realize how much better easier, faster, and all >around better programs that use computers as computers work. I hope not... At least not until the BBS operators and writers agree on some standardized API so people like me and other third parties can write PC based interfaces in a language of our choice. The problem with current "coupled systems" (for example the Coconet BBS software) is that they all rely on proprietary interface programs on the PC. If I communicate with 10 BBS systems (large or small), I must have 10 different communications programs... No thanks... Also keep in mind that much of the value of these systems comes from their availability to the widest possible audience. There are people in many parts of the world who still have nothing better then 1970's style glass tty's and even paper-output type terminals! ****** Back on the issue of privacy and anonymity, I don't understand the lure of all these schemes for hiding mail paths, etc. If encrypted messages pass through one aliaser, and get decrypted (and aliased again) on another machine, you are protected. The machine that knows who you are can't read your material, and the machine that can read you doesn't know who you are. Any further obfuscation adds little (IMHO) to your security. Revelation of your identity (in either case) depends on collusion between system administrators on the different hosts. True this might be even less likely where 3 or more hosts are involved, but how much less so? If some agency is powerful enough to force two systems in different parts of the world (and the net) to reveal what they know about you, the chances are they can force three or four, etc. matthew rapaport Philosopher/Programmer At Large KD6KVH mjr at netcom.com 70371.255 at compuserve.com From honey at put-in-bay.citi.umich.edu Mon Jan 25 12:43:13 1993 From: honey at put-in-bay.citi.umich.edu (peter honeyman) Date: Mon, 25 Jan 93 12:43:13 PST Subject: This list... In-Reply-To: <9301251834.AA07145@maggie.shearson.com> Message-ID: <9301252043.AA20045@toad.com> > The whole point of this list is to develop techniques to ensure privacy -- > most of us understand that there isn't much right now. but but but ... sendmail already offers an easy way to hide the membership of a mailing list. why not use it? peter From ld231782 at longs.lance.colostate.edu Mon Jan 25 13:20:00 1993 From: ld231782 at longs.lance.colostate.edu (ld231782 at longs.lance.colostate.edu) Date: Mon, 25 Jan 93 13:20:00 PST Subject: anonymous server compilation? Message-ID: <9301252119.AA27366@longs.lance.colostate.edu> Hello. To my knowledge no public listing of known anonymous servers has been compiled. I'd like to start one. This could possibly turn into a FAQ if response is good. I will put in this newbie-type introductory information at the end of this document for review. Please help me improve this by sending constructive/informative feedback, esp. sections flagged with (?). This all is very weak right now but with your help it could become very thorough and valuable. pax.tpa.com.au -------------- The most sophisticated anonymous posting system to my knowledge. Uses public key encryption for traffic in both ways (to/from) the server. No anonymous remailing capabilities yet but dclunie at pax.tpa.com.au, the administrator, says he's considering it. Had a serious bug recently fixed that caused a reassignment of previously allocated anonymous addresses. Located in Australia. anon.post.g at pax.tpa.com.au for anonymous USENET posting where `g' is the group anon.info at pax.tpa.com.au for information anon.subscribe at pax.tpa.com.au to subscribe to the mailing list acs at n7kbt.rain.com ------------------ no info (?). given to me by dclunie at pax.tpa.com.au godiva.nectar.cs.cmu.ed ----------------------- operated by Karl_Kleinpaste at cs.cmu.edu. Mentioned by julf at penet.fi in an introductory information. This person has posted code to alt.sources that implements anonymous server capabilities. (?) anon.penet.fi ------------- operated by julf at penet.fi. Both anonymous posting and remailing capabilities. (?) hh at pmantis.berkeley.edu ----------------------- no info (?). given to me by tcmay at netcom.com Anonymity and Identity on the Internet ====================================== Generally, identity is amorphous and almost nonexistent on the Internet for a variety of reasons. One is the inherent fluidity of "cyberspace" where people emerge and submerge frequently, and absences are not readily noted in the "community". You currently do not really have any great assurance that the messages you get in mail and the messages you see on USENET are from the people they appear to be from, nor do others have of you. Be careful not to be led astray; gullibility is perhaps the greatest crime here, and skepticism the most useful virtue. Neither are there currently good assurances of privacy in your personal email, and cases where it has been compromised are not uncommon. New encryption technologies are slowly gaining acceptance and penetration into systems that make possible digital encryption and authentication that will make the systems more trustworthy. These can also protect your identity and privacy by offering anonymous posting and mailing capabilities. USENET USENET is a worldwide decentralized news distribution system, adhering to Internet standards described in RFC977 (?). MAIL The characters that you are reading are almost certainly encoded in ASCII, the American Standard Code for Information Interchange that maps alphabetic and symbolic characters onto numeric codes and vice versa. Virtually every computer system uses this code, and if not, has ways of converting to and from it. When you write a mail message, it is being sent in ASCII, and since the standard is virtually universal, there is no intrinsic privacy. Anyone with access to hardware involved in forwarding the message can theoretically read it. Internet mail standards, described in RFC (?), are still evolving rapidly and not entirely orderly. For example, standards for mail address `munging' or `parsing' tend to vary slightly between sites and frequently mean the difference between finding addresses and bouncing mail. New standards are calling for uniform introduction of "privacy enhanced mail" (PEM) which uses encryption technologies to ensure privacy. The current internet mailing protocol is slightly anachronistic in that it was created when the system was somewhat obscure and not widespread, with only a fraction of the traffic it now sees. Today about (?) of internet traffic is mail, comprising about (?) messages. (Source: (?)) A person's mailing address is far from an identification of an individual. First, anyone with access to the account, e.g. they know the password, either legitimately or otherwise, can send mail with that address in the From: line. Secondly, as part of current mailing protocol standards, forging the From: line is a fairly trivial operation for many hackers. Much less forgable is the status and path information prepended to messages by intermediate hosts. Note that bounced messages go to postmasters at a given site in their entirety. This means that if you address mail with an incorrect address it has a good chance of being seen by a human other than the recipient. Theoretically people at any site in the chain of sites that forwards a given mail message over the Internet (about a half-dozen (?) on average, depending on the distances) could potentially compromise the privacy of that message and read it. In practice, this appears to be rare or unheard of. Something more common is instances of immature and unscrupulous system operators reading private mail at a local site, such as a university. The requirements and screening for getting a system administration job (and access to *all* information on a system) vary widely between sites and are sometimes frighteningly lax. ANONYMOUS MAILING ----------------- Some people find it useful to send anonymous mail to others. Examples of this include (?). Here the distinction should be made between sort of "hit and run" mail, where the sender does not want to carry on any further communication, and anonymized mail, where the recipient can respond but has no idea of the sender or origination of a message. The servers listed above allow for the latter type of communication. The former type is now largely confined to hackers who find it convenient for scurrilous threats or whatever, but probably has legitimate uses as well (?). Another category is people who want to appear to have regular but not traceable appearances, i.e. the userid and site origination do not obviously flag their mail as anonymous. Unfortunately, no set of standards is in place to handle the procedures for anonymous posting. Typically the approach is to set up an "anonymous server" that, when activated by email to its address, responds by allocating and supplying an "anonymous ID" that is unique to the person requesting it (based on his email address). This will vary for the same person for different machine address email originations. To send anonymous mail, the user sends email directed to the server containing the final destination. The server "anonymizes" the message by stripping of identification information and forwards the message, which appears to originate from the anonymous server only from the corresponding anonymous user id. From pmetzger at shearson.com Mon Jan 25 14:17:36 1993 From: pmetzger at shearson.com (Perry E. Metzger) Date: Mon, 25 Jan 93 14:17:36 PST Subject: This list... In-Reply-To: <9301252040.AA26396@uu5.psi.com> Message-ID: <9301252142.AA12706@maggie.shearson.com> >From: peter honeyman >> The whole point of this list is to develop techniques to ensure privacy -- >> most of us understand that there isn't much right now. >but but but ... sendmail already offers an easy way to hide the membership >of a mailing list. why not use it? Prehaps that would be of value, but its best not to think of it as worth too much. After all, the bad guys can likely just subscribe to the list, and they could always just eavesdrop on the outgoing mail. Fixing this "hole" is o.k. so long as no one believes that it has actually added to security in any substantial way. Its best that no false sense of security be engendered. Everyone should know and understand that the structures as they exist are almost completely insecure. Perry From edgar at spectrx.Saigon.COM Mon Jan 25 14:58:27 1993 From: edgar at spectrx.Saigon.COM (Edgar W. Swank) Date: Mon, 25 Jan 93 14:58:27 PST Subject: public servant privacy Message-ID: My friend Dave del Torto said recently: Tim May notes (appropriately) that: >>Strong crypto means even Ollie North can fully protect his >>records. Yes, but shouldn't he be _required_ to "open" his files if he is under criminal investigation just like a drug-dealer who's required to open the locked trunk of his car? Actually, the drug dealer is *not* required to open his locked car trunk. But he might as well, otherwise the police (with search warrent) will force it open, probably causing some damage which they will not pay to repair. There doesn't seem to be any practical way to "force open" a (strongly) encrypted message without the key. Failure to produce the key when ordered might be an excuse for firing a govt. employee, but it can't be the basis for a criminal prosecution (5th Amendment). "Murdering Thug" further commented: Well, there are really two conflicting issues here: 1) The Fifth Amendment - the right not to testify against yourself, hence the Miranda warning when you're arrested. You can claim that being forced to decrypt your hard disk by the cops violates your Fifth Amendment rights, and refuse to decrypt it. 2) Obstruction of Justice - by not handing over the key to your hard disk, you may be obstructing an investigation. By not decrypting your hard disk under court order, you maybe be held in contempt of court. Number 2 may work for law enforcement if they are investigation a third party and ask to see your hard disk in order to help their investigation. A good example is an Internet site that is being used as a telnet launch-pad by some hacker. If that site refuses to cooperate and keeps their files encrypted, the police/court may charge you with obstruction of justice or contempt of court. HOWEVER, if you feel that by decrypting these files, you would be providing testimony/evidence against yourself, you can plead the 5th, and tell them to go screw themselves. Pleading the 5th will fail if you are offered *immunity* from prosecution for anything you reveal (as Ollie North was, recall, for his testimony before Congress). If you still don't want to testify (to avoid providing damaging evidence against your friends, for example) your next line of defense is "I forget". Very hard for the prosecutor to prove beyond reasonable doubt that you really remember that secret key. -- edgar at spectrx.saigon.com (Edgar W. Swank) SPECTROX SYSTEMS +1.408.252.1005 Silicon Valley, Ca From hughes at soda.berkeley.edu Mon Jan 25 15:09:59 1993 From: hughes at soda.berkeley.edu (Eric Hughes) Date: Mon, 25 Jan 93 15:09:59 PST Subject: Coupled programs In-Reply-To: <9301252034.AA21595@netcom2.netcom.com> Message-ID: <9301252308.AA11480@soda.berkeley.edu> Matthew Rapaport writes: >At least not until the BBS operators and writers agree >on some standardized API so people like me and other third parties >can write PC based interfaces in a language of our choice. This is exactly the goal. For example, zmodem has a widespread deployment and a public specification. What needs to happen for cryptography is the development of such protocols for key exchange, signatures, and other cryptographic entities. Eric From hughes at soda.berkeley.edu Mon Jan 25 15:20:38 1993 From: hughes at soda.berkeley.edu (Eric Hughes) Date: Mon, 25 Jan 93 15:20:38 PST Subject: security by obfuscation In-Reply-To: <9301252034.AA21595@netcom2.netcom.com> Message-ID: <9301252318.AA12294@soda.berkeley.edu> Matthew Rapaport writes: >[...] I don't understand the lure >of all these schemes for hiding mail paths, etc. The disambiguating question is "What is the capability of your opponent?" Some opponents have only access to their own machine as users, and some have access as root. Others have access to all traffic on the local network and can thus see all mail entering and leaving a system. Others, we might assume, have access to all traffic on any non-local network. The rule is the following. If it's cheap enough to defend against even the strongest opponent, deploy it. Cryptography, with its presumably exponential difference between the costs of defense (encryption) and offense (cryptanalysis), allows for economical solutions against even the largest of opponents. Cryptography is a greater leveler than the Colt .45 revolver. Eric From dclunie at pax.tpa.com.au Mon Jan 25 16:33:25 1993 From: dclunie at pax.tpa.com.au (David Clunie) Date: Mon, 25 Jan 93 16:33:25 PST Subject: anonymous server compilation? Message-ID: <9301260030.AA03959@britt> > Hello. To my knowledge no public listing of known anonymous servers has > been compiled. > pax.tpa.com.au > -------------- Unfortunately, the anonymous sytem at pax has been closed, as the local network in Australia was considered unsuitable for this kind of thing, partly due to the narrow bandwidth of the link to the US, and partly because of the prevailing attitude at the US end that anonymous mail is generally a bad thing. david From phantom at u.washington.edu Mon Jan 25 16:41:42 1993 From: phantom at u.washington.edu (The Phantom) Date: Mon, 25 Jan 93 16:41:42 PST Subject: New Anonymous Remailer site avail. Message-ID: After the forcing down of the penet site, with the help of Hal Finney I've set up a remailer located at phantom at mead.u.washington.edu. Mail is not cc'ed or kept track of, unless I start getting complaints about abuse, which I will investigate. PGP public key available via finger at phantom at mead.u.washington.edu. I'm pretty sure if all of the encryption bugs are worked out, but I would much appreciate someone helping me out on this; If you do send a message through it and have problems, let me know. Aw, heck, here's the public key - -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.1 mQCNAitcsHIAAAEEAPZ3Ex1rEwKLeANRoaRyTA72htDFGiGPmWkowByZyUtRkTRp Vs/WdhgoJ1VLz76Chyb63I+ejpekeJfOud98gMh2HtVoTjNGYAawpCKo15tFyzYn BFYVy0NjroyxwM6YnPCsYfYMpvyjEa5mfgrlyzvYBBeTDRD89vYoe7Eue0fDAAUR tDJBbm9ueW1vdXMgUmVtYWlsZXIgPHBoYW50b21AbWVhZC51Lndhc2hpbmd0b24u ZWR1PokAlQIFECtcqWpkhnxaNc7AOQEBZ+8EAIOOvsFf/niUrWw0BRvPhSEmtzrA kQJt3q7kPXutjj3IsJ1/oR8oGhv4iPQ5BmNvvd5dnsbbCqOurhaftVgzlSpyQcYi VryeNVvpdeX1+VTS7N+lAHVAlqnimoaEtUUIftDoDIjNNKRDi+nU4GbbL+1MqveC 1LKQMIi1WPjr6Wpw =1XNo -----END PGP PUBLIC KEY BLOCK----- Matt Matt Thomlinson University of Washington, Seattle, Washington. Internet: phantom at u.washington.edu phone: (206) 528-5732 PGP 2.0 key availaible via email or finger phantom at hardy.u.washington.edu From honey at citi.umich.edu Mon Jan 25 16:54:56 1993 From: honey at citi.umich.edu (Peter Honeyman) Date: Mon, 25 Jan 93 16:54:56 PST Subject: This list... Message-ID: <9301260054.AA23403@toad.com> eavesdropping on the list would not reveal lurkers. peter From honey at citi.umich.edu Mon Jan 25 16:58:57 1993 From: honey at citi.umich.edu (Peter Honeyman) Date: Mon, 25 Jan 93 16:58:57 PST Subject: public servant privacy Message-ID: <9301260058.AA23462@toad.com> i believe there is a special exception related to automobiles that makes them subject to search without a warrant when the driver is placed under arrest. but check with a lawyer. peter From honey at citi.umich.edu Mon Jan 25 17:01:57 1993 From: honey at citi.umich.edu (Peter Honeyman) Date: Mon, 25 Jan 93 17:01:57 PST Subject: anonymous server compilation? Message-ID: <9301260101.AA23509@toad.com> > Unfortunately, the anonymous sytem at pax has been closed, as the local > network in Australia was considered unsuitable for this kind of thing, > partly due to the narrow bandwidth of the link to the US, and partly because > of the prevailing attitude at the US end that anonymous mail is generally > a bad thing. i thought the latter theory was debunked -- ? peter From honey at citi.umich.edu Mon Jan 25 17:03:57 1993 From: honey at citi.umich.edu (Peter Honeyman) Date: Mon, 25 Jan 93 17:03:57 PST Subject: New Anonymous Remailer site avail. Message-ID: <9301260103.AA23559@toad.com> > After the forcing down of the penet site ... you mean pax, not penet, right? peter From phantom at u.washington.edu Mon Jan 25 17:27:22 1993 From: phantom at u.washington.edu (The Phantom) Date: Mon, 25 Jan 93 17:27:22 PST Subject: New Anonymous Remailer site avail. In-Reply-To: <9301260103.AA00955@bashful.u.washington.edu> Message-ID: On Mon, 25 Jan 1993, Peter Honeyman wrote: > > After the forcing down of the penet site ... > > you mean pax, not penet, right? > > peter Yes -- sorry. Matt Thomlinson University of Washington, Seattle, Washington. Internet: phantom at u.washington.edu phone: (206) 528-5732 PGP 2.0 key availaible via email or finger phantom at hardy.u.washington.edu From mitra at pandora.sf.ca.us Mon Jan 25 18:57:10 1993 From: mitra at pandora.sf.ca.us (Mitra) Date: Mon, 25 Jan 93 18:57:10 PST Subject: Coupled programs In-Reply-To: <9301252308.AA11480@soda.berkeley.edu> Message-ID: Eric Hughes (hughes at soda.berkeley.edu) wrote: : This is exactly the goal. For example, zmodem has a widespread : deployment and a public specification. What needs to happen for : cryptography is the development of such protocols for key exchange, : signatures, and other cryptographic entities. I thought that was the point of PEM? Why not integrate the PGP encryption protocol into the PEM structure? - Mitra From John.Nieder at f33.n125.z1.FIDONET.ORG Mon Jan 25 22:53:33 1993 From: John.Nieder at f33.n125.z1.FIDONET.ORG (John Nieder) Date: Mon, 25 Jan 93 22:53:33 PST Subject: NSA STRENGTH Message-ID: <4625.2B64DAF7@fidogate.FIDONET.ORG> from: john.nieder at f33.n125.z1.fidonet.org >> I am doubtful of the 40,000 figure even with contract employees. That's >> a small army. What the hell could keep that many people busy? (shudder) >NSA occupies two very large office buildings, including the longest >corridor in the world (a mile, if I recall correctly, but my copy of >"The Puzzle Palace" is not handy). I went and took a look, and can >confirm the parking lot is _huge_. As is the case with a good many other gov't. agencies, one can be sure that all the crew are not 9-to-5ers showing up at one office. >The 40,000 figure may or may not be accurate, as the NSA won't say. >Some say the employment is closer to 100,000. Certainly it is much >higher than that of the CIA. It has been a good many years since I traveled in the lower strata of these circles, but it was my information that the NSA, at least at that time, had a manpower pool "hugely greater than the CIA's." It is my understanding that the NSA budget is highly classified - unavailable even to most members of Congress. >Bear in mind that they are the nation's >primary SIGINT facility... I believe you'll find that the NSA also is involved in SATINT & ELINT as well. Never Say Anythings are busy little bees. >operating the various listening posts in >conjunction with military personnel (via Army Security Agency, Naval >Security Group, Air Forc, etc.). It is my belief from personal experience that the NSA requests & receives operational assistance from those innocuous agencies in positions to gather information of use to the NSA in the course of their routine duties. >As always, read James Bamford's "The Puzzle Palace," which gets >referred to a lot on this list. I've tried to read this famous tome a couple of times, but have been unable to hack its turgid prose. Someday. perhaps... > Public Key: waiting for the dust to settle. Excuse me, Tim? JN -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.1 mQCNAitWeuoAAAEEAN2DcLjYiri8Th9HlUFfCxSyxt/FZLjIX121kWoGax9hb8wM QRTtjeN+FKHdkdzD8zr7P+GbExF0X5DhZp02O1te6/2fuHDESHYUsymQpyDqoJpH wd7xZ/VraYhEX6eQzbbS4k5jbdQLzzIdgD8URzAMXYmTkvLrXhAm8ppE4nk3AAUR tDFKb2huIE5pZWRlciA8am9obi5uaWVkZXJAZjMzLm4xMjUuejEuZmlkb25ldC5v cmc+ =237u -----END PGP PUBLIC KEY BLOCK----- ... Who has the USSR's BIOWAR contageous snakebite virus? --- Blue Wave/Opus v2.12 [NR] -- John Nieder - via FidoNet node 1:125/555 UUCP - ...!uunet!hoptoad!kumr!fidogate!33!John.Nieder INTERNET - John.Nieder at f33.n125.z1.FIDONET.ORG From John.Nieder at f33.n125.z1.FIDONET.ORG Mon Jan 25 22:53:35 1993 From: John.Nieder at f33.n125.z1.FIDONET.ORG (John Nieder) Date: Mon, 25 Jan 93 22:53:35 PST Subject: 5th AMENDMENT & DECRYPTION Message-ID: <4627.2B64DAF9@fidogate.FIDONET.ORG> from: john.nieder at f33.n125.z1.fidonet.org > In a recent message, Murdering Thug said: > | The Fifth Ammendment is the tastiest one of all when it comes to > | encryption. By pleading the Fifth, you do not have to decrypt anything > | for the prosecution. The Fifth Ammendment gives you the right not to > | testify or provide evidence that would incriminate you. Providing a > | key to decrypt your hard disk would incriminate you, and you don't > | have to do it. I should like to see the body of case law on which this opinion is based, if any. . Recently this question came up in another forum on encryption & an "authority" on communications law claimed the probable scenario would be that the arresting agency would have the encrypted material decrypted by a competent government or academic agency & the costs of said decryption would eventually be recovered from the defendant through civil suits, presuming the defendant had sufficient assets. It is my memory of the thread that he claimed this had been done in previous cases. JN ... Gun control: It ain't about guns, it's about *control*. --- Blue Wave/Opus v2.12 [NR] -- John Nieder - via FidoNet node 1:125/555 UUCP - ...!uunet!hoptoad!kumr!fidogate!33!John.Nieder INTERNET - John.Nieder at f33.n125.z1.FIDONET.ORG From mimir at u.washington.edu Mon Jan 25 23:34:45 1993 From: mimir at u.washington.edu (Al Billings) Date: Mon, 25 Jan 93 23:34:45 PST Subject: anonymous server compilation? In-Reply-To: <9301252119.AA27366@longs.lance.colostate.edu> Message-ID: On Mon, 25 Jan 1993 ld231782 at longs.lance.colostate.edu wrote: > > pax.tpa.com.au > -------------- > The most sophisticated anonymous posting system to my knowledge. Uses > public key encryption for traffic in both ways (to/from) the server. > No anonymous remailing capabilities yet but dclunie at pax.tpa.com.au, the > administrator, says he's considering it. Had a serious bug recently > fixed that caused a reassignment of previously allocated anonymous > addresses. Located in Australia. This is down and gone. They had problems with the net. I asked earlier if anyone had copies of the code used to run it (as I liked their set-up) but I received no replies. From tcmay at netcom.com Tue Jan 26 00:04:51 1993 From: tcmay at netcom.com (Timothy C. May) Date: Tue, 26 Jan 93 00:04:51 PST Subject: 5th AMENDMENT & DECRYPTION In-Reply-To: <4627.2B64DAF9@fidogate.FIDONET.ORG> Message-ID: <9301260801.AA18233@netcom3.netcom.com> > from: john.nieder at f33.n125.z1.fidonet.org (commenting on the strategy of "taking the 5th" on the matter of decrypting one's files) > . Recently this question came up in another forum on encryption & an > "authority" on communications law claimed the probable scenario would be > that the arresting agency would have the encrypted material decrypted by > a competent government or academic agency & the costs of said decryption > would eventually be recovered from the defendant through civil suits, > presuming the defendant had sufficient assets. It is my memory of the > thread that he claimed this had been done in previous cases. With strong crypto, e.g., with 300 decimal digit moduli, the "costs" of decryption by brute force could easily exceed the GNP/GDP of the U.S. So taking the 5th, or claiming to have "forgotten" the key, should work, all other things being equal. But all other things are not equal...perhaps they eavesdropped as the private key was being typed in (and it was stored somewhere, presumably), perhaps they "black bagged" the house, perhaps a simple pass phrase was used in lieu of memorizing 300 digits, and so on. A lot of work lies ahead. -- .......................................................................... Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay at netcom.com | anonymous networks, digital pseudonyms, zero 408-688-5409 | knowledge, reputations, information markets, W.A.S.T.E.: Aptos, CA | black markets, collapse of governments. Higher Power: 2^756839 | Public Key: waiting for the dust to settle. From phiber at eff.org Tue Jan 26 01:30:08 1993 From: phiber at eff.org (Phiber Optik) Date: Tue, 26 Jan 93 01:30:08 PST Subject: This list... Message-ID: <199301260929.AA16274@eff.org> > > The whole point of this list is to develop techniques to ensure privacy -- > > most of us understand that there isn't much right now. > > but but but ... sendmail already offers an easy way to hide the membership > of a mailing list. why not use it? > > peter > Thank you. Welcome to the world of common sense. It's a given that certain things you just can't be secure against. But when you don't take every precaution, no matter how small, it's called laziness. Not fixing it with the excuse that people have to understand or accept the overall insecurity of things in general sounds pretty idiotic to me. It isn't such a big deal. From karn at qualcomm.com Tue Jan 26 01:55:10 1993 From: karn at qualcomm.com (Phil Karn) Date: Tue, 26 Jan 93 01:55:10 PST Subject: 5th AMENDMENT & DECRYPTION Message-ID: <9301260954.AA09481@servo> Mike Godwin (formerly, I understand) of EFF and I had a lively discussion on precisely this topic back at the Hackers' Conference. Mike insists that there is no firm legal theory or case law on which to base an assertion that the 5th amendment would shield you from being compelled to divulge an encryption key that could then be used to decrypt information to be used as evidence against you. He says that the closest the Supreme Court came to this issue was an offhand remark in a 5th amendment case to the effect that "of course, we couldn't compel the defendant to, say, reveal the combination on a lock". I forget the precise legal term that Mike used to refer to this comment, but he said it didn't establish a binding legal precedent because it didn't relate directly to an issue in the case at hand. On the other hand, several other lawyers I've asked have responded "of course!" when I ask them whether the 5th amendment would protect a defendant from being compelled to divulge an encryption key without immunity for the evidence it might decrypt. My own opinion, given that I seem unable to get a complete consensus from the lawyers, (has this *ever* been possible?) is that the issue is as yet untested in court and could go either way depending on the actual case. But Mike seems much more pessimistic, and he *is* a lawyer. I'm not. Don't give up working on those steganographic schemes just yet. And wherever practical (e.g., for communications as opposed to storage), use a key management scheme that doesn't leave anything around that can be seized or subpeonaed after the fact (e.g., Diffie's "perfect forward secrecy" scheme.) Phil From tony at morgan.demon.co.uk Tue Jan 26 04:51:23 1993 From: tony at morgan.demon.co.uk (Tony Kidson) Date: Tue, 26 Jan 93 04:51:23 PST Subject: 5th AMENDMENT & DECRYPTION Message-ID: <1726@morgan.demon.co.uk> Well, the autorities trying to decrypt somebody's files would make an 'interesting' test for PGP. Although, they'd only have to crack the 'conventional' cypher to find your secret key. Tony +-----------------+-------------------------------+--------------------------+ | Tony Kidson |`morgan' is an 8MB 486/33 Cat-| Voice +44 81 466 5127 | | Morgan Towers, |Warmer with a 670 MB Hard Disk.| E-Mail | | Morgan Road, |It resides at Morgan Towers in| tony at morgan.demon.co.uk | | Bromley, |Beautiful Down Town Bromley. | tny at cix.compulink.co.uk | | England BR1 3QE |Honda ST1100 ==*== DoD# 0801 | 100024.301 at compuserve.com| +=================+===============================+==========================+ From tony at morgan.demon.co.uk Tue Jan 26 04:52:57 1993 From: tony at morgan.demon.co.uk (Tony Kidson) Date: Tue, 26 Jan 93 04:52:57 PST Subject: 5th AMENDMENT & DECRYPTION Message-ID: <1727@morgan.demon.co.uk> In message <9301260801.AA18233 at netcom3.netcom.com> you write: > > > from: john.nieder at f33.n125.z1.fidonet.org > > (commenting on the strategy of "taking the 5th" on the matter of > decrypting one's files) .................. > > With strong crypto, e.g., with 300 decimal digit moduli, the "costs" > of decryption by brute force could easily exceed the GNP/GDP of the > U.S. ........ > bagged" the house, perhaps a simple pass phrase was used in lieu of > memorizing 300 digits, and so on. But what is encrypted with the 'simple phrase' is quite short and does not provide much material for cryptanalysis. Tony +-----------------+-------------------------------+--------------------------+ | Tony Kidson |`morgan' is an 8MB 486/33 Cat-| Voice +44 81 466 5127 | | Morgan Towers, |Warmer with a 670 MB Hard Disk.| E-Mail | | Morgan Road, |It resides at Morgan Towers in| tony at morgan.demon.co.uk | | Bromley, |Beautiful Down Town Bromley. | tny at cix.compulink.co.uk | | England BR1 3QE |Honda ST1100 ==*== DoD# 0801 | 100024.301 at compuserve.com| +=================+===============================+==========================+ From veritas!u.washington.edu!news at markv.com Tue Jan 26 06:42:10 1993 From: veritas!u.washington.edu!news at markv.com (veritas!u.washington.edu!news at markv.com) Date: Tue, 26 Jan 93 06:42:10 PST Subject: No Subject Message-ID: From thug at phantom.com Tue Jan 26 08:49:57 1993 From: thug at phantom.com (Murdering Thug) Date: Tue, 26 Jan 93 08:49:57 PST Subject: Computerized OTP (was 5th AMENDMENT & DECRYPTION) In-Reply-To: <9301260801.AA18233@netcom3.netcom.com> Message-ID: tcmay at netcom.com writes: > > from: john.nieder at f33.n125.z1.fidonet.org > > (commenting on the strategy of "taking the 5th" on the matter of > decrypting one's files) > > > . Recently this question came up in another forum on encryption & an > > "authority" on communications law claimed the probable scenario would be > > that the arresting agency would have the encrypted material decrypted by > > a competent government or academic agency & the costs of said decryption > > would eventually be recovered from the defendant through civil suits, > > presuming the defendant had sufficient assets. It is my memory of the > > thread that he claimed this had been done in previous cases. > > With strong crypto, e.g., with 300 decimal digit moduli, the "costs" > of decryption by brute force could easily exceed the GNP/GDP of the > U.S. Since none of us have ever been inside the NSA, we cannot underestimate their power and resources. For all we know they may have 500 Intel Delta supercomputers linked together, each having 65,536 i860-XP/50mhz chips. We really don't know what kind of iron they possess. Thus we can't assume that they can't factor extremely large numbers easily. The only way to thwart the NSA is to use an encryption scheme which has been _proven_ uncrackable. The only one I know of is the One Time Pad. A person I know is working on a computerized version of the OTP that extracts a truly random stream of bits from TV/RF static and massages it using a DSP to be highly variable (e.g.: no runs of 0's or 1's longer than 5 bits). This stream is then XOR'd in one time pad fashion with an LZW compressed version of a plaintext message. The key stream is never re-used and after a byte from the key stream is used, it is erased (crossed off the digital pad). Since no bit in the key stream has any known relationship to any other bit (unlike in pseudo-random-number generators), the goal of extracting either the key or the plain text is intractable. If the NSA can crack the OTP, then they must have God himself on their salary. Read the sci.crypt FAQ on more info about the one time pad. The only problem with the whole OTP scheme is that it can only be used for provably secure communications over unsecure channels. It is much more difficult to use a OTP to encrypt one's hard disk without having to memorize 50 million bits of TV/RF static. Then again 50 million bits of TV/RF static can be stored on a totally-self-destructing memory device. For instance a memory card with battary backed RAM that fits in my pocket. If the law busts in, I merely have to pull out the lithium battary from the card and the key is destroyed beyond all possible recovery. If the NSA can extract bits from the proverbial bit bucket in the sky (also known as write once memory (WOM)), then they truly must have God working on their side. Thug From elee9sf at Menudo.UH.EDU Tue Jan 26 08:55:07 1993 From: elee9sf at Menudo.UH.EDU (Karl Barrus) Date: Tue, 26 Jan 93 08:55:07 PST Subject: digital bank Message-ID: <199301261654.AA04341@Menudo.UH.EDU> -----BEGIN PGP SIGNED MESSAGE----- Fellow cypherpunks: I have been working on a digital bank, implementing Hal Finney's simple bank protocol (random account number and random digicash - not Chaum's more sophisticated system based on RSA encryption, decryption, blinded messages, etc.) The enhancement posted by ?? - I can't remember right now - (having to do with wallets) is not implemented. I beleive it is ready to enter the next test phase: everyone on the list may apply for an account. Send a message of this form to the anonymous remailer I run (elee7h5 at rosebud.ee.uh.edu) : :: command: help user at host Be sure to include your real mail address in the user at host line, because that's where the bank will send back the information. /-----------------------------------\ | Karl L. Barrus | | elee9sf at menudo.uh.edu | <- preferred address | barrus at tree.egr.uh.edu (NeXTMail) | \-----------------------------------/ -----BEGIN PGP SIGNATURE----- Version: 2.1 iQCVAgUBK2VsWoOA7OpLWtYzAQGCTQQAlM3qhbcO2DvAAIGunmoVMYdHhTISS+7w YOq7oUoWU9Ys8kSaQMIHEmoaNITnaK5VZBIEbOdbI8oWzyUBkuKmPk+n8+SBr8PD KCs2ULSm6fqQ9nOe0sqOa8U0F6Q8Pij7YLjbdApeSjKA32XcnT4PcVq/iCP0HhBn svCTwLiXXIA= =9mlF -----END PGP SIGNATURE----- From fnerd at smds.com Tue Jan 26 08:59:23 1993 From: fnerd at smds.com (FutureNerd Steve Witham) Date: Tue, 26 Jan 93 08:59:23 PST Subject: Hash Cash and Ripped Checks Message-ID: <9301261617.AB12479@smds.com> Here's a form of digital cash and checks that takes off from Tim May's and Hal's ideas, and might have advantages, but uses crypto. I find it easier to understand than Chaum's method (but maybe the complexity vs. benefits make it the worst of all possible worlds...lemme know). Consider: This message can be exchanged for $x at Fred's Bank by the first person to present it along with a message whose MD5 hash is: h (Serial number: n) Digitally Signed, Fred's Bank Think of this as the right half of a $x bill that's been ripped in half. The hash is the shape of the rip. The bill is valid if you're the first one with both matching halves. The left half is blank (a random message that hashes to h). TO VERIFY: take a new piece of paper, rip it in half (generate a random number, take its hash). Send both halves of the old bill, plus the right half of the piece of paper (the new hash), to the bank. The bank either says the old bill was spent*, or sends back the right half with the same amount and their signature. Now only you have the whole new bill. CHECKS: ask the payee to give you a blank right half. Pay the bank to fill it in. The payee can verify that it's good without taking it to the bank. STAMPS/TOKENS/GIFT CERTIFICATES: The payee gives you a pack of right halves. You turn them to checks later. They might include a serial number with each one and ask you to give it back with the check so they can look up (or regenerate!) the left halves easily. They might even insist that you use the hash/serial # pairs in sequence! (Or is crypto- strong hashing of serial numbers too much to ask?) There are even more compromises of anonymity here than with Tim and Hal's ideas--I assume some compensation with remailers, as Hal suggested. I was thinking you could launder money by buying checks from Bank B with checks to Bank B that are drawn on Bank A, etc. A similar form would be something that said: This message can be exchanged for $x at Fred's Bank by the first person to present it signed with the private key that matches this public key: k (Serial number: n) (pad) Digitally Signed, Fred's Bank This would let you buy checks to random strangers without having to transact anything with them first, but it's sure obvious who the check is to. *Maybe you'd send the right half, then the bank would either prove that it already had the left half, or you'd proceed as above. -fnerd quote me fnerd at smds.com (FutureNerd Steve Witham) From pmetzger at shearson.com Tue Jan 26 09:01:32 1993 From: pmetzger at shearson.com (Perry E. Metzger) Date: Tue, 26 Jan 93 09:01:32 PST Subject: This list... Message-ID: <9301261633.AA17497@maggie.shearson.com> > From: Peter Honeyman > To: pmetzger at shearson.com > > eavesdropping on the list would not reveal lurkers. > > peter But eavesdropping on the mail coming out of toad.com would. In any case I think I've made my point -- its fine to patch holes, so long as one is aware that one hasn't given people a sense of false security in so doing. Perry From jim at tadpole.com Tue Jan 26 09:18:43 1993 From: jim at tadpole.com (Jim Thompson) Date: Tue, 26 Jan 93 09:18:43 PST Subject: Rational PC mail , was Re: PGP on BBS Message-ID: <9301261717.AA13492@tadpole.tadpole.com> > From: pfarrell at cs.gmu.edu (Pat Farrell) > > With NUpop and Eudora, SLIP is optional. The NUpop docs say > that SLIP slows down the transfer, and recommends simple ASCII > async connection using a reliable modem (MNP or V42/V.42bis) I don't understand how the authors of this document can do so. Modern compressed-header SLIP implementations will compress the TCP/IP/SLIP headers down to 5 or 6 'bytes' (octets), on the average. In theory, I suppose its true, but in practice, it makes little difference. Even without header compression, and assuming minimal-sized datagrams, you end up with an overhead of 41/576. 93% of your bandwidth is still yours. A simple ASCII async connection using MNP or V.42 still violates the end-to-end argument. Serial ports can, and do loose characters. Leaving your encrypted message, or even your key, to the whims of a cheap modem, (you'll never know what the other guy has), or back serial drivers seems a bad idea to me. Jim From jthomas at kolanut.mitre.org Tue Jan 26 09:24:19 1993 From: jthomas at kolanut.mitre.org (Joe Thomas) Date: Tue, 26 Jan 93 09:24:19 PST Subject: Computerized OTP (was 5th AMENDMENT & DECRYPTION) Message-ID: <9301261719.AA00224@kolanut> From: thug at phantom.com (Murdering Thug) tcmay at netcom.com writes: > > from: john.nieder at f33.n125.z1.fidonet.org > > (commenting on the strategy of "taking the 5th" on the matter of > decrypting one's files) > > > . Recently this question came up in another forum on encryption & an > > "authority" on communications law claimed the probable scenario would be > > that the arresting agency would have the encrypted material decrypted by > > a competent government or academic agency & the costs of said decryption > > would eventually be recovered from the defendant through civil suits, > > presuming the defendant had sufficient assets. It is my memory of the > > thread that he claimed this had been done in previous cases. > > With strong crypto, e.g., with 300 decimal digit moduli, the "costs" > of decryption by brute force could easily exceed the GNP/GDP of the > U.S. Since none of us have ever been inside the NSA, we cannot underestimate their power and resources. For all we know they may have 500 Intel Delta supercomputers linked together, each having 65,536 i860-XP/50mhz chips. We really don't know what kind of iron they possess. Thus we can't assume that they can't factor extremely large numbers easily. The only way to thwart the NSA is to use an encryption scheme which has been _proven_ uncrackable. The only one I know of is the One Time Pad. True, but impractical. I can't conceive of any rational one-time-pad key distribution over the net. Key distribution has to be over a guaranteed secure channel. For RSA, the channel only has to be authenticated. And if NSA can crack RSA, it would be worth having one cypherpunk lose one court case to find that out (yup, even if it's me...). Joe From jim at tadpole.com Tue Jan 26 09:34:03 1993 From: jim at tadpole.com (Jim Thompson) Date: Tue, 26 Jan 93 09:34:03 PST Subject: Computerized OTP (was 5th AMENDMENT & DECRYPTION) Message-ID: <9301261732.AA13574@tadpole.tadpole.com> > From: thug at phantom.com (Murdering Thug) > Since none of us have ever been inside the NSA, we cannot underestimate > their power and resources. For all we know they may have 500 Intel Delta > supercomputers linked together, each having 65,536 i860-XP/50mhz chips. > We really don't know what kind of iron they possess. Thus we can't assume > that they can't factor extremely large numbers easily. Um, I've been inside the NSA, (and I don't have a clearence.) They have a very nice visitors center, where they display some of their more arcane technology, along with little placards explaining what the hardware does. For instance, they display a very nice looking u-wave radio-based computer (complete with wax lenses), and a light-based floating-point engine that develops God-only-knows how many hundres Gflops, and yes, it can be custom programmed. They display a RISC core (of their own design) than also has a custom crypto unit on-chip, said unit can be field re-programmed. Also displayed are various arcane (antique) crypto devices. Jim P.S. Admittedly, I didn't get very far inside.. From pmetzger at shearson.com Tue Jan 26 10:12:27 1993 From: pmetzger at shearson.com (Perry E. Metzger) Date: Tue, 26 Jan 93 10:12:27 PST Subject: 5th AMENDMENT & DECRYPTION Message-ID: <9301261731.AA19162@maggie.shearson.com> > From: karn at qualcomm.com (Phil Karn) > > On the other hand, several other lawyers I've asked have responded "of > course!" when I ask them whether the 5th amendment would protect a > defendant from being compelled to divulge an encryption key without > immunity for the evidence it might decrypt. > > My own opinion, given that I seem unable to get a complete consensus > from the lawyers, (has this *ever* been possible?) is that the issue > is as yet untested in court and could go either way depending on the > actual case. But Mike seems much more pessimistic, and he *is* a > lawyer. I'm not. One might, of course, validly ask what the potential penalty would be for failing to divulge the key. Presumably, you would be held to be in contempt of court and sent off to jail until you divulged the key -- but at best you are likely to be locked up for a few months before the judge gives up. Given that, one can make a decision on whether the data you had encrypted is worth the loss of a few months of your life. (Remember, by the way, that merely having been in contempt is not nearly the same as having, say, a felony conviction on your record.) So even if they might have an argument for why they should be able to order you to give them a key, that doesn't mean that they have any real way to get it -- you can still fail to hand it over if you are willing to pay the price. Perry From pfarrell at cs.gmu.edu Tue Jan 26 10:29:30 1993 From: pfarrell at cs.gmu.edu (Pat Farrell) Date: Tue, 26 Jan 93 10:29:30 PST Subject: Rational PC mail , was Re: PGP on BBS Message-ID: <9301261824.AA23577@cs.gmu.edu> Jim, While serial ports do lose characters, especially if you don't have a 16550afn serial chip, I don't see this as a major hassle. In a pure DOS space, you really arn't likely to lose the characters, and this is the initial space of NUpop. With Windows, you have to learn to play with the priorities to make it work well, or get one of the intellegent serial driver DLLs that make it transparent. It is possible that the authors of the NUpop document don't worry too much about single character dropouts. There is plenty of redundancy in english. PGP will complain, but I can see retransmitting a message half a dozen times to get it thru cleanly will lose. I never allow my private key anywhere near a serial port. The public keys are checksummed, so it is easy to see that a character is wrong. I'd love to be able to use CSLIP. We (a bunch of folks on this campus) have just convinced the admin to allow POP services. It will take a while before we can convince them to allow SLIP, CSLIP, and PPP. In the meantime, I'll happily live with NUpop's serial support. Pat From tcmay at netcom.com Tue Jan 26 10:31:31 1993 From: tcmay at netcom.com (Timothy C. May) Date: Tue, 26 Jan 93 10:31:31 PST Subject: Computerized OTP (was 5th AMENDMENT & DECRYPTION) In-Reply-To: Message-ID: <9301261828.AA25565@netcom3.netcom.com> Murdering Thug (not his real name) writes, quoting me: > > With strong crypto, e.g., with 300 decimal digit moduli, the "costs" > > of decryption by brute force could easily exceed the GNP/GDP of the > > U.S. > > Since none of us have ever been inside the NSA, we cannot underestimate > their power and resources. For all we know they may have 500 Intel Delta > supercomputers linked together, each having 65,536 i860-XP/50mhz chips. > We really don't know what kind of iron they possess. Thus we can't assume > that they can't factor extremely large numbers easily. Doubtful. That's why I cited 300 decimal digit moduli...the current factoring record is, I believe, a 105 digit number, and this took a network of Sun workstations a year or so (this was big news some months back). As a former Intel employee and current Intel stockholder (yeah!), I certainly hope the NSA is consuming large numbers of Touchstone Deltas, but they won't do much good against strong crypto. A bigger effect would be a breakthrough in factoring. No evidence of this, though. > The only way to thwart the NSA is to use an encryption scheme which has > been _proven_ uncrackable. The only one I know of is the One Time Pad. > A person I know is working on a computerized version of the OTP that ....rest elided... Sure, one-time pads are information-theoretically secure. The problem is the key distribution problem, as well as the storage of one-time pads. For example, for the couple of hundred folks on this list to communicate securely will other members, each would have to meet in person or deliver by trusted courier a one-time pad to _each_ of the others! A very tough logistical problem, fraught with potential weaknesses, and much easier to spoof or break than, for example, factoring very large numbers. This is the problem, the key distribution problem, that public key methods solve. -Tim -- .......................................................................... Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay at netcom.com | anonymous networks, digital pseudonyms, zero 408-688-5409 | knowledge, reputations, information markets, W.A.S.T.E.: Aptos, CA | black markets, collapse of governments. Higher Power: 2^756839 | Public Key: waiting for the dust to settle. From P30TMR8%NIU.bitnet at UICVM.UIC.EDU Tue Jan 26 11:12:12 1993 From: P30TMR8%NIU.bitnet at UICVM.UIC.EDU (P30TMR8%NIU.bitnet at UICVM.UIC.EDU) Date: Tue, 26 Jan 93 11:12:12 PST Subject: manifesto Message-ID: <9301261912.AA09570@toad.com> how would I get a copy of the manifesto? Thanks, Micheal Roberts From pmetzger at shearson.com Tue Jan 26 11:25:54 1993 From: pmetzger at shearson.com (Perry E. Metzger) Date: Tue, 26 Jan 93 11:25:54 PST Subject: Computerized OTP (was 5th AMENDMENT & DECRYPTION) Message-ID: <9301261853.AA21329@maggie.shearson.com> > From: thug at phantom.com (Murdering Thug) > Since none of us have ever been inside the NSA, we cannot > underestimate > their power and resources. For all we know they may have 500 Intel > Delta > supercomputers linked together, each having 65,536 i860-XP/50mhz > chips. > We really don't know what kind of iron they possess. Thus we can't > assume > that they can't factor extremely large numbers easily. Mr. Thug doesn't seem to understand the issue here. Your fear should be that the NSA knows something about number theory we don't, not that they possess a huge number of supercomputers. Consider that we believe the factoring problem to be exponential in the number of digits. That means that doubling the number of digits doesn't double the size of the problem -- it makes it far, far, far worse. Indeed, I suspect that it could be shown that using a key of only a few thousand digits, barring a change in factoring algorithm there would be no way to factor the number in the lifetime of the universe even were all the matter and energy in the universe given over to the factoring problem. There are problems that are known to be that size, by the way -- such as trying to do a complete search on the game tree for chess. So, if you are worried that the NSA might have 10,000 times the resources you suspected, you can just add a few more digits on to your key and defeat that possibility. Myself, I always use a key thats as long as possible to be safe, but I think that paranoia about their HARDWARE is wholely misplaced. The thing to be paranoid about is that they know something about factoring algorithms that we do not. Perry From Marc.Ringuette at GS80.SP.CS.CMU.EDU Tue Jan 26 11:46:37 1993 From: Marc.Ringuette at GS80.SP.CS.CMU.EDU (Marc.Ringuette at GS80.SP.CS.CMU.EDU) Date: Tue, 26 Jan 93 11:46:37 PST Subject: Computerized OTP (was 5th AMENDMENT & DECRYPTION) Message-ID: <9301261946.AA09982@toad.com> thug at phantom.com (Murdering Thug) writes, > A person I know is working on a computerized version of the OTP that > extracts a truly random stream of bits from TV/RF static and massages it > using a DSP to be highly variable (e.g.: no runs of 0's or 1's longer than > 5 bits). Cool! You've managed to weaken the one time pad enough for someone to crack it! [ I can collect statistics on the plaintext based on the fact that if five zeroes occur in the OTP then the next bit is constrained to be one. Of course, I don't have complete access to the OTP, but it's an extremely useful statitistical foot-in-the-door. ] This failure occurred because your friend tried to create a number sequence that is somehow "more random than random". Such a sequence is, by definition, weak. -- Marc Ringuette (mnr at cs.cmu.edu) From vinman at ravel.udel.edu Tue Jan 26 12:06:56 1993 From: vinman at ravel.udel.edu (Vincent Dileonardo) Date: Tue, 26 Jan 93 12:06:56 PST Subject: withdraw Message-ID: <199301262005.AA22494@ravel.udel.edu> I would like to request that I be removed from your mailing list as soon as possible. Thank you. Vinnie DiLeonardo From jim at tadpole.com Tue Jan 26 12:35:45 1993 From: jim at tadpole.com (Jim Thompson) Date: Tue, 26 Jan 93 12:35:45 PST Subject: Rational PC mail , was Re: PGP on BBS Message-ID: <9301262034.AA14699@tadpole.tadpole.com> > From pfarrell at cs.gmu.edu Tue Jan 26 12:28:05 1993 > > While serial ports do lose characters, especially if you don't have > a 16550afn serial chip, I don't see this as a major hassle. In a pure > DOS space, you really arn't likely to lose the characters, and this > is the initial space of NUpop. With Windows, you have to learn to play > with the priorities to make it work well, or get one of the intellegent > serial driver DLLs that make it transparent. Let me try to put it another way. The higher you drive the DTE rate, the more likely you are to loose characters. At the same time, you start to care less about the (small) protocol overheads involved. > It is possible that the authors of the NUpop document don't worry too > much about single character dropouts. There is plenty of redundancy in > english. PGP will complain, but I can see retransmitting a message > half a dozen times to get it thru cleanly will lose. But if characters change during transmit, how can you tell that the message wasn't altered by some agent other than the device/driver? Further, if it happens only occasionally, won't you react with mistrust of the original message? "Hey, this message doesn't check with the author's key!" If it happens a lot, aren't you more likely to say, "Well, he must have meant $10,000, not $1000, the serial port must be loosing again." rather than resending some number of times? > I never allow my private key anywhere near a serial port. The public keys > are checksummed, so it is easy to see that a character is wrong. > I'd love to be able to use CSLIP. We (a bunch of folks on this campus) have > just convinced the admin to allow POP services. It will take a while before > we can convince them to allow SLIP, CSLIP, and PPP. The older I get, the more I understand, "Power to the people." Cheers, Jim From thug at phantom.com Tue Jan 26 12:46:59 1993 From: thug at phantom.com (Murdering Thug) Date: Tue, 26 Jan 93 12:46:59 PST Subject: Computerized OTP (a clarification) In-Reply-To: <9301261828.AA25565@netcom3.netcom.com> Message-ID: tcmay at netcom.com writes: > Sure, one-time pads are information-theoretically secure. > > The problem is the key distribution problem, as well as the storage of > one-time pads. For example, for the couple of hundred folks on this > list to communicate securely will other members, each would have to > meet in person or deliver by trusted courier a one-time pad to _each_ > of the others! A very tough logistical problem, fraught with potential > weaknesses, and much easier to spoof or break than, for example, > factoring very large numbers. > > This is the problem, the key distribution problem, that public key > methods solve. > I never recommended the digital OTP as a replacement for public key cryptography. Clearly the logistics of using OTPs on a large scale are clearly dismal. While public key solutions like PGP are good for mass communication systems, they are not secure as far as I am concerned. I am sure the NSA has plenty of tricks up their sleeve for dealing with PGP & RSA. OTP is an excellent solution for small groups (5 people or less) who MUST have completely secure communications. It would be quite easy for a small group like this to physically meet once a year and exchange their fresh 250mb pads (stored on magnetic reel tape which is incrementaly shreaded & burned on the way out of a OTP decoding machine). In fact only one trusted individual is needed to operate an OTP pad generating machine to create the fresh pad tapes from RF noise and only once a year. This could be the ring leader of the group and tape distributor. A 250mb pad is enough for each individual to send 250,000 one kilobyte messages to his conspirators, surely enough pad material to require physical pad exchange only once a year, perhaps even less frequently. A terrorist group or drug ring could use OTPs quite easily from a logistical and key distribution point of view and never have to worry about their messages (e-mail or telex) being decrypted by any agency on the face of the earth. The costs of such a method are minimal for a group of 5 terrorists, a 5-node system like this could be built and set up for around $5000. Of course an OTP scheme must insure physical security as well. Used up key stream tape must be incrementally shredded and burned beyond recovery. And plaintext messages should be displayed to CRT, never be stored. After each message is read or sent, it is destroyed by being overwritten in RAM by nulls. The screen should either by an LCD display or a Tempest proof CRT. Unused pad tape must be quickly removable so that it can be dropped into a near by barrel of sulfuric acid should the law bust through your door. This would prevent the capture of the unused pad tape and prevent the law from spoofing your conspirators by sending and decoding messages as you. A ventilation system must be put in place to suck out the fumes from the barrel of acid out of the room. A wireless alarm system must be in place to allow the detection of a law enforcement assault and allow the quick acid bath destruction of unused pad material. Note, this scheme comes directly from my mind as I speak and does not fly out of anything. It could be refined into a very secure and inexpensive set up. A well implemented OTP scheme makes the interception of plaintext impossible and the capture of messages by physical raids also impossible. This is what I believe to be the only provably secure communication method. If I was a drug king pin, this is what I would use. Thug From phantom at u.washington.edu Tue Jan 26 16:24:02 1993 From: phantom at u.washington.edu (The Phantom) Date: Tue, 26 Jan 93 16:24:02 PST Subject: weak point of PGP implementation Message-ID: tcmay says: ---- With strong crypto, e.g., with 300 decimal digit moduli, the "costs" of decryption by brute force could easily exceed the GNP/GDP of the U.S. ... bagged" the house, perhaps a simple pass phrase was used in lieu of memorizing 300 digits, and so on. ---- I've been wondering about this. It seems as though the weak point of PGP is one of three possible things: 1) RSA key length (a key length of 10 digits might be a good target, but noone using pgp uses anything so absurdly small, so this can be all but ruled out barring any huge jumps in factoring .. 2) 'conventional cryptography' used for encoding the secring.pgp files, etc. What crypto, exactly, is used? How strong is it? If the NSA knocked on the door and demanded your computer, would it try to crack your key, or would it go directly for the secring.pgp file? 3) length/triviality of pass phrase. This is, I would think, the weakest point mentioned yet. How long does the pass phrase have to be until this point becomes as secure as the weaker of the above two? If all bits of your passphrase were random, how long would an exhaustive search take? matt Matt Thomlinson University of Washington, Seattle, Washington. Internet: phantom at u.washington.edu phone: (206) 528-5732 PGP 2.0 key availaible via email or finger phantom at hardy.u.washington.edu From nowhere at bsu-cs.bsu.edu Tue Jan 26 17:18:54 1993 From: nowhere at bsu-cs.bsu.edu (Chael Hall) Date: Tue, 26 Jan 93 17:18:54 PST Subject: Remailer Changes Message-ID: <9301270115.AA24665@bsu-cs.bsu.edu> The following changes have been made to the remailer running here at bsu-cs. Note that they are effective immediately. If some of you would please just try sending a few messages through the remailer so I can be sure it is working (I don't care if you remail it to yourself, but I want to look at the debug output so that I can turn off the logs. Changes: - Thanks to a suggestion on here, I have changed to the more standard "::" format. If and only if the first line of the message after the header contains "::" will the lines following it up until a blank line *OR* another "::" on a line by itself be parsed as though they are part of the header. - Any "X-Anon-To," "X-Anonymously-To," or "Request-Remailing-To," lines in the main header or the secondary header will cause the recipient's name to be set to its value. The last one listed will be the one to which the mail is sent (I haven't decided whether or not multiple recipients are going to be supported yet) - Any "From" line in either header will be stripped. - Any line except the "Subject" line will be stripped from the main header before being sent. - Any lines aside from those already described above that are contained in the secondary header will be appended to the header before the message is sent out. - No X-Anon-To, X-Anonymously-To, or Request-Remailing-To header lines will be passed on in case this remailer is being chained onto another remailer (which would cause an endless loop if it found its own address as the X-Anon-To field and didn't strip it on outbound mail). Please let me know what you think. Once again, this software is written in C and I plan to release source code when the project is completed. Chael Hall -- Chael Hall nowhere at bsu-cs.bsu.edu, 00CCHALL at LEO.BSUVC.BSU.EDU, CHALL at CLSV.Charon.BSU.Edu (317) 285-3648 after 4 pm EST From hugh at domingo.teracons.com Tue Jan 26 18:37:41 1993 From: hugh at domingo.teracons.com (Hugh Daniel) Date: Tue, 26 Jan 93 18:37:41 PST Subject: Remailer Changes In-Reply-To: <9301270115.AA24665@bsu-cs.bsu.edu> Message-ID: <9301270235.AA01717@domingo.teracons.com> Why are you retaining the Subject: headder line? If I want a Subject: line I should include inside the encrypted block. ||ugh Daniel hugh at toad.com From hughes at soda.berkeley.edu Tue Jan 26 19:29:55 1993 From: hughes at soda.berkeley.edu (Eric Hughes) Date: Tue, 26 Jan 93 19:29:55 PST Subject: weak point of PGP implementation In-Reply-To: Message-ID: <9301270327.AA17865@soda.berkeley.edu> Matt mentions three potential weaknesses in PGP: RSA key length, the IDEA cypher, the pass phrase. Let me add: 4. The random number generator used to make session keys. If this is weak, then an opponent might be able to guess them feasibly. This attack does not require breaking the underlying cryptography. 5. Weak random numbers for RSA key generation. If the numbers in the random number pool are not as random as they should be, then one might simply simulate the prime generation algorithm and compile a table of potential PGP primes. Simply running trial division on this list versus a storehouse of public keys might reveal common factors. Even running Euclid's algorithm to find g.c.d.'s on a such a storehouse versus itself might produce factorizations. >From my quick reading of genprime.c, the PGP key generation algorithm searches sequentially from a random starting point. Thus it will tend to find primes that are preceded by large blocks of composite numbers. This alone reduces the search space some, possibly considerably. Has anybody measured how good the keystroke timings are, anyway? Eric From hughes at soda.berkeley.edu Tue Jan 26 19:36:42 1993 From: hughes at soda.berkeley.edu (Eric Hughes) Date: Tue, 26 Jan 93 19:36:42 PST Subject: Computerized OTP (was 5th AMENDMENT & DECRYPTION) In-Reply-To: <9301261946.AA09982@toad.com> Message-ID: <9301270334.AA18297@soda.berkeley.edu> >thug at phantom.com (Murdering Thug) writes, >> (e.g.: no runs of 0's or 1's longer than >> 5 bits). >Cool! You've managed to weaken the one time pad enough for someone to >crack it! Taking 6-graph statistics, we seen that the entropy is 5.95, where it should be 6.00. Or in other words, .992 bits of entropy per bit symbol. That's not good. Eric From hughes at soda.berkeley.edu Tue Jan 26 19:41:31 1993 From: hughes at soda.berkeley.edu (Eric Hughes) Date: Tue, 26 Jan 93 19:41:31 PST Subject: Coupled programs In-Reply-To: Message-ID: <9301270339.AA18743@soda.berkeley.edu> >Eric Hughes (hughes at soda.berkeley.edu) wrote: >: What needs to happen for >: cryptography is the development of such protocols for key exchange, >: signatures, and other cryptographic entities. Mitra writes: >I thought that was the point of PEM? Why not integrate the PGP >encryption protocol into the PEM structure? I am talking about interactive protocols. To generate a session key for communication with some remote host will require both parties to cooperate. PEM is a standard for "privacy enchanced" electronic email formats and encryption methods. PEM is not a standard for interacting protocols. Eric From thug at phantom.com Tue Jan 26 20:14:48 1993 From: thug at phantom.com (Murdering Thug) Date: Tue, 26 Jan 93 20:14:48 PST Subject: Computerized OTP (was 5th AMENDMENT & DECRYPTION) In-Reply-To: Message-ID: Timothy Newsham wries: > Murdering Thug writes: > > The only way to thwart the NSA is to use an encryption scheme which has > > been _proven_ uncrackable. The only one I know of is the One Time Pad. > > didnt shannon prove that the only "unbreakable" encryptions (or > encryptions with "zero knowledge") have to have a key at least > as long as the message? The key stream for a OTP system is infinitely long, and if a real random source is used (e.g. RF noise/static) no bit in the key stream has any relationship to any other bit in the key stream, unlike a pseudo-random-gen key stream where there is a relationship and this relationship can be found and the seed for the PRNG extracted and thus the key is broken. Since TV static on unused channels is basically amplified RF garbage coming in from outer space radio sources and is in fact "white noise", it makes the perfect encoding stream for a one time pad system, it's infinitely long, never repeats, and is never reused. Yes I do think the idea of making a "more random than random" stream by filtering out long runs of 0's or 1's weakens the the key stream in theory, but in practical use it strengthens it, because if the stream is left alone, runs of 500 bits of 0's or 1's can come through, and any fool can then extract plain text using XOR in this area of the cyphertext. LZW compression of the plaintext helps, but I feel that it is far better to reduce the possibility of a key stream containing long runs of 0's or 1's, than to leave it alone. The other possibility is to find a truly random RF source that has all the properties you want, the more important being that the >average< length of a homogenous bit run (0's or 1's) is around 4 or 5 bits. Of course you should let run lengths of 12 bits come through to screw the stat guys, but the >average< run length should be below 8 bits. Such a highly variable stream of white noise makes the perfect key stream in my opinion. Thug From uri at watson.ibm.com Tue Jan 26 20:39:33 1993 From: uri at watson.ibm.com (uri at watson.ibm.com) Date: Tue, 26 Jan 93 20:39:33 PST Subject: weak point of PGP implementation In-Reply-To: <9301270327.AA17865@soda.berkeley.edu> Message-ID: <9301270438.AA15194@buoy.watson.ibm.com> Eric Hughes says: > Matt mentions three potential weaknesses in PGP: RSA key length, the > IDEA cypher, the pass phrase. Probably the first two even a paranoid person won't call "weaknesses". The pass-phrase - th docs should give some guidelines, as to how one must choose his pass-phrase (if it's already there - apologies :-). > Let me add: And now you're talking! (:-) > 4. The random number generator used to make session keys. If this is > weak, then an opponent might be able to guess them feasibly. This attack > does not require breaking the underlying cryptography. > > 5. Weak random numbers for RSA key generation. If the numbers in the > random number pool are not as random as they should be, then one might > simply simulate the prime generation algorithm and compile a table of > potential PGP primes. It looks like that [former] Soviet professor found and pointed out exactly those weaknesses: poor RSA keys (making factoring about two orders of magnitude easier) and poor something else (I couldn't understand what he meant, sorry :-). Quite possible he hit session keys (as likely as not)... -- Regards, Uri uri at watson.ibm.com scifi!angmar!uri N2RIU ----------- >From cypherpunks-request Tue Jan 26 21:28:06 1993 From Marc.Ringuette at GS80.SP.CS.CMU.EDU Tue Jan 26 21:19:45 1993 From: Marc.Ringuette at GS80.SP.CS.CMU.EDU (Marc.Ringuette at GS80.SP.CS.CMU.EDU) Date: Tue, 26 Jan 93 21:19:45 PST Subject: Computerized OTP (was 5th AMENDMENT & DECRYPTION) Message-ID: <9301270519.AA17681@toad.com> Thug writes, > The other possibility is to find a truly random RF source that has all > the properties you want, the more important being that the >average< > length of a homogenous bit run (0's or 1's) is around 4 or 5 bits. "All the properties you want?" What you want is random, and nothing else! Random isn't "average bit runs of 4 or 5 bits". It isn't "nice white noise". It is TRULY RANDOM! You need to understand that the absolutely critical property for a one time pad bit-stream to have is this: given all previous bits seen, the probability that the next bit seen will be zero or one is exactly 0.5. What you need is a method for converting a biased random number stream (say, one where after a run of zeroes, another zero has high probability) into an unbiased one where the probability of the next bit being zero is exactly 0.5. Truncating runs to length 5 is an attempt at this, but a VERY BAD and cryptographically useless attempt. Does anybody remember a good recipe for converting a biased RNG into an unbiased one? I can't think of one off the top of my head, and that's what Thug's friend seems to need. This has been discussed at length in the literature. -- Marc Ringuette (mnr at cs.cmu.edu) From jpp at markv.com Tue Jan 26 22:23:17 1993 From: jpp at markv.com (Jay Prime Positive) Date: Tue, 26 Jan 93 22:23:17 PST Subject: [veritas!u.washington.edu!news@markv.com: ] Message-ID: <9301262221.aa12202@hermix.markv.com> From: jpp at hermix To: cypherpunks at toad.com Subject: [veritas!u.washington.edu!news at markv.com: ] Interesting message I recieved... Twice... j' From strat at intercon.com Tue Jan 26 22:42:12 1993 From: strat at intercon.com (Bob Stratton) Date: Tue, 26 Jan 93 22:42:12 PST Subject: 5th Amendment and keys Message-ID: <9301270641.AA08281@intercon.com> It might be worth pinging Mike Godwin for a summary of his current assessment. I was at a meeting with him over the weekend, and he said he's slowly growing more optimistic with regard to this very issue, as a result of some precedents he found. He'd probably be honored to know that a whole list was hanging on his every word. :-) --Strat From nobody at alumni.cco.caltech.edu Tue Jan 26 22:57:43 1993 From: nobody at alumni.cco.caltech.edu (nobody at alumni.cco.caltech.edu) Date: Tue, 26 Jan 93 22:57:43 PST Subject: Computerized OTP (was 5th AMENDMENT & DECRYPTION) Message-ID: <9301270659.AA10471@alumni.cco.caltech.edu> Murdering Thug wrote: > Yes I do think the idea of making a "more random than random" stream > by filtering out long runs of 0's or 1's weakens the the key stream > in theory, but in practical use it strengthens it, because if the stream > is left alone, runs of 500 bits of 0's or 1's can come through, and any > fool can then extract plain text using XOR in this area of the cyphertext. Thug is wrong about this, but it's a common mistake. It does seem like those runs of 0's (and, to a lesser extent, 1's) are dangerous - there's your plaintext, totally exposed to the prying eyes of strangers! But, what is forgotten is this: for every run of 0's which would reveal your plaintext, there is an equally likely pattern of 1's and 0's which transforms your plaintext into one of Shakespeare's plays. Or into the Declaration of Independence. Or into anything else you like. You see, xor'ing your message with a random stream means that the resulting output is equally likely to be _any_ original message. There is no way in theory or in practice to determine what the message originally was; that is, all bit patterns are equally likely to be the original message. To see an example of this, suppose you had one of the simplest possible original messages: all 1's. Now you xor this with a random pattern. To your dismay, your random stream happens to come up with a large block of 0's. This is what would happen: Original message: 1111111111111111111111111111111111 Random stream: 0011010010000000110111010111001010 Resulting output: 1100101101111111001000101000110101 Look at that big block of 1's in there. Won't that give it away? No. Such a block of 1's is expected to occur occasionally no matter what the original message. It's just as likely that the original message and random stream looked like: Original message: 1010101010101010101010101010101010 Random stream: 0110000111010101100010000010011111 Resulting output: 1100101101111111001000101000110101 There is no way to tell what the original message was, even when you see a block of output which seems to match some pattern. It doesn't tell you anything. Hal 74076.1041 at compuserve.com From tribble at xanadu.com Wed Jan 27 00:50:22 1993 From: tribble at xanadu.com (E. Dean Tribble) Date: Wed, 27 Jan 93 00:50:22 PST Subject: Computerized OTP (was 5th AMENDMENT & DECRYPTION) In-Reply-To: <9301270519.AA17681@toad.com> Message-ID: <9301270816.AA08283@xanadu.xanadu.com> "All the properties you want?" What you want is random, and nothing else! all previous bits seen, the probability that the next bit seen will be zero or one is exactly 0.5. Note that in practice, the length of a string of 1's or 0' is irrelevant: The chance of a string of length N being all the same is O(2^N), so becomes unlikely for reasonably short strings of bits (1 in 1024 for 10 bits), and virtually impossible for interesting sizes of N (1 in 4 billion for 32 bits). This doesn't even strike as being worht the effort of figuring out how badly the OTP is compromised by shortening such runs. Remember how badly our intuitions are on things like security. Believe the numbers, not your gut feel. dean From gnu Wed Jan 27 01:36:14 1993 From: gnu (John Gilmore) Date: Wed, 27 Jan 93 01:36:14 PST Subject: SunExpress to expand "unlockable" software distribution Message-ID: <9301270936.AA24007@toad.com> It would probably be a public service if some interested parties were to determine the ``encryption'' method that Sun Express, the standard Sun ``license manager'', and other packages use. At the moment, the details of these technologies are not described in the public literature (as far as I know). Rather than have these companies discover years too late that their "unlockable" software is really unlockable by anyone who understands cryptography, it'd be better for them to learn it this year, while they are still handling low volumes of programs that way. Also maybe they will stop dumping these programs-that-you-have-but-must-pay-to-run on us. John ---------------------------------------------------------------------------- The Florida SunFlash SunExpress Unveils One-Stop Shopping From the Desktop SunFLASH Vol 49 #21 January 1993 ---------------------------------------------------------------------------- New CD-ROM and facsimile services make it easier than ever to select and purchase products CHELMSFORD, Mass. --January 26, 1993-- SunExpress, a subsidiary of workstation industry leader Sun Microsystems, Inc., today announced two new customer services which simplify information retrieval and product ordering. FaxInfo(SM), which allows SunExpress customers to access product information and order product through their fax machine, is available now. A second program will allow SunExpress customers to "unlock" software applications directly from SunSoft's Catalyst CDware(TM), the most widely-distributed demo CD for users of the UNIX(R) operating system. The CD-ROM program is being implemented in twenty customer sites on a trial basis and will be generally available later this year with Catalyst CDware Volume 5.0. The integration of these technologies, coupled with other electronic ordering innovations planned for release later in 1993, will allow SunExpress to process orders more efficiently and provide a higher level of customer satisfaction. Eventually, these process innovations will result in drastically fewer written orders, smaller inventories, less postage, phone and freight costs, resulting in reduced costs for SunExpress customers. "SunExpress is committed to providing its customers with leading-edge technologies that will make it easier than ever for them to select and purchase products. The new programs announced today are just the beginning," said Dorothy Terrell, president of SunExpress. "In the near future, our customers will be able to browse through full color on-line catalogs, watch video demonstrations and try out software all without leaving their workstation." FaxInfo The FaxInfo program allows SunExpress customers to access detailed product information about catalog offerings within minutes. By calling into the regular SunExpress ordering and information number (800-USE-SUNX), customers can access FaxInfo and have technical data sheets faxed back to the location of their choice by using the touch-tone keypad on their phone. SunExpress maintains up-to-date datasheets on all of the products that it offers and makes revisions to product specs as they are made available. SunExpress joins with SunSoft's Catalyst CDware Program Sun(TM) workstation users currently have access to SunSoft's Catalyst CDware program which allows them to run demo versions of a range of UNIX software applications from several major ISV's and decide whether it is something they would like to buy. With SunExpress' participation in the program, interested customers can purchase and obtain a fully-functional version of their chosen software -- all in one toll-free phone call. Currently this program is being tried out at twenty customer sites with limited software product offerings including: Clarity's Rapport(TM), and Ta-Dah!(TM) and SimCity(TM) from Dux Software. The program is targeted for full implementation with many more titles this summer, and will be attractive to ISVs who are already marketing their product through Catalyst CDware from SunSoft. Catalyst CDware currently carries 73 product presentations from 54 different vendors. "We feel that this service from SunExpress can only enhance the effectiveness and impact of our Catalyst CDware program," said Peter Schakow, Manager of CD programs at SunSoft. "We look forward to providing this added service to our Catalyst CDware partners." ISVs are interested in the SunExpress distribution strategy as a new sales channel. "This program will greatly facilitate our marketing efforts into the Sun installed base," said Bob Adams of DUX Software. "In addition to assisting with new product sales, it will be extremely useful and cost effective for distributing product enhancements and upgrades." SunExpress, a subsidiary of Sun Microsystems, Inc. provides customers with easy access to a wide range of Sun and innovative 3rd party products at low competitive prices and same day shipping. SunExpress supports SPARC(R), Solaris(R), and other computing environments based on the UNIX operating system. The company offers a 30-day no fault return policy and is currently serving customers in the United States, Europe and Japan. SunExpress can be reached at 1 (800) USE-SUNX and is headquartered in Chelmsford, MA. Press Contact: Hi-Tech Communications Mark Lederhos (508) 251-8278 Kathryn Lang (415) 904-7000 x204 Sun Lisa Ganier (415) 336-5637. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ For information send mail to info-sunflash at Sun.COM. Subscription requests should be sent to sunflash-request at Sun.COM. Archives are on solar.nova.edu, uunet.uu.net, sunsite.unc.edu, src.doc.ic.ac.uk and ftp.adelaide.edu.au All prices, availability, and other statements relating to Sun or third party products are valid in the U.S. only. Please contact your local Sales Representative for details of pricing and product availability in your region. Descriptions of, or references to products or publications within SunFlash does not imply an endorsement of that product or publication by Sun Microsystems. John McLaughlin, SunFlash editor, flash at Sun.COM. (305) 776-7770. From John.Nieder at f33.n125.z1.FIDONET.ORG Wed Jan 27 02:58:45 1993 From: John.Nieder at f33.n125.z1.FIDONET.ORG (John Nieder) Date: Wed, 27 Jan 93 02:58:45 PST Subject: PRACTICAL DECRYPTION Message-ID: <4652.2B66598A@fidogate.FIDONET.ORG> from: john.nieder at f33.n125.z1.fidonet.com > (commenting on the strategy of "taking the 5th" on the matter of > decrypting one's files) > > > . Recently this question came up in another forum on encryption & an > > "authority" on communications law claimed the probable scenario would be > > that the arresting agency would have the encrypted material decrypted by > > a competent government or academic agency & the costs of said decryption > > would eventually be recovered from the defendant through civil suits, > > presuming the defendant had sufficient assets. It is my memory of the > > thread that he claimed this had been done in previous cases. > > With strong crypto, e.g., with 300 decimal digit moduli, the "costs" > of decryption by brute force could easily exceed the GNP/GDP of the > U.S. # Since none of us have ever been inside the NSA, we cannot underestimate # their power and resources. For all we know... This is somewhat beside the point. In actual fact, much of the seized encrypted evidence in criminal cases employs built-in encryption programs in major software packages (WordPerfect is a good example) rather than obscurer stuff like PGP/IDEA/RSA. Even highly-touted commercial programs like Norton Utilities DiskReet w/DES use simple passwords of a maximum ten-character size. . Much of this decryption may be trivially accomplished, though many "experts" charged law enforcement agencies stout fees for the service. It is now known that those specializing in WordPerfect files were using a simple program available on most BBS file bases which will crack the "secret" WordPerfect password in seconds on an old XT. . Apparently, the consulting fees for breaking bad crypto in most cases is not prohibitive. . Tim's objections about high-end decryption are indeed valid, at least theoretically, but we can not tell if a given encryption program has been backdoored or if a fatal flaw has been uncovered that reduces the security of the cyphertext. If any cryptanalysts might find such flaws, they would probably be those in no position to reveal their findings. . Jean-Loup Gailly [an original PGP team member in France] informs me that the same general criticisms of PGP soundness voiced in the Moscow State University report have been independently suggested in sci.crypto, though he is aware of no instance of these alleged weaknesses being exploited to break a PGP message. The jury is still out on PGP's ultimate security, I suppose. . Personally, I am not counting on PGP's brute-force decryption being a task of the magnitude Tim suggests, though I _hope_ he's right. I sure wish some well-equipped crypto labs like Marty Hellman's would turn their attentions to an evaluation of PGP... JN --- Blue Wave/Opus v2.12 [NR] -- John Nieder - via FidoNet node 1:125/555 UUCP - ...!uunet!hoptoad!kumr!fidogate!33!John.Nieder INTERNET - John.Nieder at f33.n125.z1.FIDONET.ORG From edgar at spectrx.Saigon.COM Wed Jan 27 03:42:17 1993 From: edgar at spectrx.Saigon.COM (Edgar W. Swank) Date: Wed, 27 Jan 93 03:42:17 PST Subject: a few good weasels Message-ID: Dave del Torto said here: A world of absolutes is not a fun world and it's not a safe world. Someone's gotta break the rules every once in a while or we all go down the tubes. Of course, I _personally_ would _never_ break any of the fine laws of our beloved nation, but I know deep in my heart (but not anywhere on my hard disks) that such brave people exist and that the effect of their less-than-legal efforts is the delicate equilibrium in which we continue to prosper and innovate. I agree completely. So would Ollie North, who is a fine example of "such brave people". -- edgar at spectrx.saigon.com (Edgar W. Swank) SPECTROX SYSTEMS +1.408.252.1005 Silicon Valley, Ca From dsinclai at acs.ucalgary.ca Wed Jan 27 05:37:20 1993 From: dsinclai at acs.ucalgary.ca (Douglas Sinclair) Date: Wed, 27 Jan 93 05:37:20 PST Subject: Random OTP sources Message-ID: <9301271305.AA25910@acs1.acs.ucalgary.ca> Much discussion has been going on about creating a truly random OTP key by tuning in to dead TV channels, etc. There is a much simpler, and more secure way. Look at the decay of a small radioactive source. Find a time period in which there is a 50% chance of seeing an event, and then clock a 1 if you do, or a 0 of you don't. Radioactive sources and detectors are easily obtained from smoke detectors, and it should be fairly easy to set up (though I havn't done it). If our understanding of quantum mechanics are correct, the resulting bitstream is truly random. RF noise may be random. Also, if the NSA or other Big Brother organization knows what you are doing, they can try listening in on the same channel and deducing your key. To my knowledge, there is no way to see what is going on in a small Californium source if you have more than a few meters between the source and detector. Anyhow, a given event will probably only produce one particle, or maybe two, so your point detector will only see a portion of the events and knowledge of particles in another direction doesn't tell you anything. Hm. I hope that was coherent. Any comments? -- Vercotti: I was terrified of him. Everyone was terrified of Doug. I've seen grown men pull their own heads off rather than see Doug. Even Dinsdale was frightened of Doug. Interviewer: What did he do? Vercotti: He used sarcasm. He knew all the tricks, dramatic irony, metaphor, bathos, puns, parody, litotes and satire. -- Monty Python, Episode 14 PGP 2.1 Key by finger From honey at citi.umich.edu Wed Jan 27 07:08:01 1993 From: honey at citi.umich.edu (peter honeyman) Date: Wed, 27 Jan 93 07:08:01 PST Subject: Computerized OTP (was 5th AMENDMENT & DECRYPTION) In-Reply-To: <9301270659.AA10471@alumni.cco.caltech.edu> Message-ID: <9301271507.AA12215@toad.com> Murdering Thug wrote: > Yes I do think the idea of making a "more random than random" stream > by filtering out long runs of 0's or 1's weakens the the key stream > in theory, but in practical use it strengthens it, because if the stream > is left alone, runs of 500 bits of 0's or 1's can come through, and any > fool can then extract plain text using XOR in this area of the cyphertext. this is a one in 2^500 event. just to remind you, 2^500 is 3,273,390,607,896,141,870,013,189,696,827,599,152,216,642,046,043,064,789,483,291,368,096,133,796,404,674,554,883,270,092,325,904,157,150,886,684,127,560,071,009,217,256,545,885,393,053,328,527,589,376 (sorry to those folks whose screens get bugged by looooong lines.) i wouldn't worry about a 1 in 2^500 event occurring too often ... peter From pmetzger at shearson.com Wed Jan 27 09:24:28 1993 From: pmetzger at shearson.com (Perry E. Metzger) Date: Wed, 27 Jan 93 09:24:28 PST Subject: Randomness Message-ID: <9301271622.AA02754@maggie.shearson.com> > From: thug at phantom.com (Murdering Thug) > > Yes I do think the idea of making a "more random than random" stream > by filtering out long runs of 0's or 1's weakens the the key stream > in theory, but in practical use it strengthens it, because if the stream > is left alone, runs of 500 bits of 0's or 1's can come through, and any > fool can then extract plain text using XOR in this area of the cyphertext. The odds against a run of 500 1's is one in 2^500th, which is a number so large I can't imagine a real random number source creating it in the lifetime of our universe. Presumably, your problem is that your random number source is crap. Perry From surfpunk at osc.versant.com Wed Jan 27 10:33:43 1993 From: surfpunk at osc.versant.com (gubhtug gb ribxr fpvrapr svpgvba engure guna fpvrapr) Date: Wed, 27 Jan 93 10:33:43 PST Subject: [surfpunk-0036] CRYPT: Sci Am on Public Key Cryptosystems Message-ID: + + Cypherpunks don't care if you don't like the + software they write. Cypherpunks know that + software can't be destroyed. Cypherpunks know + that a widely dispersed system can't be shut + down. + -- the cypherpunk manifesto + (cypherpunks-request at toad.com) ++++++++++++++++++++++++++++++++++++++++++++++++ Here's a short piece from Scientific American on RSA, PEM, PGP etc. Notice towards the end this article says "The U.S. is the only nation that permits the patenting of mathematical algorithms." That threw me at first -- it's not *supposed* to be permitted, but in practice, it is. So I suppose this is a true statement. (The cover article of this Sci Am is on a team at the Science Museum in London that did a 3-ton implementation of Babbage's Difference Engine.) -- strick ________________________________________________________________________ ________________________________________________________________________ Source: Scientific American, February 1993, beginning at the 30th page. For fair use only. Electronic Envelopes? The uncertainty of keeping e-mail private Recent legislative efforts to mandate remote wiretapping attachments for every telephone system and computer network in the U.S. may have been the best thing that every happened for encryption software. "We have mostly the FBI to thank," says John Gilmore of Cygnus Support in Palo Alto, Calif. Gilmore is an entrepreneur, hacker and electronic civil libertarian who helped to found the Electronic Frontier Foundation (EFF). He is now watching closely the development of two competing techniques for keeping electronic mail private. As matters now stand, computers transmit messages from one user to another in plain text. If a geneticist in Boston sends e-mail to a molecular biologist in San Diego, any of the half a dozen or so intermediary machines that forward the letter could siphon off a copy -- and so could any of the dozens of workstations that might be attached to the local-area network at the sender's or recipient's university or company. The Electronic Privacy Act of 1986 prohibits snooping by public e-mail carriers or law-enforcement officials, except by court order. Nevertheless, many people are becoming uncomfortable with the electronic equivalent of mailing all their correspondence on postcards and relying on people to refrain from reading it. They are turning to public-key encryption, which allows anyone to encode a message but only the recipient to decode it. Each user has a public key, which is made widely available, and a closely guarded secret key. Messages encrypted with one key can be decrypted only with each other, thus also making it possible to "sign" messages by encrypting them with the private key [see "Achieving Electronic Privacy," by David Chaum; Scientific American, August 1992]. Two programs -- and two almost diametrically opposed viewpoints embodied in them -- are competing for acceptance. Privacy Enhanced Mail (PEM) is the long-awaited culmination of years of international standard setting by computer scientists. Pretty Good Privacy (PGP) is a possibly illegal work of "guerilla freeware" originally written by software consultant Philip Zimmermann. The philosophies of PEM and PGP differ most visibly with respect to key management, the crucial task of ensuring that the public keys that encode messages actually belong to the intended recipient rather than a malevolent third party. PEM relies on a rigid hierarchy of trusted companies, universities and other institutions to certify public keys, which are then stored on a "key server" accessible over the Internet. To send private mail, one asks the key server for the public key of the addressee, which has been signed by the appropriate certification authorities. PGP, in contrast, operates on what Zimmermann calls "a web of trust": people who wish to correspond privately can exchange keys directly or through trusted intermediaries. The intermediaries sign the keys that they pass on, thus certifying their authenticity. PGP's decentralized approach has gained a wide following since its initial release in June 1991, according to Hugh E. Miller of Loyola University in Chicago, who maintains an electronic mailing list for discussion among PGP users. His personal "keyring" file contains public keys for about 100 correspondents, and others have keyrings containing far more. As of the end of 1992, meanwhile, a final version of PEM has not been officially released. Gilmore, who subscribes to the electronic mailing list for PEM developers, says he has seen "only five or 10" messages actually encrypted using the software. Although PGP's purchase price is right -- it is freely available over the Internet and on electronic bulletin boards throughout the world -- it does carry two liabilities that could frighten away potential users. First, U.S. law defines cryptographic hardware and software as "munitions." So anyone who is caught making a copy of the program could run afoul of export-control laws. Miller calls this situation "absurd," citing the availability of high-quality cryptographic software on the streets of Moscow. Worse yet, RSA Data Security in Redwood City, Calif., holds rights to a U.S. patent on the public-key encryption algorithm, and D. James Bidzos, the company's president, asserts that anyone using or distributing PGP could be sued for infringement. The company has licensed public-key software to corporations and sells its own encrypted-mail package (the algorithm was developed with federal support, and so the government has a royalty-free license). When Bidzos's attorneys warned Zimmermann that he faced a suit for developing PGP, he gave up further work on the program. Instead PGP's ongoing improvements are in the hands of an international team of software developers who take advice from Zimmermann by e-mail. The U.S. is the only nation that permits the patenting of mathematical algorithms, and so programmers in the Netherlands or New Zealand apparently have little to fear. U.S. residents who import the program could still face legal action, although repeated warnings broadcast in cryptography discussion groups on computer networks have yet to be superseded by legal filings. Meanwhile, Gilmore says, the only substantive effect of the patent threat is that development and use of cryptographic tools have been driven out of the U.S. into less restrictive countries -- Paul Wallich ________________________________________________________________________ ________________________________________________________________________ The SURFPUNK Technical Journal is a dangerous multinational hacker zine originating near BARRNET in the fashionable western arm of the northern California matrix. Quantum Californians appear in one of two states, spin surf or spin punk. Undetected, we are both, or might be neither. ________________________________________________________________________ Send postings to , subscription requests to . MIME encouraged. Xanalogical archive access soon. Cypherpunks love to practice. ________________________________________________________________________ ________________________________________________________________________ #define DA_MD2 3 #define DA_MD5 5 #define MIN_RSA_MODULUS_BITS 508 #define MAX_RSA_MODULUS_BITS 1024 #define MAX_RSA_MODULUS_LEN ((MAX_RSA_MODULUS_BITS + 7) / 8) #define MAX_RSA_PRIME_BITS ((MAX_RSA_MODULUS_BITS + 1) / 2) #define MAX_RSA_PRIME_LEN ((MAX_RSA_PRIME_BITS + 7) / 8) From scott_collins at genmagic.genmagic.com Wed Jan 27 10:40:15 1993 From: scott_collins at genmagic.genmagic.com (Scott Collins) Date: Wed, 27 Jan 93 10:40:15 PST Subject: Randomness and RE>OTPs Message-ID: <9301271839.AA25190@> Subject: Randomness and RE>OTPs >Does anybody remember a good recipe for converting a biased RNG into an >unbiased one? I can't think of one off the top of my head, and that's >what Thug's friend seems to need. This has been discussed at length in >the literature. 1. If you want randomness, introducing order is bad. As Eric Hughes pointed out, trimming runs reduces the entropy of the sequence. You want to increase the entropy i.e. maximize the surprise. One good way to increase the entropy is to compress the 'random' sequence. The output of a good compressor has greater entropy than the input. If the input is already random, no harm done (again, with a GOOD compressor... otherwise it is easy to accidentally introduce order). If the input has some subtle bias or regularity, the compressor will get rid of it (at the cost of reducing the total volume of the sequence). Good compressors are much better at detecting regularity (and eliminating it) than human beings. 2. Of course (as Thug stated) you are (also) compressing the plaintext before you encrypt it. It is best to do this with an adaptive scheme and an arithmetic encoder so that a) the entropy of the plaintext is maximized and so that b) accidentally decrypting something correctly in the middle of the stream is useless. My recommendation for a good binary scheme is DMC (dynamic markov compression) feeding into almost any binary arithmetic encoder (e.g. the Q-coder, et. al.). I would use this to compress both the plaintext stream before encryption, and a 'suspect' random number stream. If there is interest, I will post a bibliography of papers and books relating to this. Scott Collins (Scott_Collins at genmagic.com) From Eric.Fogleman at analog.com Wed Jan 27 14:51:10 1993 From: Eric.Fogleman at analog.com (Eric Fogleman) Date: Wed, 27 Jan 93 14:51:10 PST Subject: Limiting "white" noise runlength Message-ID: <9301272248.AA18636@ack.adstest.analog.com> Mr. Thug, In talking about "white" noise, you mentioned: > Yes I do think the idea of making a "more random than random" stream > by filtering out long runs of 0's or 1's weakens the the key stream > in theory, but in practical use it strengthens it, because if the stream > is left alone, runs of 500 bits of 0's or 1's can come through, and any > fool can then extract plain text using XOR in this area of the cyphertext. > LZW compression of the plaintext helps, but I feel that it is far better > to reduce the possibility of a key stream containing long runs of 0's or > 1's, than to leave it alone. Why not feed back the previously encrypted bits to perform the "present" encryption (something like cipher block chaining) to keep this from happening? Then any particular encrypted character will depend on *all* previous characters and break up runs of "plaintext". That seems much better than un-whitening your white noise... Eric Fogleman From tcmay at netcom.com Wed Jan 27 19:41:55 1993 From: tcmay at netcom.com (Timothy C. May) Date: Wed, 27 Jan 93 19:41:55 PST Subject: (fwd) RISKS DIGEST 14.29 Message-ID: <9301280338.AA09001@netcom3.netcom.com> I found this in RISKS. Apparently, law enforcement types are approaching software vendors and seeking backdoors and other compromises. Note that Lotus is a licensee of RSA, so the encryption algorithms worrying the FBI are probably the main RSA algorithms. Cypherpunk activities are becoming more important than ever. -Tim May From: risks at CSL.SRI.COM (RISKS Forum) Subject: RISKS DIGEST 14.29 Date: 27 Jan 93 22:05:31 GMT ------------------------------ Date: Wed, 20 Jan 93 17:58:49 EST From: joltes at husc.harvard.edu Subject: The FBI and Lotus cc:Mail An interesting tidbit came to light while I was attending a demonstration of Lotus' cc:Mail and Notes products at the Boston NetWorld this month. During the Notes portion of the presentation someone asked how secure the information in the various databases was, and how the encryption was done. The presenter said that the data was considered very secure, so much so that the FBI had approached Lotus to ask that a "back door" be left in the software in order to give the Bureau a method for infiltrating suspects' filesystems. She said they were specifically targeting "drug dealers and other bad people." Given this backdoor, what was to stop the Bureau from inspecting confidential materials on any system? The risks seem obvious. Additionally, it makes one wonder how many other vendors of supposedly "secure" software have been similarly approached by various Federal organizations, and how many have agreed to create the back doors as requested. Happily, the presenter said that Lotus refused to honor the FBI's request. Bravo! Dick Joltes, Manager, Networks and Hardware, Harvard University Science Center joltes at husc.harvard.edu ------------------------------ From jpp at markv.com Wed Jan 27 20:45:22 1993 From: jpp at markv.com (Jay Prime Positive) Date: Wed, 27 Jan 93 20:45:22 PST Subject: thresholding to enhance secrecy Message-ID: <9301272043.aa08979@hermix.markv.com> Summary: You can improve the secrecy of weak cypher systems by using thresholding. You can gain linear (or better) improvements for linear increase in the cyphertext size. No claim for change in signature strength is made. Thresholding is the name for a way of breaking up a peice of information into X peices so that Y <= X peices are needed to recover the information. If even Y-1 peices recovered, you still have no idea what the original information is. A simple thresholding system which requires 2 out of 2 peices to recover the original is to transform M into R and R+M where R is a random bit stream, and R+M is the same random bit stream xored with the message. Concider the weak cypher systems S1, S2, S3... where each has a probability of being 'broken' X1, X2, X3... requireing the (expected) expense of E1, E2, ... EN effort. Threshold your message P into N peices, P1, P2, P3, PN, such that all N are required to recover the message. Send S1(P1), S2(P2), S3(P3)... SN(PN). I belive that the probability of breaking this system should be (1-X1)*(1-X2)*(1-X3)* ...*(1-XN) and that the effort to break it to be E1+E2+...EN (with a smaller deviation that the sum of the deviations of Ei). This is only a linear increase in effort, but more than linear increase in the probability of secrecy. (right?) If people fear that PGP doesn't provide strong enough secrecy, we could switch to PGP^3, or even PGP^10. And if people are going to compress their messages anyway, there doesn't seem to be any good reason NOT to switch to PGP^2. There is probably a similar system which increases the strength of signatures too. Any ideas? (I suspect the naive aplication of thresholding here will DECREASE signature strength.) How about a way to *exponentialy* increase the effort and probability? Then it wouldn't matter much how weak our cyphers were! j' From hughes at soda.berkeley.edu Wed Jan 27 20:50:44 1993 From: hughes at soda.berkeley.edu (Eric Hughes) Date: Wed, 27 Jan 93 20:50:44 PST Subject: Computerized OTP (was 5th AMENDMENT & DECRYPTION) In-Reply-To: Message-ID: <9301280448.AA02108@soda.berkeley.edu> At risk of belaboring the point about random numbers, I have some more, hopefully different comments. Let me at least make the following point clear. Making random numbers is a hard problem. It is hard on the scale of designing a good cryptographic hash function. >if a real >random source is used (e.g. RF noise/static) It is unwise to conclude that a source is random merely because it looks like noise. Electrical noise is often a poor source of randomness because much noise comes from unshielded oscillators of one sort or another. Even a source based on thermal noise must be carefully designed, since solid state effects such as avalanching can generate characteristic contributions. I would suggest that everyone look and volume 2 of Knuth for the difficulty of designing pseudorandom number generators in software. Making hardware random numbers is harder than that, since it requires all that knowledge and then some. The difficulty is in knowing that your numbers are random, not in making noise. >no bit in the key stream >has any relationship to any other bit in the key stream, This is not sufficient for a stream to be random. I can have this property and still have a very non-random stream. For example, suppose I have a random stream. If for every two bits I output those two bits and their xor (sum mod 2), then no two bits have any relation to each other, but looking at bits three at a time shows awful statistics. The actual statement is that the every conditional probability that a configuration of size n occur given any other independent configuration is 1/n. In others words, every combination of bits must be independent from every other combination. This is much stronger than requiring mere bit independence. And as an aside, long runs of bits can be removed (as Scott Collins mentioned) by compression, and short configurations of bits can be removed by hashing. Eric From nowhere at bsu-cs.bsu.edu Wed Jan 27 20:51:20 1993 From: nowhere at bsu-cs.bsu.edu (Chael Hall) Date: Wed, 27 Jan 93 20:51:20 PST Subject: Remailer Changes In-Reply-To: <9301270235.AA01717@domingo.teracons.com> Message-ID: <9301280448.AA22419@bsu-cs.bsu.edu> > Why are you retaining the Subject: headder line? If I want a >Subject: line I should include inside the encrypted block. > > ||ugh Daniel > hugh at toad.com Taking Hugh's advice, I made the remailer strip subject lines from the original header. By the way, I could use a few more messages sent through here for testing. Please remember, it only gets remailed if: X-Anon-To: user at host X-Anonymously-To: user at host Request-Remailing-To: user at host Subject: Request Remailing One of the above lines *MUST* be in the header or else it won't get remailed. (it goes to my in box) Thanks. Chael Hall -- Chael Hall nowhere at bsu-cs.bsu.edu, 00CCHALL at LEO.BSUVC.BSU.EDU, CHALL at CLSV.Charon.BSU.Edu (317) 285-3648 after 5 pm EST From scott_collins at genmagic.genmagic.com Thu Jan 28 14:46:48 1993 From: scott_collins at genmagic.genmagic.com (Scott Collins) Date: Thu, 28 Jan 93 14:46:48 PST Subject: Biblio re>randomness and OT Message-ID: <9301282246.AA28614@> Subject: Biblio re>randomness and OTPs Response was sufficient to merit posting this (brief and specific) bibliography pertaining to a) randomness; b) testing for randomness; and c) compression and coding as it relates to privacy and maximizing entropy. The items are listed in the order that *I* think represents their helpfulness on this topic. Two interesting quotes from Knuth (book [1] below): (sec3.2.2 para2 p25) One of the common fallacies encountered in connection with random number generation is the idea that we can take a good generator and modify it a little, in order get and "even-more-random" sequence. (sect3.3 para4 p38) ...The point of these remarks is that we cannot be trusted to judge by ourselves whether a sequence of numbers is random or not. Some unbiased mechanical tests must be applied. Books ========== [1] "The Art of Computer Programming, vol 2: Seminumerical Algorithms" by Donald Knuth. ISBN 0-201-03822-6 Sections of interest: (3) Random Numbers [2] "Text Compression" by Bell, Cleary and Witten. ISBN 0-13-911991-4 Sections of interest: (5) From Probablilities to Bits, especially (5.2) Arithmetic Coding (7.3) Dynamic Markov Modeling (10.1.5) Privacy and Compression [3] "Adaptive Data Compression" by Ross N. Williams. ISBN 0-7923-9085-7 Sections of interest: (1.9) Arithmetic Coding (1.10.6.8) DMC (1.16) Error Correction, Data Compression and Cryptography [4] "Image and Text Compression" edited by Storer. ISBN 0-7923-9243-4 Sections of interest: (4) 'Practical mplementations of Arithmetic Coding' by Howard and Vitter. Papers ========== [5] "A note on the DMC data compression scheme" by Bell and Moffat. [6] "Universal Coding, Information, Prediction, and Estimation" by Rissanen. [7] "Linear Time Adaptive Arithmetic Coding" by Moffat. [8] "A Simple General Binary Source Code" by Langdon and Rissanen. [9] "An overview of the basic principles of the Q-Coder adaptive binary arithmetic coder" by Pennebaker, Mitchell, Langdon and Arps. [10] "Software implementations fo the Q-Coder" by Mitchell and Pennebaker. [11] "Optimal hardware and sofware arithmetic coding procedures for the Q-Coder" by Mitchell and Pennebaker. [5] "Probability estimation for the Q-Coder" by Pennebaker and Mitchell. I hope you find this information helpful. Scott Collins (Scott_Collins at genmagic.com) From USTAI%MEMSTVX1.bitnet at CUNYVM.CUNY.EDU Thu Jan 28 21:22:56 1993 From: USTAI%MEMSTVX1.bitnet at CUNYVM.CUNY.EDU (Fan Li TAI) Date: Thu, 28 Jan 93 21:22:56 PST Subject: is this true??? Message-ID: <9301290522.AA17978@toad.com> Hiya.... I found this post in a newsgroup that I try to follow. Don't know about etiquette about how this should have been edited, so it's all here, headers and all. Anyway, I would like to know if the info is accurate, bull or what? FYI, the ISA means Internal Security Act (back in Malaysia) and they have had UUCP for a few years (but UUCP's hardly enough for the kinds of traffic they are talking about, but then a few private companies *did* have full Internet, so..... it's possible that the "thingy" was there without public knowledge.... ________begin reposting________ X-NEWS: msuvx1 soc.culture.asean: 11533 Relay-Version: VMS News - V6.1B5 17/9/92 VAX/VMS A5.5-2; site memstvx1.memst.edu Path: memstvx1!cs.utk.edu!gatech!swrinde!zaphod.mps.ohio-state.edu!darwin.sura.n et!haven.umd.edu!uunet!mcsun!fuug!anon Newsgroups: soc.culture.asean Subject: ?? Electronic Monitoring ?? [The article] Message-ID: <1993Jan20.211138.20587 at fuug.fi> From: an3284 at anon.penet.fi (legend) Date: Wed, 20 Jan 1993 19:40:25 GMT Sender: anon at fuug.fi (The Anon Administrator) Organization: Anonymous contact service X-Anonymously-To: soc.culture.asean Lines: 181 sorry about the previous post. The mailer cut off everything after any "--" line, which I used to separate the forwarded message. Here'e the complete message. legend. In article <1993Jan20.041347.19567 at husc3.harvard.edu>, on at husc.harvard.edu writes: |> |> Now with Malaysia officially on Internet, I wonder if the ISA patrol |> will be monitoring this (and maybe s.c.malaysia) newsgroup. If so, then |> I guess there'll be no more criticizing the government -- that could |> get you detained without a trial. And since posting here could be |> interpreted as publishing, I guess there'll be no more talk on "sensitive" |> issues or you'll be in hot soup under the Seditions Act. Of course, now |> we can't talk about freedom or basic human rights either because Mr. |> what's-his-name here has declared that it has no place in Malaysian |> society; therefore it has no place in s.c.a or s.c.m too! |> |> SIGH! Soc.culture.asean will never be quite the same again... But hey, |> look on the bright side... we can always talk about food. |> |> Goodnight... |> |> Ahmad Zulqarnain b. Che On GO HOOSIERS!! |> on at husc.harvard.edu NO MORE DOOK... NO MORE DOOK... NO MORE DOOK ! When in doubt, assume they will (or for that matter, have been). In fact, Malaysia has *ALWAYS* been capable of monitoring Usenet news since a long time ago, since Malaysia has long been connected via UUCP, which is capable of providing a news feed. Included below is an article that appeared in alt.bbs.allsysop. It's source has NOT been validated. It is included here for your pondering only. PLEASE TREAT IT ONLY AS A RUMOR UNTIL THERE IS EVIDENCE. The possibility of the scenerio described in the article happening is up for debate. Again, the article is included for discussion purposes only. Please use your own discretion in deciding the truthfulness/falsefulness of the content. I am only forwarding an article that appeared in another newsgroup. This article was NOT originated from me. legend. ************************************************************************ * ************************************************************************ * *** ** * *** IF YOU WISH TO QUOTE/RE-QUOTE PART/ALL OF THE FOLLOWING ARTICLE, ** * *** PLEASE ALWAYS INCLUDE THIS DISCLAIMER/WARNING WITH IT. THANKS. ** * *** ** * *** The following article appeared in alt.bbs.allsysop in ** * *** September '92 and is re-post here without permission. ** * *** It has been included here for DISCUSSION PURPOSES ONLY. ** * *** The validity of the information included has NOT BEEN ** * *** VERIFIED. The reader should at best treat it as a RUMOR ** * *** at this point, and conduct his/her own investigation if ** * *** felt necessary. ** * *** ** * ************************************************************************ * ************************************************************************ * ORIGINAL POST FOLLOWS: Newsgroup: alt.bbs.allsysop In article <1992Sep30.033757.24139 at bnlux1.bnl.gov>, foxworth at bnlux1.bnl.gov (Bob Foxworth) writes: |> |> The following message was received over our local Amateur Radio TCP/IP |> VHF Radio network on 26 Sept. It came there from the Amateur AX.25 protocol |> Packet Radio network, the originating radio BBS station (at Canton Ohio) |> entered it into the Amateur packet network on 16 Sept. I am passing it |> on "as received". I am not vouching for, nor am I disclaiming any statements |> in this message. I hope it is not a repeat of anything...any replies, post |> to the net, not to me. I tried to post it 3 days ago but it never |> appeared here. It did also go to a moderated group who rejected it, however. |> |> [begin included tex] |> - From n8ecw%kc2fd at kc2fd.ampr.org Sat Sep 26 14:05:28 1992 |> - Received: from n2mdq.ampr.org by k2euh.ampr.org with SMTP |> id AA9736 ; Sat, 26 Sep 92 13:59:54 UTC |> - Received: from kc2fd.ampr.org by n2mdq.ampr.org |> - (n2mdq at n2mdq.ampr.org) with SMTP |> - id AA10034 ; Tue, 22 Sep 92 13:49:44 UTC |> - Date: 26 Sep 92 13:51:00 UTC |> - Message-Id: <6087 at kc2fd.ampr.org> |> - From: n8ecw at kc2fd.#nli.ny.usa.na |> - To: nli at n2mdq |> - Subject: CP KC2FD: BBSs, Privacy, and You! |> - X-BBS-Msg-Type: P |> - Status: R |> |> - R:920926/1351Z @:KC2FD.#NLI.NY.USA.NA [Coram, LI, NY] FBB5.14d #:18091 |> |> - From: N8ECW at KC2FD.#NLI.NY.USA.NA |> - To : NLI at N2MDQ |> |> - Original from N8ECW to ALL at USBBS |> - R:920926/0848Z @:N2BQF.#NLI.NY.USA.NOAM [Copiague] FBB5.14d TELINK #:18005 |> - intermediate headers deleted |> - R:920916/1944z @:KA8Z.OH.USA Canton, Oh. #:26846 Z:44705 |> |> I found the following message on a land line BBS. Since many packet users |> also have modems and call land line BBSs, and many sysops also run such |> BBSs I think that the information in the following message is something |> we should all be aware of. |> |> *** |> |> As someone involved in the telephone industry on the level of security |> and data integrity... I would like to inform everyone that uses modems |> and/or are bbs operators of some information. |> |> The first thing that everyone that uses a modem should know is that |> every time you fire up your modem your activating monitoring equipment |> somewhere in the U.S. I have worked for several large telephone |> networks that routinely monitor and reroute modem and fax transmissions |> through devices that allow them to view what is being transmitted and |> even decodes encrypted data and fax packets used by major corporations |> and governmental agencies. This is allowed under the heading of |> "Maintenance Monitoring" and may be continued for up to 6 months without |> the need of any legal paperwork being generated. Under an obscure |> pre-WWII ruling by the agency that is now the FCC... "No information may |> be encoded or transmitted over PUBLIC or PRIVATE forms of telephony or |> radio with the exception of those agencies involved in the National |> Security" a further designation goes on to say "with the exception of |> the MORSE system of 'transmittal', any communication that is not |> interpretable by the human ear is forbidden and unlawful." |> |> The information gathered goes to 3 seperate database facilities...1 is |> codenamed Diana and is located in Brussels, the 2nd is named Fredrick |> and is located somewhere in Malaysia, the 3rd is named Elizabeth and is |> located in Boulder, Colorado. The information stored in these systems |> is accessable by the US Government, Interpol, Scotland Yard and various |> other such agencies. Your credit rating is also affected by your modem |> usage... if you ever get a copy of your credit history and find a |> listing that has HN06443 <--= this is a negative risk rating. or a code |> 87AT4 <---= an even more negative risk rating.... these will usually |> have no description on them... and if you inquire about them they will |> tell you that it just comes from the system that way. |> |> I am currently working for another major carrier as a consultant and |> have been able to watch these systems operate...at one unnamed long |> distance carrier here in Columbus Ohio in their NCC, Network Control |> Center, you can see several rows of computer terminals which have |> approximately 30 to 40 separate windows in each... these windows have |> data transmissions that are being monitored... banks of 9 track tapes |> are going constantly to record everything. Everyone should realize that |> even if a sysop posts a disclaimer at the beginning of his bbs about no |> access to governmental agencies or law enforcement...that it isn't worth |> the time it takes to type it in... looking forward to hearing reactions |> to this. |> |> ****** |> |> I apologize for the length of this message, but it's information that I |> feel is important, especially for any land-line BBS sysop. Anytime you |> enter a message, even if it's private, always do it with the assumtion |> that it's going to be seen by anyone and everyone, everywhere. |> |> Tnx |> 73s |> de Tom, N8ECW at KA8Z.#NEOH.OH.USA.NA |> [end included message] |> Standard disclaimers apply. My employer, above, has no connection or |> responsibility with anything I say or relay here. Of course. ------------------------------------------------------------------------- To find out more about the anon service, send mail to help at anon.penet.fi. Due to the double-blind system, any replies to this message will be anonymized, and an anonymous id will be allocated automatically. You have been warned. _______________________________________________________________________________ |___ ___ _____ ___ ___ | User Services, Room 134, Adm Bldg| || \/ | / ____\ | | | | Fan Li TAI | Memphis State University | || \ / | \____ \ | |_| | Campus Box 528039 | Internet: USTAI at MSUVX1.MEMST.EDU | ||_|\/|_| \_____/ \_____/ Memphis, TN 38152 | Bitnet : USTAI at MEMSTVX1 | |___________________________________________|__________________________________| From phiber at eff.org Fri Jan 29 00:19:39 1993 From: phiber at eff.org (Phiber Optik) Date: Fri, 29 Jan 93 00:19:39 PST Subject: Is this true??? Message-ID: <199301290818.AA18130@eff.org> That last message containing info on purported phone company monitoring activities was the biggest load of propagandist bullshit I think I've seen in a long time. I'm sure it generated the expected fear and paranoia amongst more ignorant people. From miron at extropia.wimsey.com Fri Jan 29 04:11:48 1993 From: miron at extropia.wimsey.com (Miron Cuperman) Date: Fri, 29 Jan 93 04:11:48 PST Subject: ARA security Message-ID: <1993Jan29.105734.1737@extropia.wimsey.bc.ca> -----BEGIN PGP SIGNED MESSAGE----- Proposition 1: All remailing schemes are vulnerable in the case that all remailing sites in the chain are compromised before transmission. Proposition 2: With ARAs and direct transmission (one recipient at each hop), if the first n-1 hosts in a chain are compromised then the n_th host identity is known. If all hosts are compromised, the originator is known. Corollary 1: Direct-transmission ARAs are vulnerable to an adversary that can compromise any small subset of all hosts. This is done by sequentially compromising the next host, and using that information to find the identity of the next host after that. No amount of "random" routing has any effect in this case, since the randomness is implemented by each host, but each host is compromised before it makes the delivery. Proposition 3: Normal anonymous transmission (not ARA) is "unconditionally" secure after *one* passage through an uncompromised host, assuming no traffic analysis and no log files. (With log files, normal transmission is as insecure as direct-transmission ARAs.) Therefore, it seems like direct-transmission ARAs are much less secure than normal anonymous transmission. For better security, we must find some other ARA scheme. A proposal: broadcast ARAs and Message Pools - -------------------------------------------- All messages to a message pool are sent to all subscribers to the pool. Messages to the pool are encrypted with the (pseudonymous) public key of the recipient. The ARA can thus belong to any of the subscribers to the pool. The connection between public keys and subscribers is not maintained anywhere. The subscribers have attempt decryption of messages marked with their pseudonyms. Once the key of a subscriber is destroyed, it is not possible to prove that any message was destined for that subscriber, affording a last resort to a subscriber suspecting that an attack is in progress. Pools must have a large number of subscribers in case it is possible to compromise the key of any particular subscriber. Pools can be implemented as Usenet groups for a low-cost delivery medium. Each pool should be geographically limited in order to further minimize costs (the Distribution: header works well here). If costs are minimized, the pools can be increased, affording better security. For experimental, low-volume tests, mailing lists can be used. - -- Miron Cuperman | NeXTmail/Mime ok | Public key avail AMIX: MCuperman | cyberspacecomputingcryptoimmortalitynetworkslaissezfaire -----BEGIN PGP SIGNATURE----- Version: 2.1 iQCVAgUBK2j60ZNxvvA36ONDAQFKiAP+JFWWeke6rADXFfK4d4LPHNUWJ9NwcjH4 5XDC+Veg8h3JgwSQ7f0J8JM9LqwbHBWHObm4bPJKeBa1fSIP2L8xNMsA0dQnriwE EWVR6oUPy3ANMefEa9CHMS+bkOnuGRXV4Ntsi6Eh1kLyK340jUheWKjVMtWl37Cb d9qe12GqSlU= =LHSz -----END PGP SIGNATURE----- From dsinclai at acs.ucalgary.ca Fri Jan 29 05:02:48 1993 From: dsinclai at acs.ucalgary.ca (Douglas Sinclair) Date: Fri, 29 Jan 93 05:02:48 PST Subject: Radio-isotope OTP generators Message-ID: <9301291302.AA49310@acs1.acs.ucalgary.ca> I got some mail from someone on the list who told me that about a year ago there had been much discussion of radio-isotope OTP random number generators, and that the conclusion had been that they were too dangerous to use. I replied to that message, but my reply bounced for some reason. So, could anybody please send me a synopsis of the discussion? Thanks. I was talking to my father about this, and we concluded that a simple exposed- silicon photodiode put in reverse bias should provide adequate detection. Put it in darkness, and no current will flow. Hit it with and alpha, and you get a cascade on the order of a million electrons. The alpha source need only be some radium paint on the front of the diode. This is not dangerous stuff. You'd have to go very far out of your way to do yourself any damage with it. If you eat it then bad things might happen, but I can say the same thing about AA batteries... My father designs and builds particle detectors for a living, so he probably knows what he's talking about. BTW: one error in my last message. There is not Californium in a smoke detector, it is Amerecium. Same difference... -- Vercotti: I was terrified of him. Everyone was terrified of Doug. I've seen grown men pull their own heads off rather than see Doug. Even Dinsdale was frightened of Doug. Interviewer: What did he do? Vercotti: He used sarcasm. He knew all the tricks, dramatic irony, metaphor, bathos, puns, parody, litotes and satire. -- Monty Python, Episode 14 PGP 2.1 Key by finger From sDun at isma.demon.co.uk Fri Jan 29 05:20:25 1993 From: sDun at isma.demon.co.uk (Stephen Dunne) Date: Fri, 29 Jan 93 05:20:25 PST Subject: The FBI and Lotus cc:Mail Message-ID: <728328337snx@isma.demon.co.uk> In article ** unknown ** you write: >An interesting tidbit came to light while I was attending a demonstration of >Lotus' cc:Mail and Notes products at the Boston NetWorld this month. During >the Notes portion of the presentation someone asked how secure the information >in the various databases was, and how the encryption was done. > > Blah Blah Blah > >Happily, the presenter said that Lotus refused to honor the FBI's request. >Bravo! > >Dick Joltes, Manager, Networks and Hardware, Harvard University Science Center >joltes at husc.harvard.edu I suppose that really means "Lotus *said* they refused to honour it.." Paranoid? Moi !? Stephen -- +--------------------------------------------------------------------------+ |Stephen Dunne DoD#767 sdun at isma.demon.co.uk | |International Securities Market Association I speak for me,thats all| |Voice (+44) 71-538-5656 Fax (+44) 71-538-4902 PGP 2.1 key available | |We are not affiliated to any other Demon.Co.Uk site. (especially Evil!) | +--------------------------------------------------------------------------+ From hal at alumni.cco.caltech.edu Fri Jan 29 09:54:50 1993 From: hal at alumni.cco.caltech.edu (Hal Finney) Date: Fri, 29 Jan 93 09:54:50 PST Subject: OTP Generators Message-ID: <9301291755.AA08021@alumni.cco.caltech.edu> Douglas Sinclair asked about the earlier discussion re the use of radiation to generate true random numbers for one time pads. The problem, as I recall, was with the quantity of bits needed. OTP's eat bits like crazy. People have talked about filling CD-ROM's or other optical media with hundreds of megabytes or even gigabytes of random numbers. Now, the problem is how long it will take to produce that much random data. A few bits per second won't be fast enough. Suppose you wanted to produce 100 megabytes per day (which would take over a week to create a gigabyte). That requires about 10,000 random bits per second. Now, your detector is not going to be 100% efficient. Only a certain fraction of the emitted particles are going to be detected. So you will need more decays than this, possibly many more. Also, relying on a half-life calculation in which we wait a certain time interval, and see if there is a decay or not, won't be that accurate. If your time is off a little, it could bias the results. Tim May posted the best (IMO) fix for this. You collect bits in pairs; discard 00 and 11; for each 01 output a 0, for each 10 output a 1. This way even if there is a bias where, say, 60% of the bits are 0's and 40% are 1's you still get 50-50 0's and 1's out. This means you get about 1 output bit for each 4 inputs, so you have to increase the necessary decay rate by a factor of 4. So, the needed particle emission rate is 40,000 divided by the efficiency of your detector. Perhaps Douglas could get some efficiency figures from his father, and judge whether this rate of radiation emission would be safe. Hal Finney 74076.1041 at compuserve.com {. From elee9sf at Menudo.UH.EDU Fri Jan 29 10:03:47 1993 From: elee9sf at Menudo.UH.EDU (Karl Barrus) Date: Fri, 29 Jan 93 10:03:47 PST Subject: digital banking Message-ID: <199301291802.AA15702@Menudo.UH.EDU> -----BEGIN PGP SIGNED MESSAGE----- Cypherpunks, It looks like a few people are trying out the bank...but there is only so much you can try as a single user...so there needs to be a way to contact other bank users and remain anonymous. Being able to contact other bank users will allow bank customers to conduct real transactions, etc. So, what I plan to do is create a remailing header using my remailer's public key for everyone who uses the bank. I will send the appropriate remailing header to each user, which can then be attached to correspondence between bank customers. Then, each user can be contacted via an anonymous remailer (mine) and the remailing header. Following that I will send to each user the total list of remailing headers, so each bank customer will be able to contact the other bank customers. Then, each user can contact the other users, and include their own remailing header to receive responses. Right now we're just experimenting so I'd like the bank customers to be able to interact with each other. How does this system sound? I'd like to hear any comments about the bank or ways the bank's customers may transact with each other (preferably privately). Also, a few weeks ago, maybe even two months, someone posted anonymously :-) that they were nearly complete with an implementation of Chaum's digitcal cash (RSA encryption, decryption, blinded signatures, etc.) scheme. I'd like to hear from that person the status of their project, and whether it is feasible to incorporate their code into my bank server. Remain anonymous if you prefer, and include a remailing header so I can write you back. Incorporating Chaum's method, and cypherpunk-style remailers to conduct business with the bank are two of my goals for this project. /-----------------------------------\ | Karl L. Barrus | | elee9sf at menudo.uh.edu | <- preferred address | barrus at tree.egr.uh.edu (NeXTMail) | \-----------------------------------/ -----BEGIN PGP SIGNATURE----- Version: 2.1 iQCVAgUBK2lw84OA7OpLWtYzAQE67gP8DHXoSmvacMO4BlSMFDRwpf9rifEpbwqS Z8IocT5PnAsxhHY407KfKj6KQKT6WhZZ/zxDnm8UCWynwCXYAw8ASn6lqzKWW4Ds 7S9Gdnxv4ue12WqCZIFXF/Lg1AKXMch2q9IF/UN9Tx6b2n2r+IS+D+Gm7XTCksuR 5EP+Qtqhagg= =ox9u -----END PGP SIGNATURE----- From hal at alumni.cco.caltech.edu Fri Jan 29 10:05:55 1993 From: hal at alumni.cco.caltech.edu (Hal Finney) Date: Fri, 29 Jan 93 10:05:55 PST Subject: Remailer abuse? Message-ID: <9301291807.AA08440@alumni.cco.caltech.edu> When the Pax remailer was shut down, I stopped keeping any logs of my remailer operation. I felt that I did not want to provide information that would be helpful to those forces which oppose information privacy. So, I don't know the history of it, but today I received this message: To: hal at alumni.cco.caltech.edu Subject: Re: what you said you wanted I am shocked that you would send such trash to innocent young girls, whom you don't even know (Not that it is better if you know them) Well, I am appalled!!! Why me?? Is someone using my remailer to send trash to innocent young girls? I am uncomfortable to be facilitating this kind of activity. Can anyone offer suggestions for the ethical thing to do in this situation? Hal 74076.1041 at compuserve.com From tcmay at netcom.com Fri Jan 29 10:29:42 1993 From: tcmay at netcom.com (Timothy C. May) Date: Fri, 29 Jan 93 10:29:42 PST Subject: OTP Generators Message-ID: <9301291826.AA15886@netcom3.netcom.com> Hal Finney writes: > Douglas Sinclair asked about the earlier discussion re the use of > radiation to generate true random numbers for one time pads. > > The problem, as I recall, was with the quantity of bits needed. OTP's ...stuff elided... > So, the needed particle emission rate is 40,000 divided by the > efficiency of your detector. Perhaps Douglas could get some efficiency > figures from his father, and judge whether this rate of radiation > emission would be safe. Yes, we've discussed this a couple of times. For a 2 pi detector geometry, about 100,000 decays per second are needed to give the 40,000 or so that the detector could see. This is about 3 microcuries (1 curie = 3.7 x 10^10 disintegrations per second), which is far higher than the Am-241 smoke detector sources have (0.1 microcurie, if I remember correctly...but I could be wrong on this, as it's been years...). (There's also the issue of detector drift, with such high levels causing changes in the detector properties.) Obviously, multiple detectors could be used, each generating perhaps several thousand bits pers second. It'll still take a week or so to fill a single CD-ROM. Not too practical. Nor is the production and distribution of CD-ROMS very convenient. Using this for "Cypherpunks"-type activities would be a nightmare of inconvenience for all concerned. -Tim -- .......................................................................... Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay at netcom.com | anonymous networks, digital pseudonyms, zero 408-688-5409 | knowledge, reputations, information markets, W.A.S.T.E.: Aptos, CA | black markets, collapse of governments. Higher Power: 2^756839 | Public Key: waiting for the dust to settle. -- .......................................................................... Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay at netcom.com | anonymous networks, digital pseudonyms, zero 408-688-5409 | knowledge, reputations, information markets, W.A.S.T.E.: Aptos, CA | black markets, collapse of governments. Higher Power: 2^756839 | Public Key: waiting for the dust to settle. From ld231782 at longs.lance.colostate.edu Fri Jan 29 10:41:07 1993 From: ld231782 at longs.lance.colostate.edu ( L. Detweiler ) Date: Fri, 29 Jan 93 10:41:07 PST Subject: Is this true??? In-Reply-To: <199301290818.AA18130@eff.org> Message-ID: <9301291840.AA29938@longs.lance.colostate.edu> >That last message containing info on purported phone company monitoring >activities was the biggest load of propagandist bullshit I think I've seen >in a long time. >I'm sure it generated the expected fear and paranoia amongst more ignorant >people. This is not a constructive comment. What is your evidence that it is false? We should dissect the claims. |>Under an obscure |> pre-WWII ruling by the agency that is now the FCC... "No information may |> be encoded or transmitted over PUBLIC or PRIVATE forms of telephony or |> radio with the exception of those agencies involved in the National |> Security" a further designation goes on to say "with the exception of |> the MORSE system of 'transmittal', any communication that is not |> interpretable by the human ear is forbidden and unlawful." This kind of stuff seems to happen whether there are laws sanctioning it or not, but does anyone know what law is being referenced? On a general note, what would tend to validate/rebut the claim? First of all, the simple feasibility of such an operation must be called into question. There is a tremendous amount of data going over modems on public telephone lines. What is the chance that even a small fraction could be monitored? (And an even more infinitesmal fraction archived.) The claim has appeared here before that it is "trivial" for a government agency to scan for interesting keywords and sort the data based on that. But I think that even that would lead to loads of irrelevant crap and require an army of intelligence agents to sort. Where is this army? Also, the claims in the letter are referring to public telephone networks. Would this include all the networks comprising the Internet? If so, this multiplies the data volume immensely. How could anyone find anything useful in these massive streams? Granted, *very* sensitive information is probably contained within it, but how the heck could it be found efficiently? |> Your credit rating is also affected by your modem |> usage... if you ever get a copy of your credit history and find a |> listing that has HN06443 <--= this is a negative risk rating. or a code |> 87AT4 <---= an even more negative risk rating.... these will usually |> have no description on them... and if you inquire about them they will |> tell you that it just comes from the system that way. These claims that credit ratings are influenced by this secret information are rather questionable. What is the path from the decision to mark a record with a black mark to the private companies like TRW that record this? Which clients or sources of TRW or whatever are specifically those that monitor secret information? What exactly does he mean, "your credit rating is affected by your modem usage?" If anyone could refute or demonstrate the actual meaning of HN06443 and 87AT4 codes on credit reports (I've never seen a report or these codes), this would be a specific item to discredit, which would call into question the whole of the claims. |> The information gathered goes to 3 seperate database facilities...1 is |> codenamed Diana and is located in Brussels, the 2nd is named Fredrick |> and is located somewhere in Malaysia, the 3rd is named Elizabeth and is |> located in Boulder, Colorado. The information stored in these systems |> is accessable by the US Government, Interpol, Scotland Yard and various |> other such agencies. Regarding the claim that one major monitoring hub is code named "elizabeth" in Boulder Colorado. There is a government standards agency there, if I am not mistaken, I forget if it is NIST (?). Also, the National Center for Oceanic Research, which has very tremendous computing power (e.g. Cray YMP) is there also. In their tours they show massive archival storage areas, which they say record major amounts of global atmospheric data (e.g. temperatures, wind currents etc.) collected from satellites. These could conceivably be in part "covers" but the idea is also rather unimaginable. Can anybody report on agencies in the areas cited? There is the very specific claim of a carrier in Columbus Ohio. I propose that cypherpunks list be a central reporting place for what might be called "public counter spies" who report on the illicit activities of our governments. Its already largely in that area. If we get enough expertise, nonradicals, and infiltrators here we may be able to get better ideas of what the heck NSA really is doing, what kind of monitoring is really going on, what kind of cryptographic techniques can really be broken, etc. From julf at penet.FI Fri Jan 29 11:14:07 1993 From: julf at penet.FI (Johan Helsingius) Date: Fri, 29 Jan 93 11:14:07 PST Subject: Remailer abuse? In-Reply-To: <9301291807.AA08440@alumni.cco.caltech.edu> Message-ID: <9301292044.aa10755@penet.penet.FI> > When the Pax remailer was shut down, I stopped keeping any logs of my > remailer operation. I felt that I did not want to provide information > that would be helpful to those forces which oppose information privacy. > Is someone using my remailer to send trash to innocent young girls? > I am uncomfortable to be facilitating this kind of activity. Can anyone > offer suggestions for the ethical thing to do in this situation? Well, you can't have your cake and eat it. I do know the dilemma you are facing, as I have to face the issue pretty regularily. Either you just provide the service without any regard for the contents, or keep logs and play police every now and then. With anon.penet.fi the choice is simple because the way the server works - there has to be a database mapping anon id's to real addresses, and anyway it is possible to flame orginators of abusive stuff without even knowing their true identity. But in the general case it is a pretty complicated ethical issue... Julf From strick at osc.versant.com Fri Jan 29 11:16:40 1993 From: strick at osc.versant.com (henry strickland) Date: Fri, 29 Jan 93 11:16:40 PST Subject: Remailer abuse? In-Reply-To: <9301291807.AA08440@alumni.cco.caltech.edu> Message-ID: <9301291920.AA13347@versant.com> # From cypherpunks-request at toad.com Fri Jan 29 10:57:37 1993 # From: hal at alumni.cco.caltech.edu (Hal Finney) # Date: Fri, 29 Jan 93 10:07:37 PST # Message-Id: <9301291807.AA08440 at alumni.cco.caltech.edu> # To: cypherpunks at toad.com # Subject: Remailer abuse? # # Is someone using my remailer to send trash to innocent young girls? My guess: no. Just a guess, but based on the way it was worded and what troublesome forgeries frequently look like and say, I would bet that the message to you about the alleged trash was forged, and is not responding to any such event. strick strick at osc.versant.com henry strickland From hughes at soda.berkeley.edu Fri Jan 29 11:36:05 1993 From: hughes at soda.berkeley.edu (Eric Hughes) Date: Fri, 29 Jan 93 11:36:05 PST Subject: is this true??? In-Reply-To: <9301290522.AA17978@toad.com> Message-ID: <9301291933.AA03094@soda.berkeley.edu> The piece about widespread worldwide modem monitoring has one notable difference from most similar pieces: the presence of a bit of falsifiable information, namely the credit history codes HN06443 and 87AT4. Anybody know how to find an authoritative source for independent verification of this data? Eric From hughes at soda.berkeley.edu Fri Jan 29 11:48:07 1993 From: hughes at soda.berkeley.edu (Eric Hughes) Date: Fri, 29 Jan 93 11:48:07 PST Subject: thresholding to enhance secrecy In-Reply-To: <9301272043.aa08979@hermix.markv.com> Message-ID: <9301291945.AA03526@soda.berkeley.edu> It seems that your "thresholding" schemes require an increase in message size. Do I read this correctly? It also seems that you need to generate one time pads to effect this increase in message size, with all the attendant costs of making that quantity of random bits. Eric From eichin at ATHENA.MIT.EDU Fri Jan 29 12:43:44 1993 From: eichin at ATHENA.MIT.EDU (Mark W. Eichin) Date: Fri, 29 Jan 93 12:43:44 PST Subject: a "real world" anonymous service Message-ID: <9301292042.AA07489@tsx-11.MIT.EDU> Here's an interesting anonymous service that is almost in the real world (at least in the sense that Cable TV in general is more mainstream than most of what we do...) _Mark_ File: /afs/athena.mit.edu/activity/s/sctv/CROSSLINK.info What is CROSSLINK? ------------------ CROSSLINK is an anonymous message system run on MIT Student Cable TV-36. It provides an anonymous medium through which MIT students can say those things they might otherwise find difficult, inconvenient or impossible to say in person. It's also a way to send fun or totally random messages to your friends over the air. It is similar to the anonymous message pages found in many college newspapers, except that it's electronic in nature and it's free. What kind of messages can I put on CROSSLINK? --------------------------------------------- You can say whatever you want. Get out your frustration. Break the ice with that person you're too shy to approach. Try and re-establish contact with the unknown person you saw last night. Anything. Well, almost anything; CROSSLINK is bound by the rules prohibiting harassment at MIT. Please don't use racial, sexual, or gender-based slurs, because your message won't be run. You can say a lot without getting really nasty or lewd about it. Also, we won't run commercial or group advertisements. CROSSLINK is intended to be a personal messaging system, not a billboard. You can choose to sign your message however you wish (or not at all), but the recipient must not be identified by name. For instance, "E.M.", "that guy with the crewcut", or "the loser behind me in 6.002" are all perfectly acceptable ways to name your recipient, but "Eric McDonald" and "E. McDonald" are not. How often is CROSSLINK on the air? ---------------------------------- CROSSLINK is on MIT Channel 36 whenever there's empty air time. We don't have 24-hours of non-stop student programming every day, and we aren't always able to "hijack" the satellite signal, so CROSSLINK should be on most of the time. Who will see CROSSLINK? ----------------------- With over 4,000 cable outlets on and around campus, many many people can see your message on CROSSLINK. How long do CROSSLINK messages run? ----------------------------------- Unless you otherwise request, CROSSLINK messages will be run for about two days. How do I submit a message to CROSSLINK? --------------------------------------- You can drop off your message in one of two ways: 1) Write it down, fold the paper, write "CROSSLINK" on the outside, and slide it under the door to room 9-026 (or send it via inter- departmental mail). 2) Send it by email to crosslink at athena.mit.edu. We promise we won't make a note of who sent what message, and we'll erase all email after we've written down the messages. If you don't trust us, you can: use method #1, send it as root, or find a fake mail sender (but it's really not necessary). We're working on other means of delivery, but that's it for now. Remember: you may sign your message however you wish, and you need not sign it at all. For more information -------------------- This type of service is run successfully at colleges all over the country, and it can be fun to read the messages some people leave. If you want to find out more about CROSSLINK, please send email to crosslink at athena.mit.edu. - Eric McDonald CROSSLINK Manager From geoffw at nexsys.net Fri Jan 29 12:43:55 1993 From: geoffw at nexsys.net (Geoff White) Date: Fri, 29 Jan 93 12:43:55 PST Subject: Is this true??? Message-ID: <9301292031.AA01091@nexsys.nexsys.net> > are specifically those that monitor secret information? What exactly > do> Regarding the claim that one major monitoring hub is code named > "elizabeth" in Boulder Colorado. There is a government standards > agency there, if I am not mistaken, I forget if it is NIST (?). Also, > the National Center for Oceanic Research, which has very tremendous > computing power (e.g. Cray YMP) is there also. In their tours they > show massive archival storage areas, which they say record major > amounts of global atmospheric data (e.g. temperatures, wind currents > etc.) collected from satellites. These could conceivably be in part > "covers" but the idea is also rather unimaginable. Can anybody report > on agencies in the areas cited? There is the very specific claim of a > carrier in Columbus Ohio. > Well to add more paranoid fuel to the fire, it is no secret that there is a lot of "intelligence" activity around the boulder/colorodo springs area. But I don't think this alone is enough to prop up or refute this claim. The most damageing part of the story IMHO is the line about the 9 track tapes going :) Get real! Now Banks of Hi-8 maybe ... From gnu Fri Jan 29 13:03:42 1993 From: gnu (John Gilmore) Date: Fri, 29 Jan 93 13:03:42 PST Subject: Privacy Enhanced Mail proceeds to Proposed Standard Message-ID: <9301292103.AA11818@toad.com> ------- Forwarded Message To: Jon Postel -- RFC Editor To: IETF-Announce:;@CNRI.Reston.VA.US at TIS.COM Cc: Internet Architecture Board Cc: pem-dev at TIS.COM Cc: The Internet Engineering Steering Group From: IESG Secretary Subject: Protocol Action: Privacy Enhanced Mail to Proposed Standard Date: Fri, 29 Jan 93 14:29:02 -0500 Message-Id: <9301291429.aa07535 at IETF.CNRI.Reston.VA.US> The IESG has approved the Privacy Enhanced Mail Protocols as a Proposed Standard. These protocols are defined in the Internet Drafts: o "Privacy Enhancement for Internet Electronic Mail: Part I: Message Encryption and Authentication Procedures" o "Privacy Enhancement for Internet Electronic Mail: Part II: Certificate-Based Key Management" o "Privacy Enhancement for Internet Electronic Mail: Part III: Algorithms, Modes, and Identifiers" o "Privacy Enhancement for Internet Electronic Mail: Part IV: Key Certification and Related Services" These documents are the product of the Privacy-Enhanced Electronic Mail Working Group. The IESG contact person is Steve Crocker. Technical Summary The PEM specifications have been under development for almost 6 years. During that time, parts of the specifications have been published, revised and republished, with each new publication including corrections and enhancements commensurate with the experience obtained from implementations and continued deliberations. The specifications have not changed dramatically since March 1992; they are technically sound and consistent with the internet architecture and the anticipated internet security architecture. This protocol opens the door for widespread use of cryptography throughout the Internet which will result in greatly increased security for mail traffic. This protocol is of premier importance in the Internet and will facilitate transition of the Internet to a robust, commercially acceptable medium. The approach chosen in the design of this protocol is to use the public key infrastructure defined in X.509 and encapsulation of messages within the RFC 822 protocol. This approach makes full use of the prior work in the CCITT and ISO community, and it fits cleanly into the existing mail model. There are two difficulties with the approach taken in this design. The articulation of boundaries and parameters is particular to the use of PEM within the RFC 822 mail protocol. MIME includes general facilities for these functions. It would be preferable for this protocol to be aligned with MIME. MIME was not available at the time this protocol was designed, so it is proceeding separately. See below for additional comments on the alignment of MIME and PEM. The certificate infrastructure is large and awkward to bring into existence. It will pay off enormously in this and future protocols because it provides an organized framework for establishing trusted identification and binding of identities to public keys. However, it is not easy to initiate and necessarily slows the deployment and adoption of PEM. Neither of these difficulties affect the soundness of the PEM design. In the current milieu, it is important to deploy this protocol and deal with the difficulties over a period of time. THE DOCUMENTS o Part 1, Message Encryption and Authentication Procedures This document defines message encryption and authentication procedures, in order to provide privacy-enhanced mail (PEM) services for electronic mail transfer in the Internet. It is intended to become one member of a related set of four RFCs. The procedures defined are intended to be compatible with a wide range of key management approaches, including both symmetric (secret-key) and asymmetric (public-key) approaches for encryption of data encrypting keys. Symmetric cryptography is used for message text encryption. Cryptographic hash algorithms are used for message integrity check value computation. Other documents specify supporting key management mechanisms based on the use of public-key certificates; algorithms, modes, and associated identifiers; and details of paper and electronic formats and procedures for the key management infrastructure being established in support of these services. Privacy enhancement services (confidentiality, authentication, message integrity assurance, and non-repudiation of origin) are offered through the use of end-to-end cryptography between originator and recipient processes at or above the User Agent level. No special processing requirements are imposed on the Message Transfer System at endpoints or at intermediate relay sites. This approach allows privacy enhancement facilities to be incorporated selectively on a site-by-site or user-by-user basis without impact on other Internet entities. Interoperability among heterogeneous components and mail transport facilities is supported. The current specification's scope is confined to PEM processing procedures for the RFC-822 textual mail environment. Integration of PEM capabilities with MIME and possibly other mail environments is anticipated, but the specifications are yet to be worked out. In partial anticipation of such integration, the header "Content-Domain" with value "RFC822" is included as a hook. See below for additional discussion. Part II: Certificate-Based Key Management This document defines a supporting key management architecture and infrastructure, based on public-key certificate techniques, to provide keying information to message originators and recipients. It is intended to be one member of a related set of four RFCs. The key management architecture described is compatible with the authentication framework described in CCITT 1988 X.509. This document goes beyond X.509 by establishing procedures and conventions for a key management infrastructure for use with Privacy Enhanced Mail (PEM) and with other protocols, from both the TCP/IP and OSI suites, in the future. The motivations for establishing these procedures and conventions (as opposed to relying only on the very general framework outlined in X.509) are explained in the document. The infrastructure specified in this document establishes a single root for all certification within the Internet, the Internet Policy Registration Authority (IPRA). The IPRA establishes global policies, described in this document, which apply to all certification effected under this hierarchy. Beneath IPRA root are Policy Certification Authorities (PCAs), each of which establishes and publishes (in the form of an informational RFC) its policies for registration of users or organizations. Each PCA is certified by the IPRA. Below PCAs, Certification Authorities (CAs) will be established to certify users and subordinate organizational entities (e.g., departments, offices, subsidiaries, etc.). Initially, the majority of users are expected to be registered via organizational affiliation, consistent with current practices for how most user mailboxes are provided. Some CAs are expected to provide certification for residential users in support of users who wish to register independent of any organizational affiliation. For users who wish anonymity while taking advantage of PEM privacy facilities, one or more PCAs are expected to be established with policies that allow for registration of users, under subordinate CAs, who do not wish to disclose their identities. Part III: Algorithms, Modes, and Identifiers This document provides definitions, formats, references, and citations for cryptographic algorithms, usage modes, and associated identifiers and parameters used in support of Privacy Enhanced Mail. It is intended to become one member of a related set of four RFCs. It is organized into four primary sections, dealing with message encryption algorithms, message integrity check algorithms, symmetric key management algorithms, and asymmetric key management algorithms (including both asymmetric encryption and asymmetric signature algorithms). Some parts of this material are cited by other documents and it is anticipated that some of the material herein may be changed, added, or replaced without affecting the citing documents. Part IV: Key Certification and Related Services This document describes three types of service in support of Internet Privacy Enhanced Mail: key certification, certificate revocation list (CRL) storage, and CRL retrieval. It is intended to be one member of a related set of four RFCs. The services described are among those required of a Certification Authority. Each involves an electronic mail request message and an electronic mail reply message. The request may be either a privacy enhanced mail message or a message with a new syntax defined in this document. The new syntax has a different process type, thereby distinguishing it from ordinary privacy enhanced mail messages. The reply is either a privacy enhanced mail message or an ordinary unstructured message. Replies that are privacy enhanced messages can be processed like any other privacy enhanced message, so that the new certificate or the retrieved CRLs can be inserted into the requester's database during normal privacy enhanced mail processing. Certification authorities may also require non-electronic forms of the request and may return non-electronic replies. It is expected that descriptions of such forms, which are outside the scope of this document, will be available through a Certification Authority's "information" service. THE USE OF CERTIFICATES AND PRIVATE KEYS To aid in understanding the roles of public keys, certificates and private keys, it is useful to consider four functions: - Sealing and signing a message. - Verifying the integrity and signature of a message. - Encrypting a message to ensure confidentiality. - Decrypting a confidential message. The protocols are designed so that sealing and signing are the base protocol, and encryption is an optional addition. That is, a privacy enhanced message is always signed and is only optionally encrypted. To sign a message, the sender must have a public/private key pair. The sender uses the private key to sign the message. Receivers use the corresponding public key to check the signature. With respect to the issuance and use of certificates, only the sender need have a certificate. Receivers use the sender's certificate to ascertain the sender's public key, and hence may check the integrity and authenticity of a message irrespective if whether they have a certificate. This arrangement makes it possible for a sender to sign a public message, e.g. to a newsgroup, and each recipient may check the integrity and signature of the message. License agreements for RSAREF from RSA and TIS/PEM from TIS permit the use of their software for this purpose at no cost, as long as the software is not sold. Encryption and decryption are a different matter. To send an encrypted message, each receiver must have a private/public key pair. The sender accesses the receiver's public key and encrypts the message so only the receiver can decrypt the message. Since encryption is designed as an optional additional to the integrity and signature process, the use of encryption necessarily implies both the sender and receiver have private/public key pairs. There is one exception to this rule. The PEM specifications also permit a symmetric key algorithm to be used for encryption. This is suitable for traffic between two parties who have manually exchanged keys previously. DES is the algorithm used for this purpose, and it is in the public domain. A COMMENT ON THE DECISION TO INCORPORATE PATENTED TECHNOLOGY. Some have asked whether it is necessary to incorporate a patented technology into the standard. In a very real sense, the idea of wide scale cryptography in a public, networked environment is not viable without public key technology. Public key technology opened up the field and enabled application not previously possible. Hence, the decision was not whether to choose public key technology versus some other technology. Rather, the decision was to develop privacy enhanced mail once public key technology became available. The patent situation for public key technology is a bit strange. The patent rules vary slightly from country to country. The basic ideas for public key cryptography were published before the patent was applied for. In the U.S., there is a one year period in which it is still possible to apply for patents after publication. Elsewhere, publication prohibits patenting. Hence, the patent governing RSA applies in the U.S. (and perhaps Canada) but not elsewhere in the world. FUTURE DEVELOPMENTS Integration of MIME and PEM As noted above, it is desirable for MIME and PEM to be integrated. Although there is great pressure to integrate these as quickly as possible, there is even greater pressure to bring PEM out as quickly as possible. The clear consensus is to move these specifications forward now. In the future, proposals and trial implementations for merged MIME-with-PEM systems will be developed, and the resulting specifications may appear on the standards track in short order. Compatibility between these specifications and any new specifications will be of obvious concern. Preliminary analysis indicates that translation between PEM into MIME-with-PEM will be trivial. In my opinion, translation from MIME-with-PEM to PEM is also expectEed to be straightforward as long as the MIME-with-PEM messages contain only plain text, message and multipart content types. Alternative Algorithms Part III of these specifications define the use of the RSA, DES, MD2 and MD5 algorithms. The U.S. government is actively developing an alternative suite of algorithms which it intends to standardize. Many U.S. government agencies feel it will be necessary to use these algorithms and not to use the algorithms defined in Part III of this specification. As a separate but related matter, the U.S. government, along with other members of CoCom, prohibit the general export of software containing certain forms of cryptography. In particular, software containing DES for encryption is not generally exportable. Although software can be developed separately in some countries to avoid the export issue, a more general solution is to use a set of algorithms which are exportable. Export permission has been granted for various symmetric algorithms which are weaker than DES and for the use RSA with limits on the key size. Of particular note, the Software Publishers Association has reached agreement with the U.S. government for general export of software containing RC2 and RC4 with 40 bit keys and RSA with a limit of 512 bit keys when RSA is used for key exchange. (There is no limit when RSA is used only for signature and integrity.) RC2 and RC4 are symmetric key encryption algorithms developed by RSADSI and available under license. The U.S. government is now providing expedited processing of license requests for software that meets these terms. The pressure to use these alternative algorithms poses a challenge for our community and our standards process. The introduction of new algorithm requires substantial vetting to make sure it is technically sound. No complete methods exist for proving the soundness of a cryptographic algorithm, so this is necessarily a tedious and artful process. Moreover, the use of multiple algorithms within the same environment poses substantial compatibility problems. For these reasons, it is desirable to set a high threshold before admitting any additional algorithms onto the standards track. At the same time, the pressures to incorporate additional algorithms are already evident. Completely ignoring or prohibiting the use of alternative algorithms will not be a successful strategy. The Part III specification speaks to the issue of incorporation of additional algorithms into the standard and says such incorporation will be accomplished by issuing a successor document. Part III specification also addresses the interim development process by suggesting that alternative algorithms may be documented in Experimental or Prototype RFCs prior to adoption into the standard. As experience is gained, these protocols may be considered for incorporation into the standard. PATENT STATEMENT The IESG has reviewed the patent issues and will have the following text added to each of the RFC documents: This version of Privacy Enhanced Mail (PEM) relies on the use of patented public key encryption technology for authentication and encryption. The Internet Standards Process as defined in RFC 1310 requires a written statement from the Patent holder that a license will be made available to applicants under reasonable terms and conditions prior to approving a specification as a Proposed, Draft or Internet Standard. The Massachusetts Institute of Technology and the Board of Trustees of the Leland Stanford Junior University have granted Public Key Partners (PKP) exclusive sub-licensing rights to the following patents issued in the United States, and all of their corresponding foreign patents: Cryptographic Apparatus and Method ("Diffie-Hellman")............................... No. 4,200,770 Public Key Cryptographic Apparatus and Method ("Hellman-Merkle").................... No. 4,218,582 Cryptographic Communications System and Method ("RSA")................................... No. 4,405,829 Exponential Cryptographic Apparatus and Method ("Hellman-Pohlig").................... No. 4,424,414 These patents are stated by PKP to cover all known methods of practicing the art of Public Key encryption, including the variations collectively known as El Gamal. Public Key Partners has provided written assurance to the Internet Society that parties will be able to obtain, under reasonable, nondiscriminatory terms, the right to use the technology covered by these patents. This assurance is documented in RFC-1170 titled "Public Key Standards and Licenses". A copy of the written assurance dated April 20, 1990, may be obtained from the Internet Assigned Number Authority (IANA). The Internet Society, Internet Architecture Board, Internet Engineering Steering Group and the Corporation for National Research Initiatives take no position on the validity or scope of the patents and patent applications, nor on the appropriateness of the terms of the assurance. The Internet Society and other groups mentioned above have not made any determination as to any other intellectual property rights which may apply to the practice of this standard. Any further consideration of these matters is the user's own responsibility. Working Group Summary The PEM specifications originated with the Privacy and Security Research Group. As part of the transition of the specifications from research to standards track documents a Working Group within the IETF was created, which has met at each IETF since its creation. The documents have been available as an Internet Draft since at least September 1992 and represent the consensus of the Working Group. Protocol Quality Although each of the PEM specifications has a different editor, they have all cooperated to make the documents fit together as a set. They are well written, easy to understand, and provide enough background material to make them suitable for a security neophyte. At the time of the third publication of the specifications, three independent, interoperable implementations were known to exist. Currently, only two of those are aligned with the current version of the specifications. Greg Vaudreuil IESG Secretary ------- End of Forwarded Message From gnu Fri Jan 29 13:05:37 1993 From: gnu (John Gilmore) Date: Fri, 29 Jan 93 13:05:37 PST Subject: RSA assurance referenced in PEM posting In-Reply-To: <9301291429.aa07535@IETF.CNRI.Reston.VA.US> Message-ID: <9301292105.AA11851@toad.com> Here is the RFC 1170 referred to in the posting about Privacy Enhanced Mail. I note that it only covers signatures, not key exchange. John Network Working Group R. Fougner Request for Comments: 1170 Public Key Partners January 1991 Public Key Standards and Licenses Status of this Memo This RFC is a public statement by Public Key Partners regarding Public Key Standards and Licenses. This memo is for informational use only, and does not constitute an Internet standard. Distribution of this memo is unlimited. Public Key Standards and Licenses The Massachusetts Institute of Technology and the Board of Trustees of the Leland Stanford Junior University have recently granted Public Key Partners exclusive sublicensing rights to the following patents registered in the United States, and all of their corresponding foreign patents: Cryptographic Apparatus and Method ("Diffie-Hellman")............................... No. 4,200,770 Public Key Cryptographic Apparatus and Method ("Hellman-Merkle").................... No. 4,218,582 Cryptographic Communications System and Method ("RSA")................................... No. 4,405,829 Exponential Cryptographic Apparatus and Method ("Hellman-Pohlig").................... No. 4,424,414 These patents cover all known methods of practicing the art of Public Key, including the variations collectively known as El Gamal. Due to the broad acceptance of RSA digital signatures throughout the international community, Public Key Partners strongly endorses its incorporations in a digital signature standard. We assure the interested parties that Public Key Partners will comply with all of the policies of ANSI and the IEEE concerning the availability of licenses to practice this art. Specifically, in support of any RSA signature standard which may be adopted, Public Key Partners hereby gives its assurance that licenses to practice RSA signatures will be available under reasonable terms and conditions on a non- discriminatory basis. Fougner [Page 1] RFC 1170 Public Key Standards and Licenses January 1991 We take this opportunity to thank all of those concerned for their collective efforts in making this technology readily available for commercial implementation. Public Key Partners By: Robert B. Fougner Director of Licensing Security Considerations This memo discusses fair access to the use of public key technology to implement security. Author's Address Robert B. Fougner Director of Licensing Public Key Partners 130 B Kifer Court Sunnyvale, CA 94086 Phone: (408) 735-6779 Fougner [Page 2] From Marc.Ringuette at GS80.SP.CS.CMU.EDU Fri Jan 29 13:19:44 1993 From: Marc.Ringuette at GS80.SP.CS.CMU.EDU (Marc.Ringuette at GS80.SP.CS.CMU.EDU) Date: Fri, 29 Jan 93 13:19:44 PST Subject: OTP Generators Message-ID: <9301292119.AA12633@toad.com> Hal> Also, relying on a half-life calculation in which we wait a certain time Hal> interval, and see if there is a decay or not, won't be that accurate. Hal> If your time is off a little, it could bias the results. Hal> Tim May posted the best (IMO) fix for this. You collect bits in pairs; Hal> discard 00 and 11; for each 01 output a 0, for each 10 output a 1. This is better than nothing, but it doesn't completely fix the biased bit stream. For instance, if your detector typically has some runs of zeroes, then after a 10 sequence, a 01 sequence is more likely than another 10. I think that all schemes which rely on _single_ random events from a radioactive source are going to be very sensitive to tuning errors which will make their random bit streams biased and thus useless. Better is the following: select a time interval in which 100-1000 random events will occur. Count events in one of these time intervals and output the parity of the count. Repeat. If you ever detect fewer than 10 events in an interval, quit with an error. This method has the advantage that no "tuning" of the randomness source is necessary; you must only ensure that your time interval contains a lot of random events, so that there is no chance of a small drift in the random number source causing a corresponding failure in randomness. Another useful technique, if you're willing to trust crypto technology, is to compute MD5 hashes or DES encryptions of the bit stream. This will do a lot, actually. If your bits are already random, then applying a pseudo-random permutation can't hurt; but if you've been brain-dead somehow, it's a great insurance policy to apply a well-known scrambling algorithm to your bits. I wish we weren't just discussing hacks, though. I think I'll hunt for some theoretical results to make this more solid. -- Marc Ringuette (mnr at cs.cmu.edu) From tribble at xanadu.com Fri Jan 29 13:25:39 1993 From: tribble at xanadu.com (E. Dean Tribble) Date: Fri, 29 Jan 93 13:25:39 PST Subject: Remailer abuse? In-Reply-To: <9301291807.AA08440@alumni.cco.caltech.edu> Message-ID: <9301292115.AA19024@xanadu.xanadu.com> Set up your remailer under an account named remailer so that you don't get such responses. Also, perhaps prepend to outgoing messages a note to the effect that they have been forwarded by you and that you know nothing of the contents. dean From norstar at tnl.com Fri Jan 29 13:30:21 1993 From: norstar at tnl.com (Daniel Ray) Date: Fri, 29 Jan 93 13:30:21 PST Subject: turning on yourself during car stops Message-ID: <9301290553.AA10758@tnl.com> >From: Peter Honeyman >To: cypherpunks at toad.com, edgar at spectrx.Saigon.COM >Date: Mon, 25 Jan 93 19:57:20 EST >Subject: Re: public servant privacy > >i believe there is a special exception related to automobiles >that makes them subject to search without a warrant when the >driver is placed under arrest. but check with a lawyer. > > peter > essentially 90+% of all contraband found during traffic stops on the highway is because the driver consented to a search. Literally the police officer will ask "can I search your car?" and people, even experienced criminals, will say "ok alright" even though they should know better. some think that saying no means just a delay and they search anyways. this is not the case. If they ask, and you say no, the most that happens is that you get a delay and they may bring in a dog for a sniff. If they can search anyway, they will just do it and not ask. Just respond "I want to preserve my privacy". Police know that virtually NO ONE refuses a "consent-search" request. and in most cases, if you do know better and refuse, they will not bring a dog and will let you go. lately a trucker consented to a search where they discovered several million dollars in cocaine in his cab. Police know this phenomenon and, needless to say, exploit it fully. And they know how to "sweet talk" people, which is a method of questions & answers that further enhances cooperation from other- wise noncompliant people. Remember: "Just say no". It may save your ass. norstar at tnl.com From huntting at glarp.com Fri Jan 29 14:14:32 1993 From: huntting at glarp.com (Brad Huntting) Date: Fri, 29 Jan 93 14:14:32 PST Subject: Is this true??? In-Reply-To: <9301291840.AA29938@longs.lance.colostate.edu> Message-ID: <199301292212.AA02949@misc.glarp.com> > First of all, the simple feasibility of such an operation must be > called into question. There is a tremendous amount of data going > over modems on public telephone lines. What is the chance that > even a small fraction could be monitored? (And an even more > infinitesmal fraction archived.) The intelgence community get's what it want's. If congress wont allocate the funds, they'll import drugs to pay for it. I dought they can keep everything on file, but they certainly filter for interesting data. > The claim has appeared here before that it is "trivial" for a > government agency to scan for interesting keywords and sort the data > based on that. But I think that even that would lead to loads of > irrelevant crap and require an army of intelligence agents to sort. > Where is this army? Fort Mead, MD. > Also, the claims in the letter are referring to public telephone > networks. Would this include all the networks comprising the Internet? > If so, this multiplies the data volume immensely. How could anyone > find anything useful in these massive streams? Granted, *very* > sensitive information is probably contained within it, but how the heck > could it be found efficiently? A recent issue of Communications of the ACM is dedicated to the issue of data filtering. People have been working on this technology for along time. It's very importaint in the information age to have all relivant information. > Regarding the claim that one major monitoring hub is code named > "elizabeth" in Boulder Colorado. There is a government standards > agency there, if I am not mistaken, I forget if it is NIST (?). Also, > the National Center for Oceanic Research, which has very tremendous > computing power (e.g. Cray YMP) is there also. In their tours they > show massive archival storage areas, which they say record major > amounts of global atmospheric data (e.g. temperatures, wind currents > > etc.) collected from satellites. These could conceivably be in part > "covers" but the idea is also rather unimaginable. Can anybody report > on agencies in the areas cited? There is the very specific claim of a > carrier in Columbus Ohio. That's National Center for _Atmosphearic_ research (the nearest ocean is 1300mi away), and it's so public there's probably no way it could be used for such a purpose. NIST and NOAA are also very open. However, we do have an FBI office here (I only know because a friend of mine works for a criminal defence lawyer located in the same building... briliant planing, no?). There are numerous warehouses in the east quarter any number of which could house a database like this. brad From jpp at markv.com Fri Jan 29 15:25:54 1993 From: jpp at markv.com (Jay Prime Positive) Date: Fri, 29 Jan 93 15:25:54 PST Subject: Is this true??? In-Reply-To: <9301291840.AA29938@longs.lance.colostate.edu> Message-ID: <9301291524.aa22898@hermix.markv.com> >Under an obscure pre-WWII ruling by the agency that is now the FCC... >"No information may be encoded or transmitted over PUBLIC or PRIVATE >forms of telephony or radio with the exception of those agencies >involved in the National Security" a further designation goes on to >say "with the exception of the MORSE system of 'transmittal', any >communication that is not interpretable by the human ear is forbidden >and unlawful." As a liscenced ham (amature radio operator), kb6wct, I can assure you that the FCC allows transmissions other than phone, and morse code. Here are just a few -- rtty, ascii, spread spectrum, fax, sstv, and ntsc video. Hams can SEND all of these over the radio. There are still other information transmission systems in use by comercial interests. However, the FCC does in fact dissallow hams from transmitting in "any code or cypher with intent to obscure the content of the message." This allows all cryptographic authentication systems, but not encryption. j' From dsinclai at acs.ucalgary.ca Fri Jan 29 17:17:39 1993 From: dsinclai at acs.ucalgary.ca (Douglas Sinclair) Date: Fri, 29 Jan 93 17:17:39 PST Subject: Radioactive sources Message-ID: <9301300117.AA14374@acs1.acs.ucalgary.ca> Yup, the 3 microcurie source makes sense. With a pair of diodes we could make the detector 4 pi, but no big deal. 3 microcuries is not a problem health-wise as long as you don't eat it. As it's an alpha source, any shiledingor even a few centimeters of air will stop the rays. Howerver, I just encountered a new angle on it. According to my father, that's on the order of $100 worth of radium :(. If we're willing to go with a much slower source, we can use thorium which is only $2 per gram or so. Alternativly, anyone have an old clock with a radium dial? BTW: Cosmic ray background is only 1 event per square foot per minute. Plus, they occur in showers. So that isn't going to work. -- Vercotti: I was terrified of him. Everyone was terrified of Doug. I've seen grown men pull their own heads off rather than see Doug. Even Dinsdale was frightened of Doug. Interviewer: What did he do? Vercotti: He used sarcasm. He knew all the tricks, dramatic irony, metaphor, bathos, puns, parody, litotes and satire. -- Monty Python, Episode 14 PGP 2.1 Key by finger From elee9sf at Menudo.UH.EDU Fri Jan 29 23:05:46 1993 From: elee9sf at Menudo.UH.EDU (Karl Barrus) Date: Fri, 29 Jan 93 23:05:46 PST Subject: randomness & 01/10 In-Reply-To: <9301292119.AA12633@toad.com> Message-ID: <199301300456.AA28331@Menudo.UH.EDU> >bit stream. For instance, if your detector typically has some runs of >zeroes, then after a 10 sequence, a 01 sequence is more likely than >another 10. But you are looking at the stream in pairs - so whether or not you see another 10 or 01 depends on whether there is an odd or even number of zeroes before the next one. /-----------------------------------\ | Karl L. Barrus | | elee9sf at menudo.uh.edu | <- preferred address | barrus at tree.egr.uh.edu (NeXTMail) | \-----------------------------------/ From gg at well.sf.ca.us Sat Jan 30 02:08:20 1993 From: gg at well.sf.ca.us (George A. Gleason) Date: Sat, 30 Jan 93 02:08:20 PST Subject: Radioactive sources Message-ID: <199301301005.AA19123@well.sf.ca.us> Radioactive sources: if you're interested in thorium, it can be found in Coleman lantern mantles: the little cloth bags you tie over the apertures in the lantern where the flame appears. These are apparently saturated with the stuff. I got the word from an engineer at a nuclear plant some years ago, and was able to verify it at least partially: a geiger counter held next to Coleman lantern mantles at the store got a very clear reading in the range of 20mR/hr. The counter I was using was not sensitive to alphas, so I presume it was getting betas. The thorium in the lantern mantles could presumably be extracted with hydrochloric acid or by some other means. Clearly not for the amateur, but something which could be done in a lab with appropriate precautions. -gg From libert at citi.umich.edu Sat Jan 30 08:19:07 1993 From: libert at citi.umich.edu (Tom Libert) Date: Sat, 30 Jan 93 08:19:07 PST Subject: randomness Message-ID: <9301301619.AA09879@toad.com> For a cheap truly random number generator, bias a diode near the switch voltage (around .7V for silicon, if my hazy memory serves.) Take the result through an A/D converter. Should be Gaussian (or Poisson, I forget); you could generate a good approximation to a uniform distribution by inverting the source function (see e.g. Knuth, "Seminumerical Algorithms" for an algorithm for producing Gaussian variates from a pair of numbers drawn from a uniform distribution.) From shipley at merde.dis.org Sat Jan 30 14:54:43 1993 From: shipley at merde.dis.org (shipley at merde.dis.org) Date: Sat, 30 Jan 93 14:54:43 PST Subject: party... Message-ID: <9301302241.AA01909@merde.dis.org> -----BEGIN PGP SIGNED MESSAGE----- (This is not my house warming (yet).. so don't trash it) Deiodre Williams if having her B'day at my place. she would like to have ner and intresting people attend she is barrowing my house to throw a party. she is throwing this party on Jan 30th. she would like to see some new faces at this party (not just the berkeley regulars) Please call (510) 849-2230 if you have any questions map info: 2341 Spaulding Ave Berkeley Ca 94703-1627 the cross street is Channing Spaulding is one block above Sacramento Ave. and only gos between Dwight and Allston (it does not connect to Univ. Ave) ^ MLK way/Telegraph/Shattuck ave | <- university ave | | | | | | | | | | | | | | | | | | | | | | /-------+ +--- --------+ +--------------+ +-----+ _ _ _ California - - - - +--- --------+ +--------------+ +--------------+ | | | | | | | | | | | | | | | | | | | | | | | | | | | 3241 | | | | | | X |C | | | --------+B +--------------+h +--------------+D | a Spaulding a w | --------+n +--------------+n +--------------+i | |c | |n | |g | |r | |i | |h | |o | |n | |t | |f | |g | | | |t | | | |w | | | |w | |a | --------+w +-------------- a +--------------+y +---------- _ _ _ a _ _ _ _ _ _ y _ _ _ _ _ _ _ _ _ _ _ _ y Sacramento --------+ +--------------+ +--------------+ +---------- | | | | | | | | | | | | | | | | | | | . | ^ | . | My Place -> Take your favorite freeway to | | . | 580/Berkeley and get off at the U.C. | . | University ave off ramp and drive Campus | . | up toward U.C. Campus (stay in the | . | Gas right lane to be safe). 7/11 | . | Station +--------------+ +-------------- The Second major intersection should _ _ _ _ _ _ _ _ _ _ _ _ _ be Sacramento ave (~1 mile). Take a Sacramento right on to Sacramento and get into +--------------+ +-------------- the left lane (see map to the left) Gas |U . | Video Station |n . | Store At the next light take a left and |i . | drive one block then make a right <-- North |v . | onto Spaulding ave. Berkeley |e . | Bart |r . | I live at 3241 Spaulding, it is the Station |s . | 580 third house from Channing way, with |i . | | a red cracked drivway. (see other map) |t . | V |y . | In case you get lost my home number | . | is (510) 849-2230 - ------- End of Forwarded Message -----BEGIN PGP SIGNATURE----- Version: 2.1 iQBFAgUBK2sEL8hmn7GUWLLFAQHIQAF9FDQgyAvmf5bJVT6FWLlVI3BVYDB5a025 mGAOFlXJInUi7tmkGJavqu1enJ/g3MFE =IgCI -----END PGP SIGNATURE----- From nowhere at bsu-cs.bsu.edu Sat Jan 30 15:26:54 1993 From: nowhere at bsu-cs.bsu.edu (Chael Hall) Date: Sat, 30 Jan 93 15:26:54 PST Subject: Remailer abuse? In-Reply-To: <9301292115.AA19024@xanadu.xanadu.com> Message-ID: <9301302324.AA01308@bsu-cs.bsu.edu> Dean writes: >Set up your remailer under an account named remailer so that you don't >get such responses. Also, perhaps prepend to outgoing messages a note >to the effect that they have been forwarded by you and that you know >nothing of the contents. I would append the note, because prepended text could screw up chaining of remailers. Chael Hall -- Chael Hall nowhere at bsu-cs.bsu.edu, 00CCHALL at LEO.BSUVC.BSU.EDU, CHALL at CLSV.Charon.BSU.Edu (317) 285-3648 after 5 pm EST From pmetzger at shearson.com Sat Jan 30 17:40:46 1993 From: pmetzger at shearson.com (Perry E. Metzger) Date: Sat, 30 Jan 93 17:40:46 PST Subject: Radioactive sources In-Reply-To: <9301300117.AA14374@acs1.acs.ucalgary.ca> Message-ID: <9301310121.AA16272@maggie.shearson.com> >From: Douglas Sinclair >Yup, the 3 microcurie source makes sense. With a pair of diodes we could >make the detector 4 pi, but no big deal. 3 microcuries is not a problem >health-wise as long as you don't eat it. As it's an alpha source, any shiledingor even a few centimeters of air will stop the rays. Howerver, I just encountered a new angle on it. According to my father, that's on the order of $100 >worth of radium :(. If we're willing to go with a much slower source, we can >use thorium which is only $2 per gram or so. Alternativly, anyone have >an old clock with a radium dial? >BTW: Cosmic ray background is only 1 event per square foot per minute. Plus, >they occur in showers. So that isn't going to work. Why not just go with the Newbridge Micro hardware RNG that we've discussed several times in the past? Its only $50 for a 20kbit/sec output rate. Perry From 72466.3616 at CompuServe.COM Sat Jan 30 18:17:47 1993 From: 72466.3616 at CompuServe.COM (Don Henson) Date: Sat, 30 Jan 93 18:17:47 PST Subject: Remailer Abuse? Message-ID: <930131020759_72466.3616_EHB92-4@CompuServe.COM> --> Is someone using my remailer to send trash to innocent young girls? I am uncomfortable to be facilitating this kind of activity. Can anyone offer suggestions for the ethical thing to do in this situation? Hal <-- You didn't say but I assume from the context that your remailer is anonymous. If that is the case, then you have a decision to make. You can either keep your remailer anonymous and not be concerned about what goes thru it or you can make it a moderated list so that you become responsible for everything that is posted. Which way do you want it? Don Henson PGP key available on request From 72466.3616 at CompuServe.COM Sat Jan 30 18:18:49 1993 From: 72466.3616 at CompuServe.COM (Don Henson) Date: Sat, 30 Jan 93 18:18:49 PST Subject: MIME Message-ID: <930131020801_72466.3616_EHB92-5@CompuServe.COM> One stupid question, please? What is MIME? Don Henson PGP key available on request From nobody at alumni.cco.caltech.edu Sat Jan 30 19:15:46 1993 From: nobody at alumni.cco.caltech.edu (nobody at alumni.cco.caltech.edu) Date: Sat, 30 Jan 93 19:15:46 PST Subject: Remailer abuse Message-ID: <9301310317.AA22540@alumni.cco.caltech.edu> Thanks for the many suggestions posted here and sent privately to me about ways to deal with the possible use of my remailer to send abusive messages. I have taken two steps, and I could fairly easily take a third. First, I sent a letter to the girl who complained explaining that the message was not actually from me, that it was from an experimental remailing software package, and telling her to let me know if she got more objectionable messages. Second, I changed the header line inserted by my remailer to what you see above. (This message is being forwarded by my remailer.) Hopefully this will clue people in to what is happening. I didn't want to mess with the message body based on the discussion we have had here on that issue. I'd appreciate comments about the wording and appropriateness of the header line, if anyone can offer improvements. (As an unprivileged user of this system, I do not have the ability to create new accounts so that the message would appear to come from "remailer". The best I could do is get it into the From: line in the header, but my name still shows in the "out of band" From line which precedes the header.) What I could do, if more "problem" messages come through, is create a list of people _not_ to forward mail to. Some people have suggested the creation of a list not to forward mail _from_, but that is more difficult in an environment of chained remailers (since I can't always determine the message source). It should be pretty easy to check to see whether the destination of a remail request is on the list of people "not to be bothered", and to not send it in that case. We could even share this list among the various remailer operators. That does not require any collusion or message logging, and it seems like it should largely address the problem. Hal 74076.1041 at compuserve.com From dsinclai at acs.ucalgary.ca Sat Jan 30 20:12:46 1993 From: dsinclai at acs.ucalgary.ca (Douglas Sinclair) Date: Sat, 30 Jan 93 20:12:46 PST Subject: Radioactive sources In-Reply-To: <199301301005.AA19123@well.sf.ca.us> Message-ID: <9301310411.AA31726@acs1.acs.ucalgary.ca> Yes, you can get Thorium from lamp nets. A simpler way is to get it from welding rods. They are 40% thorium. More than one unsespecting lab technician has welded together an ultrasensitive detector with them, only to find it not working for some reason -- Vercotti: I was terrified of him. Everyone was terrified of Doug. I've seen grown men pull their own heads off rather than see Doug. Even Dinsdale was frightened of Doug. Interviewer: What did he do? Vercotti: He used sarcasm. He knew all the tricks, dramatic irony, metaphor, bathos, puns, parody, litotes and satire. -- Monty Python, Episode 14 PGP 2.1 Key by finger From dsinclai at acs.ucalgary.ca Sat Jan 30 20:17:04 1993 From: dsinclai at acs.ucalgary.ca (Douglas Sinclair) Date: Sat, 30 Jan 93 20:17:04 PST Subject: randomness In-Reply-To: <9301301619.AA09879@toad.com> Message-ID: <9301310416.AA23281@acs1.acs.ucalgary.ca> Yes, I have heard of using diodes for white noise production. Hoewver, I am conserned as to the nature of this noise. Is it some property of the silicon or is it just amplified radio noise that is bringing the diode above threshold?? -- Vercotti: I was terrified of him. Everyone was terrified of Doug. I've seen grown men pull their own heads off rather than see Doug. Even Dinsdale was frightened of Doug. Interviewer: What did he do? Vercotti: He used sarcasm. He knew all the tricks, dramatic irony, metaphor, bathos, puns, parody, litotes and satire. -- Monty Python, Episode 14 PGP 2.1 Key by finger From julf at penet.FI Sun Jan 31 01:08:50 1993 From: julf at penet.FI (Johan Helsingius) Date: Sun, 31 Jan 93 01:08:50 PST Subject: party... In-Reply-To: <9301302241.AA01909@merde.dis.org> Message-ID: <9301311018.aa03334@penet.penet.FI> > Deiodre Williams if having her B'day at my place. > she would like to have ner and intresting people attend > she is barrowing my house to throw a party. > she is throwing this party on Jan 30th. > she would like to see some new faces at this party (not just the > berkeley regulars) Well, it would have been nice to attend, but... a) Because of time zone differences, it was already 0:41 on Sunday, Jan 31 out here at the time you sent your message b) There was no way I could get hold of my travel agent to get a flight ticket.. And the flight from Helsinki, Finland to SF is close to 11 hours anyway... Just a reminder that the net is a pretty global thing... Hope the party was fun! Julf "Oh so near to Russia, so far from Japan... Hai! Quite a long way from Cairo, lots of miles from Vietnam." (From "The Finland Song" by Monty Python). From libert at citi.umich.edu Sun Jan 31 09:49:00 1993 From: libert at citi.umich.edu (Tom Libert) Date: Sun, 31 Jan 93 09:49:00 PST Subject: randomness Message-ID: <9301311748.AA08822@toad.com> Yes, I have heard of using diodes for white noise production. Hoewver, I am conserned as to the nature of this noise. Is it some property of the silicon or is it just amplified radio noise that is bringing the diode above threshold?? Fundamental property of the switch. If you bias a diode near the knee, random events at the quantum mechanical level can cause readily observable changes in the output potential. Recall that the diode does not conduct below the switch threshold, and conducts readily above it. But what happens AT the threshold? Thermal noise produces dramatic changes in the output. This approach has been used for years to produce "white" (or "pink") noise. I also believe (but am not certain) that electronic poker and bingo games also use this technique. From 72466.3616 at CompuServe.COM Sun Jan 31 11:38:41 1993 From: 72466.3616 at CompuServe.COM (Don Henson) Date: Sun, 31 Jan 93 11:38:41 PST Subject: party... Message-ID: <930131192921_72466.3616_EHB35-1@CompuServe.COM> --> she would like to see some new faces at this party (not just the berkeley regulars) <-- Does this mean that all cypherpunks live in driving distance of Berkeley? If so, I guess I'd better unsubscribe fast since I live in Hawaii. Be a bit of drive from there, eh? Don Henson PGP key available on request P.S. Happy Birthday From huntting at glarp.com Sun Jan 31 12:23:10 1993 From: huntting at glarp.com (Brad Huntting) Date: Sun, 31 Jan 93 12:23:10 PST Subject: MIME In-Reply-To: <930131020801_72466.3616_EHB92-5@CompuServe.COM> Message-ID: <199301312022.AA05273@misc.glarp.com> > One stupid question, please? What is MIME? Multipurpose Internet Mail Extension(s)... It provides a simple framework for sending typed body parts in RFC822 mail. One popular use for this is multimedia, but it can also be used to send binaries, references to ftp-able files, etc. It also provides an ideal framework for incorporating message encryption and authentication into rfc822 message. brad From tony at morgan.demon.co.uk Sun Jan 31 14:00:56 1993 From: tony at morgan.demon.co.uk (Tony Kidson) Date: Sun, 31 Jan 93 14:00:56 PST Subject: Remailer Abuse? Message-ID: <1883@morgan.demon.co.uk> In message <930131020759_72466.3616_EHB92-4 at CompuServe.COM> you write: > --> > > Is someone using my remailer to send trash to innocent young girls? > I am uncomfortable to be facilitating this kind of activity. Can anyone > offer suggestions for the ethical thing to do in this situation? > > Hal > > <-- > > You didn't say but I assume from the context that your remailer is anonymous. > If that is the case, then you have a decision to make. You can either keep > your remailer anonymous and not be concerned about what goes thru it or you can > make it a moderated list so that you become responsible for everything that is > posted. Which way do you want it? Not necessarily. Surely, he can keep logs for a limited period. If no complaint arrives, discard the logs. If anybody complains, pass it on with endorsement if necessary. Also, put a disclaimer in your mail, that you are not responsible for the opinions expressed. Tony +-----------------+-------------------------------+--------------------------+ | Tony Kidson |`morgan' is an 8MB 486/33 Cat-| Voice +44 81 466 5127 | | Morgan Towers, |Warmer with a 670 MB Hard Disk.| E-Mail | | Morgan Road, |It resides at Morgan Towers in| tony at morgan.demon.co.uk | | Bromley, |Beautiful Down Town Bromley. | tny at cix.compulink.co.uk | | England BR1 3QE |Honda ST1100 ==*== DoD# 0801 | 100024.301 at compuserve.com| +=================+===============================+==========================+ From shipley at tfs.COM Sun Jan 31 14:01:29 1993 From: shipley at tfs.COM (Peter Shipley) Date: Sun, 31 Jan 93 14:01:29 PST Subject: party... In-Reply-To: <930131192921_72466.3616_EHB35-1@CompuServe.COM> Message-ID: <9301312159.AA02274@edev0.TFS> > >Does this mean that all cypherpunks live in driving distance of Berkeley? If >so, I guess I'd better unsubscribe fast since I live in Hawaii. Be a bit of >drive from there, eh? > When I sent the invite to the list I knew that there were many that do not live within traveling distance. But since there are there are a few in the area I thought it would be a good opportunity to meet a few of the locals (and trade keys). PS: ther party went very well and I did get a chance to meet a few more people from this list. -Pete From strick at osc.versant.com Sun Jan 31 14:50:27 1993 From: strick at osc.versant.com (henry strickland) Date: Sun, 31 Jan 93 14:50:27 PST Subject: party... In-Reply-To: <9301312159.AA02274@edev0.TFS> Message-ID: <9301312255.AA23576@versant.com> # PS: ther party went very well and I did get a chance to meet a few more # people from this list. I also made it to the party, and would not have, had it not been for the announcement on cypherpunks. Please do make announcements ... and leave it for individual punks to decide how far they should drive, fly, swim, etc. for a party! ( It took me two trains, one bus, and a seven block walk. ) strick strick at osc.versant.com From Eric.K.Kuecherer at Dartmouth.EDU Sun Jan 31 15:41:10 1993 From: Eric.K.Kuecherer at Dartmouth.EDU (Eric.K.Kuecherer at Dartmouth.EDU) Date: Sun, 31 Jan 93 15:41:10 PST Subject: No Subject Message-ID: <2622117@blitzen.Dartmouth.EDU> Is this real? -kuech- From elee9sf at Menudo.UH.EDU Sun Jan 31 15:56:29 1993 From: elee9sf at Menudo.UH.EDU (Karl Barrus) Date: Sun, 31 Jan 93 15:56:29 PST Subject: Yes In-Reply-To: <2622117@blitzen.Dartmouth.EDU> Message-ID: <199301312355.AA00130@Menudo.UH.EDU> >Is this real? >-kuech- Yes, this is the cypherpunk mailing list. Subscribe by sending a note to cypherpunks-request at toad.com /-----------------------------------\ | Karl L. Barrus | | elee9sf at menudo.uh.edu | <- preferred address | barrus at tree.egr.uh.edu (NeXTMail) | \-----------------------------------/ From shipley at dis.org Sun Jan 31 16:01:44 1993 From: shipley at dis.org (shipley at dis.org) Date: Sun, 31 Jan 93 16:01:44 PST Subject: party... Message-ID: <9301312352.AA04056@merde.dis.org> -----BEGIN PGP SIGNED MESSAGE----- ># PS: ther party went very well and I did get a chance to meet a few more ># people from this list. > >I also made it to the party, and would not have, had it not been for >the announcement on cypherpunks. Please do make announcements ... and >leave it for individual punks to decide how far they should drive, fly, >swim, etc. for a party! ( It took me two trains, one bus, and a seven >block walk. ) I run a party mailing list if anyone is intrested, anyone holding a party can email a invite to it the address is "ba-party at utter.dis.org" for those in Santa Curz there is a mailing list called "party at amory.com" email me if anyone is intrested ba-party. -Pete PS: henry, I added you to the list already. PPS: enough of this non-pgp stuff, anyone want to help me setup a remailer on my home systems? -----BEGIN PGP SIGNATURE----- Version: 2.1 iQBFAgUBK2xmTMhmn7GUWLLFAQEeEgF9EVFsIj8VA/zX4a8ycRppfyutsPO4shBQ 7L+FblZU7nL2ASYSmtVqQ4lu55SL35VB =qYGx -----END PGP SIGNATURE-----