- cypherpunks-legacy - lists.cpunks.org

Re: turning on yourself during car stops
by Daniel Ray 29 Jan '93

29 Jan '93

>From: Peter Honeyman <honey(a)citi.umich.edu> >To: cypherpunks(a)toad.com, edgar(a)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 … [View More]

1 0

RSA assurance referenced in PEM posting
by gnu 29 Jan '93

29 Jan '93

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 … [View More]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] [View Less]

1 0

Privacy Enhanced Mail proceeds to Proposed Standard
by gnu 29 Jan '93

29 Jan '93

------- Forwarded Message To: Jon Postel -- RFC Editor <postel(a)isi.edu> To: IETF-Announce:;@CNRI.Reston.VA.US@TIS.COM Cc: Internet Architecture Board <iab(a)isi.edu> Cc: pem-dev(a)TIS.COM Cc: The Internet Engineering Steering Group <IESG(a)IETF.CNRI.Reston.VA.US> From: IESG Secretary <iesg-secretary(a)CNRI.Reston.VA.US> Subject: Protocol Action: Privacy Enhanced Mail to Proposed Standard Date: Fri, 29 Jan 93 14:29:02 -0500 Message-Id: <9301291429.aa07535(a)IETF.… [View More]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" <draft-ietf-pem-msgproc-02.txt> o "Privacy Enhancement for Internet Electronic Mail: Part II: Certificate-Based Key Management" <draft-ietf-pem-keymgmt-01.txt> o "Privacy Enhancement for Internet Electronic Mail: Part III: Algorithms, Modes, and Identifiers" <draft-ietf-pem-algorithms-02.txt> o "Privacy Enhancement for Internet Electronic Mail: Part IV: Key Certification and Related Services" <draft-ietf-pem-forms-01.txt> 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 [View Less]

1 0

Re: Is this true???
by geoffw＠nexsys.net 29 Jan '93

29 Jan '93

> 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 … [View More]

1 0

a "real world" anonymous service
by eichin＠ATHENA.MIT.EDU 29 Jan '93

29 Jan '93

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 … [View More]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(a)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(a)athena.mit.edu. - Eric McDonald CROSSLINK Manager [View Less]

1 0

thresholding to enhance secrecy
by Jay Prime Positive 29 Jan '93

29 Jan '93

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 … [View More]

2 1

is this true???
by Fan Li TAI 29 Jan '93

29 Jan '93

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 … [View More]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(a)fuug.fi> From: an3284(a)anon.penet.fi (legend) Date: Wed, 20 Jan 1993 19:40:25 GMT Sender: anon(a)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(a)husc3.harvard.edu>, on(a)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(a)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(a)bnlux1.bnl.gov>, foxworth(a)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(a)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(a)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(a)kc2fd.ampr.org> |> - From: n8ecw(a)kc2fd.#nli.ny.usa.na |> - To: nli@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(a)KC2FD.#NLI.NY.USA.NA |> - To : NLI@N2MDQ |> |> - Original from N8ECW to ALL@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(a)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(a)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(a)MSUVX1.MEMST.EDU | ||_|\/|_| \_____/ \_____/ Memphis, TN 38152 | Bitnet : USTAI@MEMSTVX1 | |___________________________________________|__________________________________| [View Less]

2 1

Re: OTP Generators
by tcmay＠netcom.com 29 Jan '93

29 Jan '93

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 … [View More]

1 0

digital banking
by Karl Barrus 29 Jan '93

29 Jan '93

-----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 … [View More]

1 0

OTP Generators
by hal＠alumni.cco.caltech.edu 29 Jan '93

29 Jan '93

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 … [View More]

1 0