December 2003 - cypherpunks-legacy

Re: S/MIME and the Future of Netscape
by tcmay＠sensemedia.net 17 Dec '03

17 Dec '03

At 12:54 PM 7/23/95, Bob Snyder wrote: >tcmay(a)sensemedia.net said: >> With regard to SSL and Netscape not being open to outside developers, >> several leading e-mail outfits, including Qualcomm, Netscape, >> Frontier, etc., are working on an interoperable secure e-mail >> standard called "Secure/MIME," or "S/MIME." > >Do you have sources for this information? MOSS is out there at least as a >Internet Draft, and possibly further along, and Steve Dorner of Qualcomm, the >original author of Eudora, is pretty active in the MIME community and I doubt >he would support a second MIME type to do the same thing... Some of you have expressed skepticism about the mention of "S/MIME." The longterm significance of S/MIME is debatable, of course. But here's the press release I got from Jim Bidzos: Date: Wed, 19 Jul 95 10:34:04 PDT From: jim(a)RSA.COM (Jim Bidzos) To: tcmay(a)sensemedia.net Subject: Integrating RSA into Netscape (Netnews and Mail) FYI... RSA News Release For information, contact: Patrick Corman or Lisa Croel Corman/Croel Marketing & Communications (415) 326-9648 or (415) 326-0487 Corman(a)cerf.net or Lcroel(a)mediacity.com Major Networking and Messaging Vendors Endorse Open Specification for Secure E-Mail S/MIME Based on RSA Public-Key Encryption Technology Redwood Shores, CA -- July 24, 1995 -- Several major networking and messaging vendors, in conjunction with leading cryptography developer RSA Data Security today announced their endorsement of a specification for interoperable e-mail security, to be known as "S/MIME", short for "Secure/Multipurpose Internet Mail Extensions". Several of the vendors announced plans to release S/MIME-compliant products next quarter. The S/MIME specification is based on the popular Internet MIME standard (RFC 1521), which provides a general structure for the content type of Internet mail messages and allows extensions for new content type applications... like security. S/MIME will allow vendors to independently develop interoperable RSA-based security for their e-mail platforms, so that an S/MIME message composed and encrypted on one vendor's application can be successfully received and decrypted on a different one. Major vendors who today announced support for the S/MIME secure interoperable e-mail plan include Microsoft, Lotus, Banyan, ConnectSoft, QUALCOMM, Frontier Technologies, Network Computing Devices, FTP Software, VeriSign, Wollongong, SecureWare and RSA. Sophisticated encryption and authentication technology has been viewed as the crucial enabling technology for electronic commerce over the World Wide Web -- but encryption has been slow to come to e-mail, with most packages offering no security whatsoever. "Commercial e-mail packages don't offer encryption because, up until now, there have been few open security specifications," said Jim Bidzos, RSA President. "Internet Privacy-Enhanced Mail (PEM) is excellent for text-based messages. MIME represents the next generation, and has been widely adopted because of its ability to handle nearly any content type. The new S/MIME allows you to secure this rich content." Today's flurry of official endorsements from industry bodes well for the S/MIME plan. "We fully expect S/MIME to be the defacto standard for vendor-independent e-mail encryption. Solid encryption is something that our customers have been asking us for, but up until now, we didn't have a viable option. S/MIME gives them everything they want: RSA encryption, digital signatures, and the ability to mix different vendors' e-mail systems without losing that security," said Bob Dickinson, ConnectSoft Vice President and General Manager Consumer Online Products & Services Division. "Frontier Technologies believes that in the future most companies will routinely encrypt electronic mail messages sent over the public Internet," said Dr. Prakash Ambegaonkar, Frontier Technologies' president. "This will only happen once there is a well-understood standard for secure e-mail that is easy to implement. Frontier has several years experience in developing secure e-mail solutions. In order to speed the adoption of the S/MIME specification, Frontier Technologies intends not only to be one of the first vendors to support S/MIME in its networking software, but to also make our initial implementation of the S/MIME protocol freely available for other vendors to use as a reference." "The freedom to have a private conversation is fundamental to personal communication that is the essence of electronic mail," said John Noerenberg, Director of Engineering for QUEST products at QUALCOMM. "Wide-spread acceptance of specs like S/MIME make it possible for individuals and organizations alike to conduct their business over the net secure in the knowledge that their private business is, in fact, private." "FTP Software is glad to endorse the S/MIME blueprint for secure electronic communication," said John O'Hara, director of development for FTP Software. "Whether communicating with customers, business partners or remote offices, companies need to ensure that confidential information stays confidential. This was difficult in the past, since organizations are connected through diverse messaging systems from competing vendors. S/MIME eliminates those barriers by facilitating implementations across multiple vendor products." "Network Computing Devices is commited to answering market demand for network information access software providing an even higher level of protection and interoperability over LANs and across the Internet," said Mike Harrigan, co-founder and vice president of NCD. "S/MIME will further enhance our customers' ability to utilize our e-mail solution, Z-Mail, and Internet navigation software tool, Mariner, in such a secure networked environment. For this reason we fully intend to support the specification provided by S/MIME within the next quarter." This wll be an exciting catalyst for the rapid deployment of secure, interoperable e-mail from most of the industry leaders," said Web Augustine, VeriSign vice president of marketing & business development. "VeriSign is committed to making our Digital ID services available to all companies that implement S/MIME and desire to work with a trusted third-party to certify public keys for their end-users." S/MIME is based on the intervendor PKCS (Public Key Cryptography Standards) which were established by a consortium of RSA, Microsoft, Lotus, Apple, Novell, Digital, Sun and the Massachusetts Institute of Technology in 1991. PKCS is the most widely implemented suite of commercial cryptographic standards in the United States. The common PKCS specifications allow developers to independently develop secure applications that will interoperate with other PKCS-secured applications. Developers interested in S/MIME can get more information at RSA's web site, at http://www.rsa.com, in the "What's New" section. RSA Data Security is the world's "brand name" for cryptography, with over 10 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 developer's kits, 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, California. S/MIME Vendor Contacts: Connectsoft Tamese Robinson 206/450-9965 Frontier Dennis Freeman 414/241-4555 FTP Software Jill Dudka 508/659-6458 Qualcomm John Noerenberg 619/597-5103 Microsoft Tom Johnston 206/936-3233 Lotus Kevin Kosh 617/860-5632 Wollongong Bob Brodie 415/962-7203 Banyan Jay Seaton 508/898-1000 NCD Mike Harrigan 415/694-0663 SecureWare David Luther 404315-6295 VeriSign Web Augustine 415/508-1151 ### RSA Public Key Cryptosystem and PKCS are trademarks of RSA Data Security, Inc. All other product or company names are trademarks of their respective corporations.

1 0

MSN privacy
by Tom Bizzell 17 Dec '03

17 Dec '03

Here is some info that was circulating around our office today. > *** Forwarding note from KKASTRP --RHQVM12 07/10/95 10:43 *** > To: KURT --RHQVM02 Anderson, K. K. LLANDER --RHQVM17 Anderson, L.L. > > Karen R. Kastrup 8/826-4664 9/(914)766-4664 > Manager, Services Accounting > Somers 4, 3J36 > Subject: Windows 95 > > *** Forwarding note from KASTRUP --ISSCVM 07/10/95 10:31 *** > To: KKASTRP --RHQVM12 > > *** Resending note of 07/10/95 09:43 > STAN KASTRUP > ISSC - INFORMATION STRATEGY & MANAGEMENT > 8/351-3229 9/(914) 288-3229 > SUBJECT: Windows 95 > Amazing! (I chopped off about 10 "forwards.") > ------- Forwarded Message > > > From: Carlos Shaw IBMMAIL:USIB2T2D cshaw(a)vnet.ibm.com > > *************************************************************** > > Subject: news on Windows95 > > ---------------------------------------------------------------------- > > Newsgroups: comp.risks > > From: cnorloff(a)tecnet1.jcte.jcs.mil > > > > Date: Wed, 17 May 95 13:44:40 EDT > > > > Microsoft officials confirm that beta versions of Windows 95 include a > > small viral routine called Registration Wizard. It interrogates every > > system on a network gathering intelligence on what software is being run > > on which machine. It then creates a complete listing of both Microsoft's > > and competitors' products by machine, which it reports to Microsoft when > > customers sign up for Microsoft's Network Services, due for launch later > > this year. > > > > "In Short" column, page 88, _Information Week_ magazine, May 22, 1995 > > > > The implications of this action, and the attitude of Microsoft to plan > > such action, beggars the imagination. > > > > An update on this. A friend of mine got hold of the beta test CD > > of Win95, and set up a packet sniffer between his serial port and the > > modem. When you try out the free demo time on The Microsoft Network, it > > transmits your entire directory structure in background. > > This means that they have a list of every directory (and, potentially > > every file) on your machine. It would not be difficult to have something > > like a FileRequest from your system to theirs, without you knowing about > > it. This way they could get ahold of any juicy routines you've written > > yourself and claim them as their own if you don't have them copyrighted. > > > > Needless to say, I'm rather annoyed about this. > > So spread the word as far and wide as possible: Steer clear of Windows > 95. > > There's nothing to say that this "feature" will be removed in the final > > release. > > > > David > > > > Carlos Shaw | nodeid/userid: stlvm6(cshaw) > > IBM - STL (J95/E443) | (408) 463-4995; (tie) 8-543-4995 > > 555 Bailey Ave | fax (408) 463-4763; (tie) 8-543- > > San Jose, CA 95141 | CompuServe id: 73203,1424 > > Subj: news on Windows95 > > > >ÿÿ > > >-------- End of Forwarded Message > > ------------------------------------- E-mail: dough(a)syntec.com (Doug Hadley) Date: 07/24/95 Time: 10:54:04 -------------------------------------

2 1

NOD_off
by John Young 17 Dec '03

17 Dec '03

7-24-95. NYPaper: "For I.B.M. Faithful, Questions About Windows 95." These are difficult days for OS/2 users."Every time I say I am an OS/2 user, I get immediately marginalized," an elderly woman confided to a young man sitting next to her at last week's OS/2 World convention in Boston. "It's amazing what saying you are an OS/2 user brings out in people." "You just have to explain that you are at the cutting edge of a powerful new technology," the young man advised her with a heavy dose of sarcasm. WRP_spd "Computer Pornography Hearing Will Not Include Expert Witness." The principal researcher in a computer pornography study will not testify at today's Senate hearing on children and computer pornography. Senator Charles E. Grassley, Republican of Iowa, removed the researcher, Marty Rimm, from the witness list late last week, after Carnegie Mellon University announced a formal investigation into whether Mr. Rimm and his faculty advisers had violated academic and ethical guidelines in preparing and publishing their study. WIT_les 1 +1: NOD_off

1 0

re: big dictionaries
by Chris Gorsuch 17 Dec '03

17 Dec '03

Bill, Good point about using a "slow" hash algorithm. A "dictionary" attack on the hash should fail because, in order to currently use the password the old password had to not be in the dictionary in the first place. However "keyspace" attacks (brute force) would still be quite feasible. Would probably want to put something similiar to a salt in there to help increase the keyspace. Keep in mind that the only reason I suggested a hash at all is to prevent an admin who, in general, would not go through the effort to replace login/password or install a sniffer to get your password, but might be "unnecessarily" tempted by having easy to access passwords stored in plaintext on the server (still in a file only the admin could read). Basically just as a method to keep honest people honest. To verify that a user wasn't using a variation on the original, you would want to only store the hash of the original, but do hashes of the variants on the "new" password and compare with the stored hash of the old password. And of course, only store a password AFTER it has been changed. Really paranoid admins should use challenge/response/one-time passwords with/or kerberos. chris gorsuch chrisg(a)ti.com

1 0

Python export-a-cryptosystems
by sdw＠lig.net 17 Dec '03

17 Dec '03

I hadn't seen this on the list, so I'm forwarding it. (I may have skipped it in my 'catchup on a rainy day' mail archive.) A friend arranged a lunch today with Guido (the author of Python, Guido van Rossum <guido(a)CNRI.Reston.VA.US>) and a few other friends. I haven't formed an opinion of Python yet. Notice that bc/dc isn't needed. ------- Forwarded Message Date: 06 Jul 1995 14:20:13 +0000 From: Andrew KUCHLING <fnord(a)maggie.cs.mcgill.ca> To: python-list(a)cwi.nl Subject: Re: Obfuscated Python Following modifications from Richard Jones and Guido van Rossum, we've now achieved a 4-line RSA script. (Shouldn't we all be doing some *real* work, I wonder? :) ) I've added a 2-line one-time pad program, which simply XORs the contents of the two files whose names are provided on the command line. Generation of random data (and securely exchanging it with your correspondent) is left as an exercise for the reader. So, the Python export-a-crypto-system-sigs are: Try: echo 'This is a test.' | rsa.py 10001 1967cb529 #!/usr/local/bin/python -- -export-a-crypto-system-sig -RSA-in-4-lines-Python from sys import*;from string import*;a=argv;[s,p,q]=filter(lambda x:x[:1]!= '-',a);d='-d'in a;e,n=atol(p,16),atol(q,16);l=(len(q)+1)/2;o,inb=l-d,l-1+d while s:s=stdin.read(inb);s and map(stdout.write,map(lambda i,b=pow(reduce( lambda x,y:(x<<8L)+y,map(ord,s)),e,n):chr(b>>8*i&255),range(o-1,-1,-1))) Try: echo 'This is a test.' | rc4.py messagekey #!/usr/local/bin/python -- -export-a-crypto-system-sig -RC4-in-4-lines-Python from sys import*;st,x,y,i2,k,s=range(256),0,0,0,map(ord,argv[1]*256)[:256],1 for i in st[:]:i2=(k[i]+st[i]+i2)%256;st[i],st[i2]=st[i2],st[i] while(s):s=stdin.read(1);x=(x+1)%256;y,c=(y+st[x])%256,len(s)and ord(s);( st[x],st[y])=st[y],st[x];stdout.write(chr(c^st[(st[x]+st[y])%256])[:len(s)]) Try: otp.py message pad >ciphertext #!/usr/local/bin/python -- -export-a-crypto-system-sig -OTP-in-2-lines-Python from sys import*;t=p=1;s,i,j=stdout,open(argv[1], 'r'),open(argv[2], 'r') while(t and p):t,p=i.read(1),j.read(1);t and p and s.write(chr(ord(t)^ord(p))) Andrew Kuchling andrewk(a)cst.ca fnord(a)cs.mcgill.ca (http://www.cs.mcgill.ca/~fnord) sdw -- Stephen D. Williams 25Feb1965 VW,OH (FBI ID) sdw(a)lig.net http://www.lig.net/sdw Consultant, Vienna,VA Mar95- 703-918-1491W 43392 Wayside Cir.,Ashburn, VA 22011 OO/Unix/Comm/NN ICBM/GPS: 39 02 37N, 77 29 16W home, 38 54 04N, 77 15 56W Pres.: Concinnous Consulting,Inc.;SDW Systems;Local Internet Gateway Co.;28May95

1 0

Regulatory Arbitrage Server
by Alex de Joode 17 Dec '03

17 Dec '03

Please check out: 'http://www.replay.com/exon', for the problems and suggestions about the scripts mail Adam Back <aba(a)dcs.ex.ac.uk> for flames mail me. Have Fun! -- Alex de Joode Fear Uncertainty and Doubt, Inc.

1 0

IPSEC
by perry＠imsi.com 17 Dec '03

17 Dec '03

For those interested in reading up on the IPSEC work, check out ds.internic.net's "internet-drafts" directory. The following are the drafts that you will want to look at. draft-ietf-ipsec-ah-md5-03.txt draft-ietf-ipsec-arch-02.txt draft-ietf-ipsec-auth-02.txt draft-ietf-ipsec-esp-01.txt draft-ietf-ipsec-esp-des-cbc-04.txt draft-ietf-ipsec-photuris-02.txt I believe that the -ah-xx.txt draft is missing. Perry

2 1

Re: An idea about Java and remailer clients and servers...
by cman＠communities.com 17 Dec '03

17 Dec '03

> I forgot to add. There is no reason User X has to run his remailer >immediately. His software could simply commit to running a remailer for >1 hour at some specified future date < some threshold. Any messages >sent to him for remailing would be queued until that time. Therefore, >all your technique would tell you is that the user remailed a message >sometime between date X and date Y. if Y-X > few days to week or two, >the intelligence gathered on User X is miniscule. Traffic analysis would >detect User X using the remailer network anyway. > When I've thought about this, it's been from the p.o.v. of message senders being able to earn prepaid service tokens (not unlike digital cash) for offering their machine as a remailer for a set period of time or number of message or total bandwidth or whatever. This activity could be completely asynchronous to any origination of messages, and, in fact, a regular habit of accumulating tokens like this would make for excellent cover traffic.

1 0

R. v. Pecciarich decision is online (fwd)
by craig＠passport.ca 17 Dec '03

17 Dec '03

Forwarded message:

1 0

Re: An idea about Java and remailer clients and servers...
by anon-remailer＠utopia.hacktic.nl 17 Dec '03

17 Dec '03

Phil Fraering writes: > Why not "charge" for the ability to send an anonymous message with > the duty to have for a short time (maybe an hour or two) running > on your machine a node in a remailer network? User X on Machine A sends a form via HTTP (or a variant- SHTTP, HTTPS, etc.) to Machine B. User Y on Machine C receives an anonymous mail from Machine B. Suspecting User X, User Y sends a mail to be anonymized and sent back to himself to User X. User X's temporary remailer does as it's told. User Y now has a strong reason to suspect User X has sent the said mail. Cpunks write code and all, but I don't think this one's going to work. :-(

4 4