December 2003 - cypherpunks-legacy

IMPORTANT: Valhalla is leaving alias.net domain!!
by John Perry 17 Dec '03

17 Dec '03

NOTICE: valhalla.phoenix.net is leaving the alias.net domain! Please change your entries from remailer(a)spook.alias.net and wmono(a)spook.alias.net to remailer(a)valhalla.phoenix.net and wmono(a)valhalla.phoenix.net accordingly. Apparently double-domaining valhalla in SunOS 4.1.3 causes severe DNS problems that I can't explain at this time. I apologize for the inconvenience. Raph, can you change the entry to your remailer list accordingly ASAP?? John Perry - KG5RG perry(a)valhalla.phoenix.net

1 0

On export restrictions and the NYT/Internet Commerece
by sameer 17 Dec '03

17 Dec '03

The recent NYT article about the NFS work (nominally about the NFS work, I wouldn't call "spoofing NFS" to be tantamount to being able to spoof any file xfer over the internet) stresses that the internet wasn't built for security, yadd yadda yadda and therefore isn't very useful for internet commerce at this point. I urge everyone who talks to the media about this to stress export restrictions.. The infrastructure *would* be in place by now if we didn't have export restrictions. Deployed encryption at the IP level would be much easier if we didn't have export restrictions, etc. etc. Now that the potential for big bucks are obviously on the line maybe, (They always were on the line, it is just more obvious now) just maybe, enogh large corporations will invest in lobbying for the removal of export restrictions that it will get done. -- sameer Voice: 510-601-9777 Community ConneXion FAX: 510-601-9734 The Internet Privacy Provider Dialin: 510-658-6376 http://www.c2.org (or login as "guest") sameer(a)c2.org

1 0

Re: SAIC bought InterNic, but who is SAIC? A spook contractor!
by Chris Claborne 17 Dec '03

17 Dec '03

At 05:18 PM 9/28/95 -0700, John Gilmore wrote: >Forwarded-by: gordoni(a)base.com (Gordon Irlam) >SAIC's board members include Admiral Bobby Inman, former NSA head and deputy >director of the CIA; Melvin Laird, Nixon's defense secretary; and retired >General Max Thurman, commander of the Panama Invasion. Recently departed >board members include Robert Gates, former CIA director; William Perry, >current Secretary of Defense; and John Deutch, the current CIA director. >Current SAIC government contracts include re-engineering information systems >at the Pentagon, automation of the FBI's computerized fingerprint >identification system, and building a national criminal history information >system. I am not supporting the idea that SAIC is not annother govt mouthpiece or cover op but it is standard practice to hire retired workers from government that worked in the area that you want to sell services into. I know of a ex army colonel that used to work for a government contractor. I'm sure that he used his contacts to sell services to the government. You gotta love it! Don't trust S/MIME, it's supported by RSA (a govt mouth piece) and uses DES. ... __o .. -\<, Chris.Claborne(a)SanDiegoCA.ATTGIS.Com ...(*)/(*). CI$: 76340.2422 http://bordeaux.sandiegoca.attgis.com/ PGP Pub Key fingerprint = A8 FA 55 92 23 20 72 69 52 AB 64 CC C7 D9 4F CA Avail on Pub Key server. PGP-encrypted e-mail welcome!

2 1

Updated Key for Valhalla
by Valhalla Remailer 17 Dec '03

17 Dec '03

Here is the updated key for valhalla to reflect the new address. -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.6.2 mQCNAy/NyuUAAAEEAMN2nGvBlrvgiJn+9H8rafUOIAySzwaDAHr0myS6/dGHscfe 1gZ2usnL9zUQyhLfziurvd4yDYmsLxofHtzZuzOlZmCwSnXDwdxaeJs4zw8JoQxU OjPcxB/Ki1aNkKMhPuRezIFnWyMxOaiJTZeQmtMLhzgfgpL0xoqfP2eApTv5AAUR tEBWYWxoYWxsYSBSZW1haWxlciBUeXBlLUkgUEdQIGtleSA8cmVtYWlsZXJAdmFs aGFsbGEucGhvZW5peC5uZXQ+tDxOU0EgU3Bvb2sgUmVtYWlsZXIgVHlwZS1JIFBH UCBrZXkgPHJlbWFpbGVyQHNwb29rLmFsaWFzLm5ldD4= =3YjJ -----END PGP PUBLIC KEY BLOCK-----

1 0

Re: Basic Flaws in Internet Security and Commerce
by todd＠lgt.com 17 Dec '03

17 Dec '03

>A fine piece of work. The ideas expressed in this paper should scare >the hell out of everyone who uses NFS for any serious applications, >which for a fact includes most banks and all investment banks and >brokage houses. In this particular area I KNOW what is at risk. >Again, I congratulate the authors on a first-class effort. > > The real issue is not NFS itself but RPC and the interface layer between the system and these layered services. In fact holes also exist in RLOGIN, REXEC, and RSH (ports 512,513, and 514). Cant tell you how many secure systems we have broken because of these little goodies. The real issue is that by itself TCP/IP has no security to speak of, and more importantly the concept of secure messaging goes much farther than just keeping prying eye's off the data contained within. For instance Commerce Models require synchonization of process events in order to manage OLTP properly. TCP/IP in and of itself is really unusable for these tasks without something like the ISIS messageing protocol and process control 1interface above the protocol stack. All in all it's a complex nut to crack. Todd cheers, > paul > >> From owner-cypherpunks(a)toad.com Tue Oct 10 03:15:15 1995 >> From: gauthier(a)espresso.CS.Berkeley.EDU (Paul_A Gauthier) >> To: cypherpunks(a)toad.com, bugtraq(a)crimelab.com >> Cc: gauthier(a)cs.Berkeley.EDU, brewer(a)cs.Berkeley.EDU, iang(a)cs.Berkeley.EDU, >> daw(a)cs.Berkeley.EDU, fur(a)netscape.com >> Subject: Basic Flaws in Internet Security and Commerce >> Date: Mon, 09 Oct 1995 14:26:06 -0700 >> Sender: owner-cypherpunks(a)toad.com >> Content-Length: 10235 >> Regards, T. S. Glassey Chief Technologist Looking Glass Technologies todd(a)lgt.com -----BEGIN PGP SIGNATURE----- Version: 2.6 iQB1AwUBMFu5E6gNRnWhagU5AQHI+gL+Mwpcd3lAWd8FF06qcG6rnLhIYveHW71a XC7xh1T0uu8qnYX31yMp17OG28jWpKUbWec1IM9/eXOi+gInA7rKICWczV8zo9Z0 0puxjRRN7yO4KfRb3cPpk+r0p6pDg01Y =bTYb -----END PGP SIGNATURE-----

1 0

FWD>sig du crypt
by rah＠shipwright.com 17 Dec '03

17 Dec '03

>Date: 11 Oct 1995 11:04:04 -0800 >From: "Vinnie Moscaritolo" <Vinnie_Moscaritolo(a)quickmail.apple.com> >Subject: FWD>sig du crypt >To: "Bob Hettinga" <RAH(a)shipwright.com> > >Mail*Link(r) SMTP FWD>sig du crypt >>(forwards factored out) >> >>Sig found in sci.crypt: >> >>-- >>Eric Norman >> >> "Congress shall make no law restricting the size of integers >> that may be multiplied together, or the number of times that >> an integer may be multiplied by itself, or the modulus by >> which an integer may be reduced". >> ----------------- Robert Hettinga (rah(a)shipwright.com) Shipwright Development Corporation, 44 Farquhar Street, Boston, MA 02131 USA (617) 323-7923 "Reality is not optional." --Thomas Sowell >>>>Phree Phil: Email: zldf(a)clark.net http://www.netresponse.com/zldf <<<<<

1 0

Pointer to 10/9/95 EE Times Article
by nobody＠REPLAY.COM 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- To: cypherpunks(a)toad.com, llange(a)eet.cmp.com Front Page: `Cypherpunks' asked to breach Netscape, Microsoft security Desperately seeking hackers Quotes from Sidebar (How the `Cypherpunks' mailing list works): "When The New York Times announced a security flaw in Netscape Communications Corp's World Wide Web browser software a few weeks ago, the `Cypherpunks' hit the big time." This may be true. Companies are now asking for their products to be brutalized by the Cypherpunks' to help ensure security! This could not be said even a few mere weeks ago. "According to the group's moderator, who prefers to remain anonymous, `The most important means to the defense of privacy is encryption. Cypherpunks are therefore devoted to cryptography. They wish to learn about it, to teach it and to implement it.'" Ok, since when is the Cypherpunk's mailing list moderated? It is apparent that the author, Larry Lange, has never studied the list closely or he would know how amusing this sounds... (Geez, if he had ever read one of Tim May's posts on the subject... :-) Oh well, at least, I was amused. Regards, Loren -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMHwRFv8de8m5izJJAQEzWgP+LCPtBBH+hz0yqOG2MfduNyGK0kM6gHfN H/ZRZ11z2CExCZiJxRma6MhR/nRmgSePxGWMq/DfbUziUsuNwuJwN/PEEJtAXWTa dJ3FEhUaZbVlhBJK5Um1M0SeZPqiLCQH9K0DJNE0FevrJed/3MAft+owYTk2NQ+H oXDwXtFrTbw= =UGHU -----END PGP SIGNATURE-----

1 0

Re: Certificate proposal
by danisch＠ira.uka.de 17 Dec '03

17 Dec '03

I was busy in the last days and didn't keep track of the certificate discussion. I just read most of the discussion all at once. - There was some discussion about the bindings between the key and the real world attributes of the key owner. Under normal circumstances communication never happens without an originator. If the originator uses some kind of security feature, he normally doesn't do it just for fun. He uses it as a tool to give the communication certain properties. Authenticity and confidentiality don't make sense without knowing anything about the key owners. There is no use in having a signature as long as you don't know anything about the signator. And there is no use in encrypting messages as long as you don't know anything about the receiver. A digital signature is only the way to say who wrote the message. "Knowing the author" is the sense of the signature, not just having the signature. "Knowing" means know enough attributes about him. Same with encryption. Knowledge of the author may, of course, be quite bizarre, as well as the author itself. But security is always in context of some knowledge about the other side. It doesn't make much sense to communicate with a "smith(a)somewhere.edu", because this is not enough information to get sufficient knowledge of the key owner. There are a lot of people named smith being able to legally have this address. And it doesn't make sense to communicate with Bob, "Bob" or ISP+Bob, as long as the name Bob is not sufficient to provide enough information. I need to be able to get any knowledge about the key owner that could be a reason to be interested in communicating with him. I do not want to talk with bob because he is one of many Bobs. I want to talk with him because he is the Bob with phone number 123, red hair and living in XY street. Therefore, a certificate must be able to provide any information that could be required for the decision whether the key owner will be accepted as a communication partner. Obviously, the informations depend on the nature of the key owner (human, machine, committee etc.) - Under normal circumstances communication has an originator and in most cases an addressee. If you can talk to an addressee, you usually have some kind of address to locate him. But perhaps you don't have more than the address, not even a public key. Thus the address to communicate should also be good to locate the public key of the addressee (or the keys of all key owners listening on that address). Therefore, the communication address should be enough to locate a key server and to retrieve the key (or a small number of possible keys) for that address. After retrieving the keys, the originator of communication can decide whether there is a key sufficiently identifying his communication partner. Consequently, the key certificate should contain the communication address of the owner. It is helpfull if the address is unique. For a human this may be the email address. For a machine it may be the DNS host name or the internet adress. For a service (WWW-site) or an organization it may be the email address. The communication address must allow to locate the key server. The only existing infrastructure allowing this in internet is the DNS. If you have an email address, hostname or IP address, you can find the appropriate DNS server. The server should be able to help you. Best way to do this is to provide the address of a key retrieval system (similar to the MX record). Use the communication address of the key owner as a searchable index for the key. Inventing a MD5 hash sum as key index is useless and doesn't make sense in my eyes. It just creates the problem of knowing the index and typo errors. - A MITM between two communication partners can be avoided by apropriate protocols as long as there is a sufficient key management structure. - A MITM between a key owner and the certification authority is a problem, but a solvable one. I don't like the separation of creating the key and attaching attributes. The MITM can attack between. There is always the problem of managing all attached attributes. When the first attribute is attached to the key, the key doesn't have any other attributes. This make it vulnerable. It is better to combine the key and its attributes _before_ creation of the key. If the attributes are not attached, but an essential part of the key, there is no hole for the MITM. If key and certification are two things, there is the problem of bringing them together. Self-certified keys don't have this problem. (RFC 1824) - There is also question whether the key attributes can be trusted to describe the real key owner well enough. This implies that someone must check the attributes and participate in attaching the attribute or creating the self-certified key. PGP uses key signatures to do so, but there is not much information attached, just name/e-mail-address. As said before there might be interest in describing the key owner in other ways. The authority signing the key must be able to check the description of the key owner. An unorganized web of trust (trust in what? signator knows key owner?) isn't suitable. One reason is that there is much too much overhead in finding a path of trust in the web and storing or retrieving the keys while searching for the path. There must be a systematic, hierarchical organization of authorities which check the key attributes. (We call them SKIA : Secure Key Issuing Authority, see RFC 1824). So I would suggest the following: We create a hierarchy of SKIAs able to check certain attributes. E.g. hostnames and IP addresses might be checked by the same authorities which allow to use them. Key attributes are a composition of the communication addresses of the key owner and his natural attributes a communication partner might be interested in while identifying the peer. Key owner and SKIA create a combination of key and attributes. The key owner deposits his key on all key servers responsible for his comm. addresses. If you communicate with someone known at least by his communication address (otherwise you couldn't communicate), you can easily retrieve all possible public keys of all key owners able to use this address. Now you can decide and choose the key with appropriate attributes (bank account number or whatever). Any comments? Hadmut

1 0

regulation of money transmitters
by cman＠communities.com 17 Dec '03

17 Dec '03

I just had a very pleasant conversation with the California State Banking Department; they are sending me copies of the relevant laws, and applications for the necessary licenses to sell negotiable instruments and transmit money overseas. I spoke with an examiner and she didn't seem to think there was anything special about them being _digital_ negotiable instruments. Apparently it involves a $5,000 non-refundable application fee, background investigations, examination of the soundness of the corporation, and the posting of a bond proportional to the anticipated volume (updated if volume is larger.) All very reasonable. Those who might be intereted in actually doing something with this information should contact Alicia Adoc at (415) 263 8549, or the banking department in the applicable state.

1 0

RSA Data Security, Inc. To Exclusively License Rights to RSA
by baldwin 17 Dec '03

17 Dec '03

Here's the latest press release from my employer. As was pointed out earlier, for those who did not already know, Business Wire articles are written by companies and distributed to news agencies by BW for a fee. --Bob Baldwin ______________________________ RSA Data Security, Inc. To Exclusively License Rights to RSA Public Key Encryption and Digital Signature Standard (DSS) Technologies; Company Becomes One-Stop Worldwide Source for Encryption Technology REDWOOD CITY, Calif.--(BUSINESS WIRE)--Oct. 12, 1995--RSA Data Security, Inc. today announced that it is now licensing patents for the Digital Signature Standard (DSS), the U.S. government standard for digital signatures. RSA also announced that it has renewed its exclusive licensing agreement for the industry-standard Rivest-Shamir-Adleman (RSA) public key cryptosystem developed at the Massachusetts Institute of Technology (MIT). With the addition of DSS technology to its portfolio of encryption offerings, RSA Data Security has become the exclusive source for the industry's most widely accepted security technologies. RSA also announced that under its uniform, non-discriminatory licensing plan, manufacturers will pay a one-time royalty when they sell products containing RSA and/or DSS technology. No additional per-certificate or use charges are required. `For the first time, the patents covering the most popular encryption and digital signature methods in the world, RSA and DSS, are easily available on a non-discriminatory basis from a single vendor,` said Jim Bidzos, president of RSA. `By offering one-stop shopping for both systems, our customers can seamlessly integrate both RSA encryption and DSS digital signature methods into their products.` Widespread Implementation Many of RSA's software licensees -- such as Adobe, Aquila, Atalla, National Semiconductor, Spyrus, Premenos, Spyglass, Terisa Systems, Frontier Technologies, BroadVision, Checkpoint Software, Raptor Systems, SafeCo Insurance, Wollongong, Square D, Interval Systems, and Comm-Press -- have already requested patent licenses to both the RSA and DSS techniques for use in software and hardware systems. IBM and Siemens currently offer DSS-based products, licensed under RSA's DSS patent, to the U.S. government. `Now that vendors can obtain DSS and RSA patents from one source, we expect to see companies throughout the U.S., Europe and Japan incorporate RSA and DSS technology into dozens of products, including access control systems, network management systems, smart cards, link encryptors, and wireless encryption devices,` said Bidzos. `The demand for these technologies is very strong and will continue to grow as vendors increasingly incorporate security features into their products. In the next several months we expect to be inundated with requests from licensees. This is great news for the security industry, which has waited patiently for easy availability of the RSA and DSS patents.` Digital Signatures A digital signature on an electronic document is an encrypted form of data equivalent to a signature on a printed document, such as a contract or other commercial agreement. It verifies that the document is valid and unaltered, and that the person signing the document has agreed to its terms. Furthermore, secure digital signatures cannot be repudiated. The signer of a document cannot disown it by claiming it was forged. Both DSS and RSA support digital signatures and certificates. Several states, including California and Utah have recently enacted legislation recognizing digital signatures as legally binding. License Availability Uniform licenses to both the RSA and DSS/Schnorr patents are available immediately. The license text, as well as other information regarding these patents, is available on RSA Data Security's home page at http://www.rsa.com. For existing customers of RSA's BSAFE and TIPEM software toolkits, no separate patent licenses are required. All rights under the patents to use, integrate and copy RSA's software are embedded. RSA Data Security, Inc. RSA Data Security, Inc. is the world's brand name for cryptography, with more than 15 million copies of RSA encryption and authentication technologies installed and in use worldwide. RSA technologies are part of existing and proposed standards for the Internet and World Wide Web, CCITT, ISO, ANSI, IEEE, and business, financial and electronic commerce networks around the globe. The company develops and markets platform-independent developers kits and end-user products and provides comprehensive cryptographic consulting services. Founded in 1982 by the inventors of the RSA Public Key Cryptosystem, the company is headquartered in Redwood City, Calif. -0- Note to Editors: RSA Public Key Cryptosystem, BSAFE and TIPEM are trademarks of RSA Data Security, Inc. All other product or company names are trademarks of their respective corporations. For information regarding licensing RSA or DSS patents, contact Paul Livesay at RSA Data Security, Inc. (415) 595-8782, or polrsa.com. For information regarding licensing RSA or DSS toolkits, contact Paul Gordon at RSA Data Security, Inc. (415) 595-8782, or paulrsa.com. --30--kr/sf.. CONTACT: Corman/Croel Marketing & Communications Patrick Corman, 415/326-9648 cormancerf.net Lisa Croel, 415/326-0487 lcroelmediacity.com KEYWORD: CALIFORNIA INDUSTRY KEYWORD: COMPUTERS/ELECTRONICS COMED TELECOMMUNICATIONS PRODUCT REPEATS: New York 212-575-8822 or 800-221-2462; Boston 617-236-4266 or 800-225-2030; SF 415-986-4422 or 800-227-0845; LA 310-820-9473 BW URL: http://www.hnt.com/bizwire AP-NY-10-12-95 0701EDT This material is copyrighted and may not be republished without permission of the originating newspaper or wire service. NewsHound is a service of the San Jose Mercury News. For more information call 1-800-818-NEWS.

3 2