December 2003 - cypherpunks-legacy

Thanks!
by johan＠eniac.campus.luth.se 17 Dec '03

17 Dec '03

I have to thank everyone who helped me with using cypherpunk remailers! Thank you very much.. I've got very much response on this so I have to thank you all in this message! Johan Sandberg

1 0

Re: Anonymous Web Browsing
by Powers Glenn 17 Dec '03

17 Dec '03

- From: tcmay(a)got.net (Timothy C. May) - At 5:24 AM 3/2/96, dwhite(a)pris.bc.ca wrote: - > My question is this: Would it be possible to create a web site that - >would function along the same lines as remailers do? Something that would - >allow a person to browse anonymously. So lets say I surfed into a - Tim May writes: - Your intuitions are correct, that protection steps are needed. The - technology is developing, but the perceived need (anonymous browsing) is - probably less than the perceived need for anonymous e-mail. simple, not real secure solutions: find a unix host, run the cern httpd server, turn on proxying, turn off logs. (about 10-15 minute setup) if this is not run often, it works well. use netcom (or something similiar) that gives you dynamic ip addresses. as a bonus, netcom doesn't require an actual name or address. (yes, they require a CC#). this allows fairly anonymous access. (prehaps one reason the neeed for web proxies isn't that high) glenn

3 2

Jim clark spoke last November in favor of GAK
by nobody＠vegas.gateway.com 17 Dec '03

17 Dec '03

Here are Jim Clark's comments in favor of GAK. It should be emphasized that since then, Netscape has officially clarified its position against GAK, and that the actions of the company speak loudly of their support of strong crypto. Nonetheless, these comments were made for the record, so let the record show: ... [Segue from a brief explanation of public key cryptography and certification authorities] So, this is a sophisticated enough system, but you run into a problem. I mean, it all works perfectly. Assuming there's no compromises in the the basic... Assuming there's no holes in the operating system, or no other ways of getting into the computer that's doing all this stuff, then you've got a system that's bulletproof. That's the problem. The government doesn't want it to be bulletproof. And the reason they don't is they want to be able to get access in cases of where there's national security issues or such, they want to be able to get access to your private communications. But you can break that into two parts. There's one area that they don't care about. And that area is if you cannot possibly send an encrypted message to someone... Let's take as an example, you're doing a financial transaction. If that transaction can only... If that communication can only be used to do a financial transaction, such as move money from A to B, or doing a wire transfer of funds, the government doesn't care about that. Uh, maybe they do, but the point is that's not the kind of communication where you're going to possibly say I'm going to blow up the World Trade Center, or some such thing. That's where they're worried. But this whole process leads to a set of questions about how you protect this data encryption technology - how you make it usable in a way that the government finds acceptable, and that you as the individual or you as the corporation find acceptable. And I've been thinking about this a lot. It's clear that this notion of issuing someone a bulletproof key, that is, that create their own private key where they can do any arbitrary communications via email to anywhere in the world with no restrictions and no one can possibly eavesdrop. It's clear to me that that is not going to happen. And the reason it isn't is that the governments of the world aren't going to let it happen. So you might as well sort of accept that at some level the government is going to be able to overhear or eavesdrop certain aspects of what you do. But as I said, the financial aspects, pure financial transactions, not general purpose electronic communications, but pure financial transactions, they really don't care. That isn't what they're trying to eavesdrop. They just want to be able to hear if you're planning on doing some illegal activity. And therefore this idea of key escrow comes up and that's what this chart, this thing is about. Key escrow. For the government, you know your private key, but also the government knows your private key. (now, you can, and so) That's one way to do it. They can always know your private key. You know, you've got a problem with your company too. (but, you know) Most companies are trying to protect the interests of the company and the shareholders, and that means that companies, (I mean I know it, but) I'll bet every single one of your companies has a mechanism to allow them to listen to your email or your voicemail or look at some of that stuff at some point in history because you might be doing something that compromises the interest of that company, illegally. So, even there, you need some mechanism to allow a corporation or the government or someone to be able to get access when they absolutely have to. That's the rub. When is, when do you absolutely need that kind of access? We'd all like to think it's as rarely as possible, and hopefully, never. But I think that these public key cryptosystems have to accomodate that kind of need. They have to allow people in governments to be able to access it. (I, I mean) I just came back from Europe. And, you know, we're allowed to export only the 40-bit version of our product into those countries. Well, I can assure you that's not satisfactory from those (companies') countries' point of view. Companies and the countries of Europe, Germany, France, the UK, want to be able to have just as secure communications as we can have inside our country. Because it's not to do illicit things, it's to protect business secrets, so if they're going to use the Internet for generalized communication they want to be able to protect their generalized communication - against corporate espionage. And that's a very, very valid requirement. And so, I think we're taking the wrong solution if the way we're going to protect information is just to make the keys easier to break, to make the lock easier to break. We have to find a better way. That means you need long keys, you need to have them be bulletproof, but there needs to be some sort of access, and that's where the idea of key escrow comes. But I think the key escrow idea is a little bit wrong, because I think what you really need is the ability to... Think of it this way; if I've got a lock, my key will open the lock. But I may want to have another keyhole, where someone else's key will open that lock as well. That other key might be the government's key. It might be the key of my corporation if I'm doing corporate business. (but) Or for example, you might have a health record, you know, a medical record. You want to protect that. That's your private information. But what happens when you're disabled, and there's an emergency you need to get access to your health data, then there needs to a be keyhole to allow people to open the lock in that case too. So there's a kind of a diferent concept or a different mechanism - multiple keys opening a lock, for example. There's one potential way, and what we need is an electronic equivalent to that, I think these things will come along very shortly. You might also want to have unanimous, all keys have to be inserted into the lock, kind of like the infamous red button that launches missiles. The president and several other people have to have access to it. This is the general concept, and I think that's what we're going to have to have in a data security sense. So, I have spent some time talking about the company Netscape, a little bit about security in general... Transcribed from: DCI Email World and Internet Expo held in November 95 in Boston. DC9523 session 100 - Security on the Net. Tape is available from Conference Copy Inc. http://www.confcopy.com/TAPES

1 0

[AUSTIN] Local Cypherpunks Meeting Saturday
by combee＠sso-austin.sps.mot.com 17 Dec '03

17 Dec '03

Here is your friendly reminder of the Austin Cypherpunks meeting tomorrow, Saturday the 2nd. We'll meet at the Central Market Cafe at 38th and Lamar at 6PM. Topics include the video (I'll have a camera!), ITAR relaxation, RC4 now being called PC1, how to duck the CDA using crypto, hardware random number generators, and stuff like that. The meeting should go around 2 hours depending on the crowd, and there is a Bookstop next door if you want to browse some reading material later. Look for the people with technical books and/or crypto-related shirts. They will be us. (I'm sending this to both austin-cpunks and cypherpunks.) -- Ben Combee, CAD Software Developer, small language enthusiast, HTML dude Motorola, Paging Products Group, Strategic Semiconductor Operation--Austin E-mail: combee(a)sso-austin.sps.mot.com Phone: (512) 891-7141

1 0

Location of Cyphermericon?
by Laszlo Vecsey 17 Dec '03

17 Dec '03

Where can I find it? Please send ftp or URL via private E-Mail. (define(RSA m e n)(list->string(u(r(s(string->list m))e n))))(define(u a)(if(> a 0)(cons(integer->char(modulo a 256))(u(quotient a 256)))'()))(define(s a)(if (null? a)0(+(char->integer(car a))(* 256(s(cdr a))))))(define(r a x n)(cond((= 0 x)1)((even? x)(modulo(expt(r a(/ x 2)n)2)n))(#t(modulo(* a(r a(1- x)n))n))))

1 0

Re: Anonymous Web Browsing
by Bill Stewart 17 Dec '03

17 Dec '03

At 03:44 PM 3/2/96 +0000, "Mark Grant, M.A. (Oxon)" <mark(a)unicorn.com> wrote: >> These are "web proxies," and searching on this should produce some >> information to answer your questions. >.... hidden mailto: .... even worse with Javascript. > >Note to Netscape people: Is it possible to have an option that will *always* >pop up a mail window and request confirmation before mail is sent out? Or >disable mailto altogether? It would be a lot easier than binary editing >the executable to remove all the mailto strings... At least in the Windows version, you can set the SMTP server you want to use for your outgoing mail. So you could do a proxy email server that listens for SMTP and pops up confirmations for outgoing traffic. For the moment, you'd probably have to write your own, but the new Winsock Remailer probably has the code you need to do most of the work, and you'd only have to add some GUI buttons and whistles. #-- # Thanks; Bill # Bill Stewart, stewarts(a)ix.netcom.com / billstewart(a)attmail.com +1-415-442-2215 # http://www.idiom.com/~wcs Pager +1-408-787-1281

2 1

Re: A brief comparison of email encryption protocols
by Joseph M. Reagle Jr. 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- At 07:20 PM 2/29/96 -5300, Adam Shostack wrote: >key://ftp.clark.net/pub/u/cme/cme-current.asc >key://ftp.clark.net/pub/u/cme/cme-longterm.asc Just as a head up on not duplicating work with regards to incorporating URL's into key certificates and DBs you might want to consider URI's, URC's or URN's as the piece to bind since URL's are considered to be almost as unstable as email.. Check out for more on these naming schemes. Linkname: WRL: Web: URXs URL: http://webreference.com/urx.html -----BEGIN PGP SIGNATURE----- Version: 2.6.3i Charset: cp850 iQCVAwUBMTcfaP0Ael7bLK1/AQG56QQAxr+Tii4UMytdQUXIrKzIp2ckY4UfbGqW BpkduSxha0lL8Mo2kmzOL4Z3s4NiJMExvzUKOo6Y16MuCXhKgJyxH5VN+Nk1Y/ov qNpm4zaFOiAFQTbjMhSWJgFGmm6uaHuOez5jZDpSCpZTSBbXUwR349lxXjEtuvy8 hm+w0ADr/VQ= =SYWa -----END PGP SIGNATURE----- _______________________ Regards, There is no point at which you can say, 'Well, I'm successful now. I might as well take a nap.' -Carrie Fisher Joseph Reagle http://farnsworth.mit.edu/~reagle/home.html reagle(a)mit.edu 0C 69 D4 E8 F2 70 24 33 B4 5E 5E EC 35 E6 FB 88

1 0

Re: [ Death of MOSS? ]
by galvin＠eit.com 17 Dec '03

17 Dec '03

At 1:17 PM 2/29/96, Housley, Russ wrote: >Jim, in what way does the end user distinguish between the MOSS-like >integration and the S/MIME-and-MSP-like integration? It seems to me that a >good user agent implementation provides the same services to the user. Russ, since you weren't present at the workshop I'll repeat the very first words I said in the presentation I gave there. Functionally, from a user's perspective, there is for all practical purposes no difference between any of these technologies. Today I would add that we could pick one out of hat and just move on. However, there are differences in the technologies. Some are easier to implement, some are more flexible, some perform better, and the list goes on. We need to explore those differences to develop a criteria for evaluating the technologies so we can provide the best possible solution to the user community. I proposed one possible criteria in my presentation, by no means the only one and by no means complete. Jim ---------------------------------------------------------------------------- James M. Galvin galvin(a)eit.com VeriFone/EIT, PO Box 220, Glenwood, MD 21738 +1 410.795.6882

1 0

RE: Nortel "Entrust"
by droelke＠rdxsunhost.aud.alcatel.com 17 Dec '03

17 Dec '03

Applied Crypto 2nd Edition - page 334-335. Brief stuff: Block Cypher (symetrical), 64 bit key, 64 bit block size "The S-boxes are implemenation dependent, but not key dependent." resistant to differential and linear cryptanalysis "Northern Telecom is using CAST in their Entrust security software package for Macintoshes, PCs, and UNIX workstations. The particular S-boxes they chose are not public. The Candadian government is evaluating CAST as a new encryption standard. CAST is patent pending." If you don't have the book - GET IT! ;-) Dan > From: "Stephen A. Gutknecht" <sgutknec(a)computek.net> > To: "'cypherpunks(a)toad.com'" <cypherpunks(a)toad.com> > Subject: RE: Nortel "Entrust" > > I too would like to see an open discussion on this. Microsoft uses this for > their new Exchange Server client/server email product.... > > ---------- > From: Jonathon Fletcher[SMTP:jonathon@japan.sbi.com] > Sent: Friday, March 01, 1996 10:17 AM > To: cypherpunks(a)toad.com > Subject: Nortel "Entrust" > > > Can anyone tell me anything about a product called "Entrust", by Nortel > (Northern Telecom). The notes talk about the software using DES ("which > employs a 56-bit key") so I guess it's single DES, not triple DES. It also > mentions a proprietary algorithm called CAST. > > Is this worthy of further investigation, or is it suspect ? What is > CAST, and would it be classed as snake oil ? > ------------------------------------------------------------------ Dan Oelke Alcatel Network Systems droelke(a)aud.alcatel.com Richardson, TX

1 0

FWD> ADMIRAL WILLIAM O. STU
by Dave Banisar 17 Dec '03

17 Dec '03

Mail*Link(r) SMTP FWD> ADMIRAL WILLIAM O. STUDEMAN Gee I guess we can trust these guys.... ---- CONCORD, Calif., Feb. 28 /PRNewswire/ -- Premenos Technology Corp. (Nasdaq: PRMO), a leading provider of electronic data interchange (EDI) software solutions for electronic commerce applications, today announced the election of Admiral William O. Studeman, U.S. Navy-retired, to its Board of Directors effective immediately. Studeman will also act as consultant on special projects including security and encryption issues. Admiral Studeman, age 56, is the former Deputy Director of Central Intelligence and served for five months in 1995 as the acting Director of Central Intelligence. He retired from the Navy in October 1995. Prior to his assignment at the Central Intelligence Agency (CIA), Studeman was the Director of the National Security Agency (NSA), and before that was the Director of Naval Intelligence. In these positions, Studeman was involved in attempting to develop public policies and technologies that addressed the complex and often conflicting issues of enhanced economic competitiveness, law enforcement's warranted requirement for information transparency in pursuit of criminal investigations, national security interest in combating potential information warfare threats, and the country's overall increased need for enhanced protection of its information-related systems and applications. In commenting on his election to the Board of Premenos, Studeman stated that "Premenos is not only a leader in facilitating the promising future of electronic commerce, it is the first company in the marketplace with a product line for enhanced protection, security and integrity for the Internet and other electronic communications-related business transactions." Studeman added, "In working with Lew Jenkins and others in the company, I have an opportunity to better frame the government-industry dialogue and define the infrastructure, standards, regulatory, technical and other directional factors which must be addressed for electronic commerce -- a rapidly evolving industry segment so fundamental to the future of the American lifestyle and national security." Lew Jenkins, chairman and founder of Premenos said, "The infrastructure for moving critical business data over the Internet is crucial to the success of electronic commerce. We welcome Admiral Studeman to our team and look forward to his help in developing a trusted model for the electronic commerce market and establishing a solid infrastructure similar to the stringent military requirements that have been in place for decades." About Premenos Corp. Premenos is setting the agenda for electronic commerce and EDI through open networks such as the Internet. Premenos EDI software is an enabling strategy for transforming how corporations conduct business in extended enterprises using electronic communications. Templar -- a suite of software and services that enable businesses to send and receive EDI documents securely and reliably over the Internet -- was awarded the EMA '95 Electronic Commerce Product Excellence Award recognizing the most innovative new product debuted at EMA's annual conference. Premenos products support the IBM AS/400, RISC System/6000, HP 9000, SunSparc, Windows 3.x, NT and Windows 95. Premenos has a worldwide presence with sales offices in California, London and Paris. Contact Premenos World Wide Web (WWW) home page at http://www.premenos.com to access over 3000 pages of information on electronic commerce, EDI, standards, as well as Premenos corporate information materials. NOTE: Premenos is a registered trademark of Premenos Corp. All other product and company names are trademarks of their respective corporations. CO: Premenos Technology Corp. ST: California IN: CPR SU: PER

1 0