December 2003 - cypherpunks-legacy

Re: X.509, S/MIME, and evolution of PGP
by Carl Ellison 17 Dec '03

17 Dec '03

>Date: Wed, 27 Sep 1995 15:22:08 -0700 >From: Bill Stewart <stewarts(a)ix.netcom.com> Bill, >I'd always heard X.509 public key certificates were a hierarchical, evil, >anti-WebOfTrust ISOism. But Netscape is now doing them, and talking S/MIME, >so I sat down to read the specs, and they're really not all that bad. I was all set to scream, when I read this first sentence. Then I read on. >(Technically, I've only read PKCS#6 and RFC 1422, and not the real ISOisms...) >Yeah, they've got lots of clunky ASN.1 Ambiguous Encoding Rules and X.500 >Silly Name Format, but those can be lived with, and the X.500 may be possible >to simply ignore in most cases. At this point, I realized that we agree in evaluation but not in weighting. Twice now, I have had to deal with X.509 certificates in real code and it is excruciatingly painful -- especially for someone, like me, with some background in performance engineering and much background in software engineering. ASN.1 is not merely ambiguous, it is actively wrong as part of a design methodology. It encourages people to define structures in the BNF style -- and they do (witness X.509). When you translate this into C or PASCAL structures by an automatic translator, you end up with structures whose definitions are nested so deeply that even with short field names you would have variable names which occupy a substantial part of a line of text. However, ASN.1's BNF-ness encourages people to use longNamesWithEmbeddedCapitals -- so you end up with variable names which turn routine C function calls into multi-line, unreadable blocks. You also end up with too much code. I recently had to deal with X.509 certs for an authentication application (a firewall proxy). The proxy was about 30KB of code prior to the ASN.1. The ASN.1 code, just to do packing and parsing, was over 100KB (.o file sizes, in both cases). You also end up with too many bytes being transferred. I worked out an example of ASN.1 abuse -- defining a triple-DES key structure for encrypting and transmittal -- as a raw C structure (following long established practice and performance engineering (an array of unsigned char, with offsets for each key and the IV)) and as ASN.1 (following modern ASN.1 practice). The raw C structure was 32 bytes long. The ASN.1 structure was 86 bytes. Worse was the code dedicated to structure definition and packing/unpacking. In the raw C case, it took 48 ASCII characters to define the structure and its offsets (including comments) and nothing to pack/unpack. With ASN.1, it took 55085 characters of definition, pack and unpack code. This is a factor of 1148 in source code expansion. -------------------------------- I could go on at length, and have in other fora. Not only is ASN.1 clearly the work of Satan, the Distinguished Name definition is more than a victim of ASN.1 generality, it is a clear reason for the unpopularity of systems which use it. Do you remember when X.400 names started showing up in e-mail (e.g., with Lotus Notes). How many of those names do you see now? It didn't work. The concept is flawed -- but it lives on in X.509. [It reminds me of a flaky grad student's idea of a way to do things -- elevated to standard before people had the chance to try it and discover how completely bogus it was.] It is possible to implement something which reads and writes ASN.1 -- but it is ugly, it inflates your code and it hurts your runtime. I would like to see as many hold-outs against ASN.1 and Distinguished Names as possible. PGP is one such. TIS/MOSS has learned its lesson (from PEM days) and is making all of the ASN.1 and DN stuff (X.509) optional. With luck, the X.509 parts will die away (although MOSS was retarded so strongly in the PEM days that it may never recover -- may never acquire the market share to make it a force). I would strongly encourage others to join the battle. This might not be easy. It is clear that there is an ASN.1 juggernaut. It is taking over all sorts of standards. I believe I know why. It makes the job of the standards writer easier. However, I also believe it needs to be fought...not merely to save future S/W development efforts from the waste and abuse which ASN.1 creates, but also to take a stand against the process by which non-implementors get together on standards committees and come out with standards which preclude good software architectures -- and who, in a kind of old-boy-network, endorse other standards (e.g., the ISO set) as part of their own. Such a design process is destructive. - Carl +--------------------------------------------------------------------------+ |Carl M. Ellison cme(a)tis.com http://www.clark.net/pub/cme | |Trusted Information Systems, Inc. http://www.tis.com/ | |3060 Washington Road PGP 2.6.2: 61E2DE7FCB9D7984E9C8048BA63221A2| |Glenwood MD 21738 Tel:(301)854-6889 FAX:(301)854-5363 | +--------------------------------------------------------------------------+

2 2

One-Time-Pad generation from audio device
by Rev. Mark Grant 17 Dec '03

17 Dec '03

Over the weekend I hacked up a one-time-pad generator from the random number code I've been writing for Privtool, which uses noise from the audio device to generate random numbers. The code basically reads in a 512-byte block from /dev/audio, then takes the MD5 of that block to generate 16 bytes of the OTP. The raw audio data I'm getting is not particularly random and will compress by 3:1 using gzip or compress, so I'm assuming that using a 32:1 ratio here via MD5 will give a truly random output (it's certainly uncompressible). Before I release the source code to the Net, can anyone give me any good reasons to believe that this won't produce physically random output, or make suggestions on how to test, or improve, the generated output ? There's a #define which can be used to easily increase the amount of data fed into the MD5, but at the moment it will only generate about 1 MB per hour on a Sparcstation (limited by the audio input rate), so I don't want to increase that if I don't have to. Mark

3 3

Introducing Johnson-Grace
by Publisher Program 17 Dec '03

17 Dec '03

Dear Web Publisher: You may have never heard of Johnson-Grace Company, but you have probably seen the benefits of our image compression technology in America Online and Apple's eWorld. "ART" compression substantially speeds up image transfers. In fact, ART formatted images transmit three times faster over conventional telephone lines than old-style GIFs and JPEGs. The immediate benefit is dramatically more compelling online content. Many of the hottest areas on AOL and eWorld are taking advantage of ART technology, including ABC, Business Week, The Smithsonian, NY Times, and 800-Flowers. Now, Johnson-Grace is able to offer the same benefit to Web publishers. To help you immediately reap the rewards of ART image compression on your Web site, Johnson-Grace is offering publishers the latest copy of our ART Press(TM) on a FREE trial basis for the remainder of calendar 1995. ART Press lets you easily convert your images to the ART format with its unique Web and online publishing features. For example, our proprietary Splash(TM) feature displays a full-size image in roughly one second; the image then becomes sharper as more detail is received and decompressed in additional layers, producing a high-quality final image within seconds. To get your free trial copy of ART Press, simply sign up for the "Johnson-Grace Publishers Program," a new program designed specially for Web and online publishers. At the foot of this email is an enrollment form. Just fill it out and email or fax it back to us. We'll send you the software right away (usually within 24 hours). For even faster results, just sign up online through the Johnson-Grace Web site (http://www.jgc.com/) Besides receiving ART Press, another prime benefit of joining our Publishers Program is that you will be automatically notified when any new versions of the software become available. Here are two more benefits: * FREE Technical Support -- For the remainder of calendar 1995 you will receive free expert technical advice on using ART Press. Support is available by email or by phone. * FREE Image Compression -- To help you get started with ART Press, Johnson-Grace will compress your original images into the ART format free of charge. Simply provide them to us in BMP, TIFF, or PICT format, and we'll do the rest. We've devised a method for allowing both ART and non-ART images to be accessed from your Web site depending on whether or not an ART-enabled browser is being used. Johnson-Grace and some of the larger browser companies have introduced a new extension to HTML, the X-ALTSRC attribute in the <IMG> tag. (<IMG> is the standard tag used to insert images into a Web page.) It indicates to ART-enabled Web browsers that an ART image is present. When an X-ALTSRC attribute is found, ART-enabled browsers will automatically use the ART image named in it, bypassing a SRC attribute it may find naming a GIF (or JPEG) image. Browsers that do not recognize the X-ALTSRC attribute will ignore it and read the SRC attribute instead, so there's no risk of incompatibility with these "old-style" browsers. Currently, AOL's built-in TurboWeb browser as well as other Web browsers including GNN and TeacherSoft recognize this new HTML attribute, representing a community of well over three and a half million users. As announced by Netscape, Johnson-Grace will be one of the first companies to provide a free plug-in for Netscape 2.0 which will allow Netscape users to take advantage of the ART format. This plug-in will be delivered as a "virtual bundle" so that support for the ART format will be automatically added to the browser the first time an ART image is encountered. Additionally, Johnson-Grace is in discussions with all the other major Web browser companies to include ART technology in their products. We expect broad support by the end of the year. Check out the Johnson-Grace Web site (http://www.jgc.com) to learn more about how to use ART's triple-speed advantage on your Web site. You'll also find a host of other useful information there designed specifically for publishers. In the months ahead, look for Johnson-Grace to provide additional "Instant Publishing" capabilities for Web and online service publishers. For example, later this year you'll see news of ART speech compression technology that will enable publishers to author interleaved sound and images for real-time playback at 14,400 bits per second. Think about what real-time sound can do for your Web pages! If you have any questions about the program, feel free to email techsupport(a)jgc.com. You can also call Tech Support at (714) 759-0700, or fax us at (714) 729-4643. Best regards, Geoff LeBlond VP, Licensing Johnson-Grace Company Enrollment for Johnson-Grace Publishers Program Please provide the following information to enroll in the Johnson-Grace Publishers Program Name: Title: Company Name: Company Address1: Company Address2: Company Address3: Company Address4: Telephone Number: Fax Number: email Address (email address is required to process your request) : Version of Software needed [ ] Windows [ ] Macintosh [ ] Both Type of Publisher (select one) [ ] Newspaper, Magazine, or Newsletter [ ] Merchant [ ] Company (e.g., product and sales information) [ ] Government or Non-Profit Organization [ ] Other (please specify) : Target Audience (check all that apply) [ ] Web [ ] Online Service(s) [ ] Both Web Site Information (1) Home Page Location (URL): (2) Launch Date: (3) Webmaster e-mail address: Note: By sending this registration form to Johnson-Grace Company, you agree to follow the following Publishers Program restrictions. (1) Do not use a trial version of ART Press after the end of the trial evaluation period. (2) Only Web and online service publishers -- defined as companies, organizations, or entities that offer content or information for display on the Web or on an online service for commercial purposes -- may qualify to participate in the Johnson-Grace Publishers Program. (3) Do not distribute copies of the program (all users must enroll), or attempt to reverse engineer the program. (4) Report any problems with the program to the Publisher Support Hotline at internet address techsupport(a)jgc.com, fax 714-729-4643, or telephone 714-759-0700 (ext. 215 or ext. 230).

2 1

Re: More forged cancels (fwd)
by Michael Froomkin 17 Dec '03

17 Dec '03

why is my mailbox full of stuff from mail.cypherpunks? **** PLEASE NOTE NEW E-MAIL ADDRESS: froomkin(a)law.miami.edu ********* A. Michael Froomkin | +1 (305) 284-4285; +1 (305) 284-6506 (fax) Associate Professor of Law | U. Miami School of Law | froomkin(a)law.miami.edu P.O. Box 248087 | http://www.law.miami.edu/~froomkin Coral Gables, FL 33124 USA | New address, but it's still just as hot here. ---------- Forwarded message ---------- Received: from relay3.UU.NET by law.miami.edu (4.1/3.1.012693-University of Miami Law School); id AA16017 for IFS=' '&&exec /home/faculty/froomkin/proc/procmail -t -f-||exit 75 #froomkin; Mon, 2 Oct 95 01:17:37 EDT Received: from toad.com by relay3.UU.NET with SMTP id QQzjqz13374; Mon, 2 Oct 1995 01:16:43 -0400 Received: by toad.com id AA17355; Sun, 1 Oct 95 22:13:04 PDT Received: from hudson.lm.com by toad.com id AA17346; Sun, 1 Oct 95 22:12:56 PDT Received: (from news@localhost) by hudson.lm.com (8.6.11/8.6.9) id BAA09549 for cypherpunks(a)toad.com; Mon, 2 Oct 1995 01:15:28 -0400 Path: hudson.lm.com!news.math.psu.edu!news.cac.psu.edu!newsserver.jvnc.net!newsse… >From: orbit(a)ix.netcom.com (Michael R. Grabois) Newsgroups: news.admin.net-abuse.misc,soc.culture.german,soc.culture.jewish,rec.radio.shortwave,alt.2600,mail.cypherpunks,alt.privacy.anon-server,alt.stop.spamming,alt.stop-spamming Subject: Re: More forged cancels Date: Mon, 02 Oct 1995 03:31:03 GMT Organization: Netcom Lines: 40 Message-Id: <44nmd0$q13(a)ixnews6.ix.netcom.com> References: <44n926$2dj(a)sundog.tiac.net> Reply-To: orbit(a)ix.netcom.com Nntp-Posting-Host: ix-hou6-03.ix.netcom.com X-Netcom-Date: Sun Oct 01 8:30:40 PM PDT 1995 X-Newsreader: Forte Free Agent 1.0.82 Xref: hudson.lm.com news.admin.net-abuse.misc:16173 soc.culture.german:76152 soc.culture.jewish:188004 rec.radio.shortwave:63171 alt.2600:125976 mail.cypherpunks:18586 alt.privacy.anon-server:4465 Apparently-To: cypherpunks(a)toad.com Sender: owner-cypherpunks(a)toad.com Precedence: bulk On Sun, 01 Oct 1995 23:45:24 GMT, jbyrd(a)tiac.net (Jim Byrd) wrote: [snip] >-----------------begin control message >Path: >sundog.tiac.net!news.sprintlink.net!in2.uu.net!sunic!mn6.swip.net!seunet!news2..swip..net!plug..ne >ws.pipex.net!pipex!tank.news.pipex.net!pipex!usenet.eel.ufl.edu!news.gmi..edu!msunews!netnew >s.upenn.edu!ts7-28.upenn.edu!user >From: 73323.603(a)compuserve.com >Newsgroups: soc.culture.german,soc.culture.jewish >Subject: cmsg cancel <73323.603-3009951517290001(a)ts7-28.upenn.edu> >Date: Sun, 1 Oct 1995 17:56 GMT >Organization: The National Alliance >Message-ID: <cancel.73323.603-3009951517290001(a)ts7-28.upenn.edu> >NNTP-Posting-Host: ts7-28.upenn.edu >Approved: 73323.603(a)compuserve.com >Control: cancel <73323.603-3009951517290001(a)ts7-28.upenn.edu> >X-Cancelled-By: 73323.603(a)compuserve.com >Lines: 1 >CANCELLED. >----end control message Does this mean that the cancel came from the Compuserve account? Forging cancel notices is definitely against CIS rules, as is unsolicited e-mail. I've already talked to a sysop there about it, and he said he'd pass it along to the CIS Security folks. If nothing else, that may get his account revoked. Hey, small victories. Michael R. Grabois | orbit(a)ix.netcom.com Houston, TX | CI$: 74737,2600 ------------------------------------------------------- Gravity. It's not just a good idea, it's the law.

1 0

Certificate proposal
by Carl Ellison 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- X.509 certificates are not totally bad. Their structure contains lessons for anyone designing a certificate structure. [Raw X.509 does not imply a hierarchy, I believe. Steve Kent & Co. do.] However, there are also some serious problems with X.509 certs, aside from their use of ASN.1. Perhaps the biggest problem is the use of a name -- a text string (or some abortion like the DN which can be reduced to a text string) -- as the anchor point. This anchor point needs to be unique. Since it is just a text string, that means that the certificate authority needs to guarantee uniqueness. However, it is also supposed to stand for a unique individual. Since it is not that individual's DNA sequence -- it is not testable. There has to be machinery set up outside the certificate definition for binding this text string to its individual. ------------------------------ PGP certificates have the same problem. In that case, it is an e-mail address and name (by tradition) as the text string. That needs to be bound to some physical body. If it is an e-mail name, there is some binding enforced by whatever access mechanisms protect access to that e-mail account. However, that binding is weak and also outside the certificate definition. ------------------------------ Let me propose an alternative unique name: the public key (or a good hash of it). The public key has an advantage over both X.509 and PGP names. The binding between it and its human being is testable. You can challenge the human in question to sign something. Assuming you use a public key as the unique name, you end up with a much simplified certificate. In fact, the notion of "certificate" may go away, in the sense that the certificate binds a key to a person through a unique name. The person binds himself to his key, on challenge (or on any message signature). What remains is a need for attributes to be bound to a key. For example, someone might testify that E0414C79B5AF36750217BC1A57386478 has brown hair, is balding and wears a pony tail, by signing a message to that effect. Someone else might sign a message stating that the person who owns the private key of 61E2DE7FCB9D7984E9C8048BA63221A2 is authorized to spend money from bank account number 07123 of Provident Savings in Columbia MD. That latter signator needs to be verified as authorized to make such an assertion -- and you end up with a certification chain -- but it is not hierarchical like X.509 and it is not web-of-trust -- it is relational. It is not a chain binding key to person but key's person to attribute or permission. It goes directly to what we need to accomplish without the middleman -- without stopping at a person in the middle. I realize that if you want to revoke a key, then it might help to have bindings be to something other than the key. That way, you can change keys out from under the binding. However, every method I've examined for accomplishing that has security weaknesses. The best method I've found yet has a very long signature key -- used only rarely (e.g., when acquiring an attribute-certificate worth a great deal; and signing more transient keys) -- and never normally revoked (or, if revoked, causing a widespread re-establishment of bindings -- like when you lose your wallet today). ------------------------------ Current certificates are going down a fundamentally wrong path. They are trying to bind keys to people and let Society somehow bind attributes to people -- but the latter binding is too weak to permit keys to be bound to attributes or permissions. The community will discover this, soon, but the farther we play along the X.509 path (especially, but also the PGP path), the more inertia there will be to overcome in trying to fix this problem. I would therefore suggest that the PGP development process address this issue now and continue the established habit of taking the lead into sanity. - Carl +--------------------------------------------------------------------------+ |Carl M. Ellison cme(a)acm.org http://www.clark.net/pub/cme | |PGP: E0414C79B5AF36750217BC1A57386478 & 61E2DE7FCB9D7984E9C8048BA63221A2 | | ``Officer, officer, arrest that man! He's whistling a dirty song.'' | +---------------------------------------------- Jean Ellison (aka Mother) -+ -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMHAK8FQXJENzYr45AQFsdAP+JswAq/H4JIDE3+VlMsi87PBPCNBA7jg7 0ftkd8v7vrSSNda5aF+HVB7oKHylA/Lb90bvjMK7CKOJJ7aTzRP9IsAiz1i48FAR LAeD59v5SAKmAhaTMMYSRyKFRRXEaqIdEoJW3XKQBJ57b8R38vWKjR/11eTtCKjV joH4c5hhWmY= =ayYh -----END PGP SIGNATURE-----

10 16

Re: Yet Another "(Fwd) Internet Euro-Clipper"
by Peter Trei 17 Dec '03

17 Dec '03

> At 5:12 PM 9/29/95, Peter Trei wrote: > >Subject: European Governments Agree to Ban Strong Crypto > The biggest problem I have with this is that this is the third, fourth, or > fifth posting of Ross Anderson's piece to this list [...] > I urge people to read what's on the list and not repost things which have > already appeared. If they don't have time to read all of the messages on > the list, which is understandable, then they need to be even more careful > in posting things. Reading the list does not neccesarily help - I experience a several hour lag between when I post something, and when it comes back from the list server. Thus, even if I'm all caught up on my reading the list (as I was when I posted that article), articles may be 'in the pipe' which duplicate ones I'm thinking of posting. For those curious about the latency, I'm posting this at 12:08, on the US east coast. How long did it take to reach you? > > Not to pick on Peter Trei, as this happens all the time, whenever a hot > issue appears. Short of implementing some content-sensitive form of CSMA/CD, I don't see what we can do (but lowering the list latency would help a lot). > --Tim May Peter Trei Senior Software Engineer Purveyor Development Team Process Software Corporation http://www.process.com trei(a)process.com

1 0

Re: NetScape's dependence upon RSA down for the count!
by cmcmanis＠scndprsn.Eng.Sun.COM 17 Dec '03

17 Dec '03

Don wrote: >I haven't read the SSL spec for a while but my understanding was that >the server passed it's public key to the client via a certificate >signed by a mutually trusted certificate authority (i.e., Verisign). > >How would the filter be able to forge such a certificate ? Why forge it? Why not simply buy a netsite server with a valid certificate. Let's say you paid full list for it $5000. It is the classic MITM attack but the protection against that attack was generally that the parties communicating "knew" each other. This is a fundamental weakness of putting the security at the SSL level as opposed to a possibly higher level. With the netscape attack since your client never cares "how" (or to whom) the SSL connection is made, it never shows you the information about where the source key came from. Only that it is valid. --Chuck

1 0

Re: Yet Another "(Fwd) Internet Euro-Clipper"
by tcmay＠got.net 17 Dec '03

17 Dec '03

At 12:20 PM 10/2/95, Peter Trei wrote: >For those curious about the latency, I'm posting this at 12:08, on the US >east coast. >How long did it take to reach you? I got it at 09:14, Pacific Daylight Time, so there appears to be no lag. I've generally found that lags are on my end, that my system (got.net currently) is delaying mail from _all_ or _most_ mailing lists. (This was particularly the case last week, when Cypherpunks mail stopped for many hours at a time, then arrived out of sequence when my ISP was (presumably) able to receive the resent mail.) >> Not to pick on Peter Trei, as this happens all the time, whenever a hot >> issue appears. > >Short of implementing some content-sensitive form of CSMA/CD, I don't see >what we >can do (but lowering the list latency would help a lot). Well, the main issue with the "Europe to Ban Crypto" reposts was that several people reposted the same press release over a period of several days, and the case I cited here was where it was posted a week later. I can't see how a latency, even a serious latency of several hours, could cause this to happen. Mostly I think people should try to first of all, _write original stuff_. That is, write their own analyses of things. Their own essays, reactions, etc. Then, secondarily, post pointers to longer stuff. Thirdly, and less to be desired, forward articles. --Tim May ---------:---------:---------:---------:---------:---------:---------:---- Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay(a)got.net 408-728-0152 | anonymous networks, digital pseudonyms, zero Corralitos, CA | knowledge, reputations, information markets, Higher Power: 2^756839 | black markets, collapse of governments. "National borders are just speed bumps on the information superhighway."

1 0

My goof on toad.com lags...
by tcmay＠got.net 17 Dec '03

17 Dec '03

A few minutes ago I wrote: --- At 12:20 PM 10/2/95, Peter Trei wrote: >For those curious about the latency, I'm posting this at 12:08, on the US >east coast. >How long did it take to reach you? I got it at 09:14, Pacific Daylight Time, so there appears to be no lag. --- Well, before you all correct me, yes, I now realize it was my copy, sent directly to me, that I received. As of 09:35 I haven't received the toad.com-delivered copy. But my point remains that many times the lags are on local ISP systems, not necessarily on toad. --Tim May ---------:---------:---------:---------:---------:---------:---------:---- Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay(a)got.net 408-728-0152 | anonymous networks, digital pseudonyms, zero Corralitos, CA | knowledge, reputations, information markets, Higher Power: 2^756839 | black markets, collapse of governments. "National borders are just speed bumps on the information superhighway."

1 0

NT and C2
by Weld Pond 17 Dec '03

17 Dec '03

Here is the URL to an article in Network World by Winn Schwartau entitled, "One expert shares his views on Microsoft securitey features. http://www.iquest.net/cgi-bin/gate2?|mmMgT008://bbb.PHDx10.ix0/ibLD1P7i/ExU… If you need a username/password try cypherpunks/cypherpunks Here is an excerpt: Since Microsoft Corp. products are usually robust, I was looking forward to seeing what type of security features the company implemented in Windows NT Workstation Version 3.5. But after walking through the system with Microsoft product managers and developers, I was dismayed to find how woefully short on security features Windows NT is. Despite the fact that the U.S. government is expected to certify Windows NT as a secure operating system, Microsoft's first serious venture into security is not very impressive. Windows NT may pass muster with the federal government, but it does not meet the real-world security needs of corporations running complex, heterogeneous networked environments. Weld Pond - weld(a)l0pht.com - http://www.l0pht.com/~weld L 0 p h t H e a v y I n d u s t r i e s Technical archives for the people - Bio/Electro/Crypto/Radio

2 1

List latency.
by Peter Trei 17 Dec '03

17 Dec '03

> > At 12:20 PM 10/2/95, Peter Trei wrote: > > >For those curious about the latency, I'm posting this at 12:08, on the US > >east coast. > >How long did it take to reach you? > > I got it at 09:14, Pacific Daylight Time, so there appears to be no lag. Here's the relevant headers for the bounceback to me, which took an hour: > Received: from relay3.UU.NET [192.48.96.8] by alcor.process.com > with SMTP-OpenVMS via TCP/IP; Mon, 2 Oct 1995 13:10 -0400 > Received: from toad.com by relay3.UU.NET with SMTP > id QQzjst04916; Mon, 2 Oct 1995 12:51:05 -0400 > Received: by toad.com id AA00166; Mon, 2 Oct 95 09:10:05 PDT > Received: from alcor.process.com by toad.com id AA00160; Mon, 2 Oct 95 > 09:10:02 PDT Message-Id: <9510021610.AA00160(a)toad.com> Received: from thunk > [192.42.95.240] by alcor.process.com > with SMTP-OpenVMS via TCP/IP; Mon, 2 Oct 1995 12:10 -0400 > Date: Mon, 2 Oct 1995 12:14:30 -6 Translating: Sent by thunk.process.com 12:14 EDT Received by alcor.process.com 12:10 EDT -4 minutes (thunk's clock is off) Received by toad 9:10 PDT 0 minutes Received by uunet 12:51 EDT 41 minutes Received by alcor 13:10 EDT 19 minutes It looks like there's a considerable delay entering and leaving uunet. I'm not sure which machine gets the blame, but it's either toad&uunet, or uunet&alcor. Peter Trei Senior Software Engineer Purveyor Development Team Process Software Corporation http://www.process.com trei(a)process.com

2 1

Re: Simple Hardware RNG Idea
by Dave Dittrich 17 Dec '03

17 Dec '03

> Perry writes, regarding alpha decay counts for random numbers: > > > And, as I noted, there are RS232 interfaceable radiation detectors you > > can buy off the shelf -- no hardware hacking needed. > > As far as a radiation source goes, the Americium 241 source from a cheap > smoke detector is just dandy. A while ago, I took one into the lab and > put it on a scintillating counter and got alpha hits at roughly > half-microsecond intervals. It was a while ago, so I forget how this compared > to the rating in Curies on the package. But that would be fine for a > low-to-moderate bandwidth RNG. I was thinking about this the other day and wondered if it wouldn't be cheap and relatively easy to build a board that samples and sums several randomly selected signals on various frequencies on the AM broadcast spectrum. This should catch stations in nearly all metropolitan (and most rural areas as well) and would require that someone be able to broadcast at multiple frequencies to "cheat" it. Perhaps this would be affected by RF interference from the motherboard itself. If so, could the RF radiation from the motherboard itself be used to generate random numbers? -- Dave Dittrich Client Services, Computing & Communications dittrich(a)cac.washington.edu University of Washington <a href="http://www.washington.edu/People/dad/"> Dave Dittrich / dittrich(a)cac.washington.edu</a>

4 5

SSH random numbers
by Lance Cottrell 17 Dec '03

17 Dec '03

I have finaly been goaded into using SSH. I seems like a great tool, but I have one major worry. When I install SSH, it generates the host key right away. When I run ssh-keygen, it generates my user key right away. Where is it getting the random numbers. Before I dive into the source I was wondering if anyone else had looked into this? -Lance no PGP sig because I am on a remote machine. ---------------------------------------------------------- Lance Cottrell loki(a)obscura.com PGP 2.6 key available by finger or server. Mixmaster, the next generation remailer, is now available! http://obscura.com/~loki/Welcome.html or FTP to obscura.com "Love is a snowmobile racing across the tundra. Suddenly it flips over, pinning you underneath. At night the ice weasels come." --Nietzsche ----------------------------------------------------------

1 0

Re: CJR for perl-RSA t-shirt
by Robert A. Rosenberg 17 Dec '03

17 Dec '03

At 20:58 10/1/95, Robert Hettinga wrote: >>Subject: Mass Market Software with Encryption - 15 Day Expedited Review >> Requested >> >>Subject: Commodity Jurisdiction Request for >> perl-RSA t-shirt, an encryption program > >ROTFL! > I agree. I especially laughed at the part that stated "... also as a bar code, making the t-shirt machine readable as well as machine washable."

1 0

Re: List latency.
by Joel McNamara 17 Dec '03

17 Dec '03

As a non-crypto, latency-related, aside. The USENET newsfeed coming out of uunet to my ISP was non-existent last week. It's improved somewhat, but is still lagging behind by 2 or 3 days (never did this in the past). uunet has not provided my ISP with an explanation as to what is happening. Perhaps it's related to the delay in list messages appearing. Unfounded speculation has been the .edu sites are active again after the summer and are swamping things. Joel McNamara joelm(a)eskimo.com - http://www.eskimo.com/~joelm for PGP key Thomas Jefferson used strong crypto, shouldn't you? >It looks like there's a considerable delay entering and leaving uunet. I'm not sure which >machine gets the blame, but it's either toad&uunet, or uunet&alcor.

1 0

Time Lag (was Re: Yet Another "(Fwd) Internet Euro-Clipper")
by patrick＠Verity.COM 17 Dec '03

17 Dec '03

> > At 12:20 PM 10/2/95, Peter Trei wrote: > > >For those curious about the latency, I'm posting this at 12:08, on the US > >east coast. > >How long did it take to reach you? > > I got it at 09:14, Pacific Daylight Time, so there appears to be no lag. I got it at 11:53 PDT. I just checked the headers and the delay was split in a couple of places. (Correcting all times for PDT) thunk -> 9:10 -> alcor.process.com. (And they're off and running!) alcor.process.com. -> 9:10 -> toad.com. (delivered in 0 time:) toad.com. -> 11:29 -> relay3.uu.net. (Sat on toad 2hrs, 19 min) relay3.uu.net. -> 11:54 -> mail2.pilot.net. (Sat on relay3 25 mins ) mail2.pilot.net. -> 11:53 -> verity.com. (delivered into the past!) Of course these delays can vary a few minutes either way because of inaccuracies of time clocks on various machines. Patrick _______________________________________________________________________ / These opinions are mine, and not Verity's (except by coincidence;). \ | (\ | | Patrick J. Horgan Verity Inc. \\ Have | | patrick(a)verity.com 1550 Plymouth Street \\ _ Sword | | Phone : (415)960-7600 Mountain View \\/ Will | | FAX : (415)960-7750 California 94303 _/\\ Travel | \___________________________________________________________\)__________/

1 0

Re: Certificate proposal & X509 clarifications
by baldwin 17 Dec '03

17 Dec '03

The Distinguished Name of X509 is NOT intended to be the unique identifier of a person or a public key. In the X509 world two different DNs can have the same public key, and a single DN can have multiple certificates with possibly different public keys. The same public key naturally appears in multiple certificates when each certificate is only valid for a certain period of time (e.g., weekly certificates have been proposed for applications that do not want to implement revocation lists). The unique identifier in an X509 certificate is the DN of the issuer and the serial number that the issuer attached to the certificate. Both of these fields appear in the version 1 X509 certificate. Of course, this assumes that issuers are following the rule of not issuing two certificates with the same serial number. The designers of version 1 of the X509 certificate format have realized that they need to allow issuers to attach all kinds of different attributes to a public key. This lead to version 3 of the X509 format, which provides for general extensions. Of course, this means that there is more rope to hang yourself with when it comes to designing an overall system, but with careful design, lots of good things can be done. For example, for the S/MIME secure mail effort, the certificates include the email address of the owner, as certified by the company that is providing the email post office (e.g., the employer or service provider). Note that Netscape Navigator 2.x will support Version 3 X509 certificates and S/MIME. Question: what's a good way to have the existing PGP public key infrastructure interoperate with the X509 infrastructure? --Bob

2 1

Crypto APIs
by Matt Blaze 17 Dec '03

17 Dec '03

A couple of weeks ago I attended a meeting at the NATO SHAPE Technical Center in the Hague to discuss international cryptographic APIs. Several high-ranking NSA types were there, as well as their counterparts from various NATO countries plus a handful of industry crypto people (like me). The idea of the meeting was to find a way to separate cryptographic function from cryptographic interfaces, in a way that allows the applications that call the cryptographic functions to be more freely exported. That is, I can write and export an application that calls the crypto API but that doesn't actually implement the cryptography, and then, when it reaches its destination, the locally-preferred cryptosystem can be plugged right in. Crypto might be implemented in hardware (e.g., Fortezza) or software (e.g., with a shared library or pseudo-device driver). Obviously, this idea is somewhat (completely?) at odds with the criteria presented at last month's NIST workshops for exportable software key escrow systems. One of the requirements given for such systems is that it be difficult to replace the crypto with something that doesn't implement key escrow. But who ever said the government was consistent? Interestingly, it was clear that many people in NSA believe that applications that call an API are controlled under ITAR, but there is some recognition that this may be wishful thinking or may change soon. So while some (maybe most) of NSA wants to prevent development of standard APIs and prevent the export of applications that use them, others recognize that these will evolve by themselves anyway and will be very hard to control once they do. Anyway, the situation is far from clear. It seems best to encourage the realistic side of NSA as much as possible... I learned a few interesting things at the meeting. First of all, overwhelmingly, there is recognition, especially on the part of the non-US government security agencies, that there is enormous value in being able to buy off-the-shelf applications like Microsoft Word or Netscape Navigator and just plugging in the local military cryptosystem and using it for classified traffic. Everyone seemed to agree that there is a growing need for this and that it's too expensive to rely on custom software. There is also movement away from the traditional military ``link encryption'' approach that involves centrally- controlled secure networks in favor of a ``risk management'' approach that favors end-to-end security with off-the-shelf products. In other words, the parts of the military that are concerned with actually securing communications want exactly what we want, and are just starting to realize it. While lots of us have always known this, I had never heard it articulated as quite clearly (or as loudly) by actual comsec/infosec people before. Second, the senior NSA guy mentioned a few things I hadn't heard before. Fortezza is now approved for classified traffic through the SECRET level. Also, the ``type 1'' (classified) through ``type 4'' (unevaluated) cryptography standard is being scrapped in favor of a three ``tier'' system, as follows (these are approximate quotes, from my rough notes): Tier 1 traffic is stuff related to ``national command authority''. (Seems to be secret and top secret and up). It will require NSA cryptosystems, hardware implementation, and will NOT employ key escrow (because of the ``obvious risks''!). Tier 2 traffic is information that, if disclosed, would have ``national implications'' if revealed. Examples given include things like the national power grid, the banking system, etc. It was unclear whether any classified traffic would be included in tier 2. Clearly, some of what is now called ``sensitive but unclassified'' (SBU) will be in tier 2. Anyway, tier 2 systems will be approved by NIST (not NSA, although there will obviously be NSA input into the standards) and will require hardware implementation. Tier 2 traffic will be escrowed, and the government will escrow its own keys. Fortezza is an example tier 2 device (but read on...) Tier 3 traffic will be that which would have ``private implications'' if disclosed. Examples given included personal financial and medical records, etc. Current SBU traffic not in tier 2. Tier 3 would also be handled by NIST, employ commercial or government key escrow (like tier 2) and would be permitted to be implemented in software. Here's the surprise: Tiers 2 and 3 will be interoperable. So there will be published algorithms for tier 3. It is possible that tiers 2 and 3 will have the same algorithms, and that the government will suggest them. It was unclear with interoperability will require that all tier 2 algorithms will be published and implementable in tier 3 software or whether this means that tier 2 devices will also have to implement the tier 3 algorithms. There is an obvious choice of a tier 2/3 algorithm: Skipjack (although there were concerns that this is ``too slow''). So we may eventually find out whether ``S1'' was really Skipjack after all.... -matt

2 2

Re: worldwide announce: New OTP Mail/FTP apps
by Carl Ellison 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- >From: Doug Hughes <Doug.Hughes(a)eng.auburn.edu> >Date: Thu, 28 Sep 1995 19:31:00 -0500 >A company in Israel named Elementrix has just announce at Interop an >entirely new paradigm in secure transactions. They have a secure >one time pad that allows people to exchange mail and ftp files back >in forth in complete security without the worries of key management >or storage or secure random number generation or synchronization. As far as I could tell from your description, this is an autokey cipher -- not a OTP. An autokey cipher starts with a shared secret key and uses previous plaintext or ciphertext as part of the key. DES CBC is an autokey cipher. The original autokey used previous plaintext or ciphertext as the only key. More modern ones mix in the previous text. I had a design for one, several years ago, which kept a mapping in memory and changed the mapping based on incoming plaintext. Therefore, there is state information kept at both sides which keeps changing. One might think that if the attacker never gets in, today's randomness is just as good as yesterday's. That might even be true. However, there are many openings for finding relationships between yesterday's and today's ciphertexts. I look forward to seeing the actual algorithm. - Carl +--------------------------------------------------------------------------+ |Carl M. Ellison cme(a)tis.com http://www.clark.net/pub/cme | |Trusted Information Systems, Inc. http://www.tis.com/ | |3060 Washington Road PGP 2.6.2: 61E2DE7FCB9D7984E9C8048BA63221A2| |Glenwood MD 21738 Tel:(301)854-6889 FAX:(301)854-5363 | +--------------------------------------------------------------------------+ -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMHBTU1QXJENzYr45AQHRigP/Yqw0T3n2SDubgRZIrKx8WpUSJtmBwcuf nIBxxwsOwu10sQti7hw3Zcj9tRM6JAcqFNh1U2LbYT3u7ELgh2Hicq0jLcr+3r4h B0H3LlbU9iv7WlETQF8Tw2KQcfDKLkYkeMRnS27cKnJIFHK9w0g4UTwabfB+m5SV sjnUZbv6Q1A= =P9X7 -----END PGP SIGNATURE-----

1 0

Re: The Free Speech Implications of Remailers
by James Caldwell 17 Dec '03

17 Dec '03

On 1 Oct 95 at 22:32, Timothy C. May wrote: > Crypto anarchy means the racists, sexists, speciesists, and other > "ists" cannot be muzzled. I call this a good thing. It's why I'm > here. I don't mind the mail, it's in a bit bucket, just the cowardly nature of it. It was not sent anonymously which can be filtered. I appologize for spamming the list in response to hi message, it upset me.

1 0

Re: The Free Speech Implications of Remailers
by Lynne L. Harrison 17 Dec '03

17 Dec '03

At 10:32 PM 10/1/95 -0700, Tim May wrote: <snip> >Well, guess what? The very technologies we have been so central in >deploying are the technologies that make _conventional_ means of >controlling distasteful material so hard. >system of the various mail delivery systems.) <snip> >Crypto anarchy means the racists, sexists, speciesists, and other "ists" >cannot be muzzled. I call this a good thing. It's why I'm here. Excellent analysis. One can't argue with logic, nor should one forget the purpose and spirit of this list. The fact that spamming is in poor taste is irrefutable. However, some of the "where did this come from"? responses are starting to sound like some people are suddenly against the use of anonymous remailers. I, for one, would hope that people are simply rising to the challenge of tracing the routers. Kill the message if you are so moved -- not the technological messenger. ******************************************************************** Lynne L. Harrison, Esq. Poughkeepsie, New York lharrison(a)mhv.net "Say not, 'I have found the truth', but rather, 'I have found a truth.'" - Kahlil Gibran from "The Prophet" ********************************************************************

1 0

Re: NetScape's dependence upon RSA down for the count!
by David_A Wagner 17 Dec '03

17 Dec '03

In article <9509301910.AA10970(a)dmsd.com> you write: > > The "messenger attack" as described in my earlier posts regarding > public key encryption and key management seems to apply to NetScape's SSL. > I have a Fifty dollar bill for the first person to submit to the mail box > nethack(a)dmsd.com a working Unix server (with cleartext session logs) which > accepts all connections on a unix based host to the www port and redirects > them to netscape.com leaving a clear text log of each session's SSL packets > in /tmp by session. All entries become the property of DMS Design. The winner > and I will submit a claim for one of Community COnneXion's "I HACKED NETSCAPE" > tee shirts as a server hack. (Have Fun!!) > This is a trivial program! I can't believe anyone considers this technically difficult. But hey, who am I to question, if you'll pay $50! Ok, let me back that up with real code. Here's a proxy I've been using for experimenting, in lieu of root access & tcpdump. Usage: proxy localport remotehost remoteport > capturefile Try: $ ./proxy 2999 www.netscape.com 80 > capturefile & $ netscape http://localhost:2999/home/welcome.html & or $ ./proxy 3999 alpha.mkn.co.uk 443 > capturefile & $ netscape https://localhost:3999/ & Here's the source. It's a bit unstable, and could be a improved a little, but was fine for a quick kludge. So feel free send the $50 to the following address at your convenience!! :-) David Wagner UC Berkeley 330 Soda Hall Berkeley, CA 94720 #include <stdio.h> #include <sys/types.h> #include <sys/param.h> #include <sys/socket.h> #include <sys/time.h> #include <netinet/in.h> #include <netdb.h> #include <ctype.h> /* dump bytes, sorta similar to tcpdump's style */ dump(char *p, int len) { int i, j; while (len > 0) { for (i=0; i<16 && i < len; i++) { printf("%2.2x", (unsigned char) p[i]); if (i & 1) printf(" "); } j = i; for (; i<16; i++) { printf(" "); if (i & 1) printf(" "); } printf(" # "); for (i=0; i<j; i++) printf("%c", (isprint(p[i])) ? p[i] : '.'); printf("\n"); len -= j; p += j; } printf("\n"); } /* copy one message; guaranteed not to block */ int fromto(int from, int to) { static char buf[2048]; int len; len = read(from, buf, sizeof(buf)); switch(len) { case 0: return(0); /* EOF */ case -1: perror("read"); exit(1); } dump(buf, len); return(write(to, buf, len)); } /* kludge to deal with select fd_set * parameters weirdness */ /* #define FSC(x) ((fd_set *) x) */ #define FSC(x) ((int *) x) /* repeatedly copy both ways */ proxy(int xfd, int yfd) { fd_set fs; char buffer[2048]; int done = 0; while (!done) { FD_ZERO(&fs); FD_SET(xfd, &fs); FD_SET(yfd, &fs); if (select(64, FSC(&fs), FSC(0), FSC(0), (struct timeval *) 0) == -1) { perror("select"); exit(1); } if (FD_ISSET(xfd, &fs)) if (fromto(xfd, yfd) <= 0) done = 1; if (FD_ISSET(yfd, &fs)) if (fromto(yfd, xfd) <= 0) done = 1; } } int remoteinit(char *addr, int port) { struct sockaddr_in si; int fd; struct hostent *hp; char hostname[MAXHOSTNAMELEN]; memset(&si, 0, sizeof(struct sockaddr_in)); si.sin_family = AF_INET; si.sin_addr.s_addr = inet_addr(addr); si.sin_port = port; if (si.sin_addr.s_addr == -1) hp = gethostbyname(addr); else hp = gethostbyaddr((char *)&si.sin_addr.s_addr, sizeof(struct sockaddr_in), AF_INET); if (hp == NULL) { fprintf(stderr, "unknown host %s\n", addr); exit(1); } si.sin_family = hp->h_addrtype; memcpy(&(si.sin_addr), hp->h_addr, hp->h_length); strncpy(hostname, hp->h_name, MAXHOSTNAMELEN-1); if (si.sin_family == AF_INET) printf("Connecting to %s (%s)\n", hostname, inet_ntoa(*(struct in_addr *)&si.sin_addr.s_addr)); else printf("Connecting to %s\n", hostname); if ((fd = socket(AF_INET, SOCK_STREAM, 0)) < 0) { perror("socket"); exit(1); } if (connect(fd, &si, sizeof(si)) < 0) { perror("connect"); exit(1); } return(fd); } int localinit(int port) { struct sockaddr_in thissock; int s, i; if ((s = socket(AF_INET, SOCK_STREAM, 0)) < 0) { perror("socket"); exit(1); } memset((char *)&thissock, 0, sizeof(struct sockaddr_in)); thissock.sin_family = AF_INET; thissock.sin_port = port; thissock.sin_addr.s_addr = htonl(INADDR_ANY); i = 1; setsockopt(s, SOL_SOCKET, SO_REUSEADDR, (char *)&i, sizeof(int)); if (bind(s, (struct sockaddr *)&thissock, sizeof(struct sockaddr_in)) < 0) { perror("bind"); exit(1); } if (listen(s, 5) < 0) { perror("listen"); exit(1); } return(s); } usage() { fprintf(stderr, "Usage: proxy localport remotehost remoteport\n"); exit(1); } int main(int argc, char **argv) { int partialxfd, xfd, yfd, i, localport, remoteport; struct sockaddr_in thatsock; char *remotehost; if (argc != 4) usage(); localport = atoi(argv[1]); remotehost = argv[2]; remoteport = atoi(argv[3]); if (localport < 1024 || remoteport <= 0) usage(); partialxfd = localinit(localport); for (;;) { i = sizeof(struct sockaddr_in); if ((xfd = accept(partialxfd, (struct sockaddr *)&thatsock, &i)) < 0) { perror("accept"); exit(1); } yfd = remoteinit(remotehost, remoteport); proxy(xfd, yfd); } }

1 0

Re: Certificate proposal
by Bill Stewart 17 Dec '03

17 Dec '03

At 11:53 AM 10/2/95 EDT, Carl Ellison <cme(a)TIS.COM> wrote: >X.509 certificates are not totally bad. Their structure contains lessons >for anyone designing a certificate structure. [Raw X.509 does not imply a >hierarchy, I believe. Steve Kent & Co. do.] I agree with you about hierarchies, and even RFC1422 doesn't really force you to use hierarchy, much less a government-enforced one, though it clearly prefers it, and it definitely does support the concept of having a key signed by more than one CA, at least for CA's keys. The most important differences, from my perspective, are 1) X.509 explicitly addresses Certificate Revocation Lists, though it isn't real precise about how they should be distributed, and the hierarchical approach isn't necessarily the best. (Maybe put the location of the preferred CRL for a key certificate in the cert itself?) 2) X.509 certificates, unlike PGP, only support once signer per certificate; this is a slight hierarchical bias, which forces you to haul around a pile of certificates to have multiply signed keys, without specifying a syntax, so simple key-cert programs may not know what to do with multiples, and hence force hierarchy; the rest of us will just have to deal with multiply syntaxes. But that's mainly a verbosity problem, duplicating Distinguished Names and key info. 3) Neither PGP nor X.509 (as documented in the RFC1422 and PKCS#6) have any mechanism for additional information other than cramming it into the username, but supposedly X.509 Version 3 includes something? >Perhaps the biggest problem is the use of a name -- a text string (or some >abortion like the DN which can be reduced to a text string) -- as the >anchor point. [.... use the public key instead ....] >What remains is a need for attributes to be bound to a key. ... >Current certificates are going down a fundamentally wrong path. They are >trying to bind keys to people and let Society somehow bind attributes to >people -- but the latter binding is too weak to permit keys to be bound to >attributes or permissions. Eventually, there may be a way to represent most of the attributes you want to describe in some format, which I dare say will look _far_ uglier than ASN.1 :-) Binding a key to a text-string usually representing a person does give you the slack to use other mechanisms rather than wait for the release of /standard-name="Attribute Semantics Notation"/version=32769/ORG="International Slowness Organization"/Country=none/reliability=ExtremelyHighTrustUsThisTime/versionh istory= For now, there do seem to be some kinds of attributes that would benefit from better representations than a human-name plus free-form text, such as "which application does the user want you to use this key for?" "how much should I trust the user's desire to have me use that key for that application?" "how do I get this key's owner to give me money?" "does the key-holder have the authority to speak for a given organization/human/bank account?" If you look at Verisign's DNs, or the text in my PGP keys, you'll see various ugly attempts at this. And then there's "WHICH person named Bill Stewart does this key belong to?" For the latter, I'm interested in solutions other than "Social Security Number", "Citizen-Unit Nationalized ID Card Number", etc. #--- # Thanks; Bill # Bill Stewart, Freelance Information Architect, stewarts(a)ix.netcom.com # Phone +1-510-247-0664 Pager/Voicemail 1-408-787-1281 #---

2 1

Re: Netscape finally issuing md5sums/pgp signed binaries ? (was Re: NetScape's dependence upon RSA down for the count!)
by patrick＠Verity.COM 17 Dec '03

17 Dec '03

> > I've been thinking about this recently for obvious reasons. My concern > is that if someone can attack your download of netscape, they could also > attack your download of the program that validates netscape. Is there > really any way out of this one? > > --Jeff I remember sometime in the last couple of years seeing a cert advisory that said that people's checksumming programs were being replaced by ones that did the normal checksumming except on compromised programs. This was part of one particular attack as I remember. Patrick _______________________________________________________________________ / These opinions are mine, and not Verity's (except by coincidence;). \ | (\ | | Patrick J. Horgan Verity Inc. \\ Have | | patrick(a)verity.com 1550 Plymouth Street \\ _ Sword | | Phone : (415)960-7600 Mountain View \\/ Will | | FAX : (415)960-7750 California 94303 _/\\ Travel | \___________________________________________________________\)__________/

1 0

Re: `Hack Microsoft' challenge is NYT Computer News Daily's top story
by MIGUELDIAZ＠megaweb.com 17 Dec '03

17 Dec '03

>Date: Mon, 02 Oct 1995 10:34:32 -0400 >From: Rick Busdiecker <rfb(a)lehman.com> >Sender: owner-cypherpunks(a)toad.com >To: cypherpunks(a)toad.com >bcc: Lehman Brothers Inc. >Subject: `Hack Microsoft' challenge is NYT Computer News > Daily's top story > >See http://nytsyn.com/live/Lead/275_100295_074418_19095.html > > MICROSOFT BECOMES NEW TARGET OF HACKING CHALLENGE (10/2) > > By HEATHER GREEN c.1995 Bloomberg Business News > > BERKELEY, Calif. -- Microsoft Corp. has been chosen as a > new target > for computer hackers. > > Community Connexion, an Internet service provider that > last week > promised a free T-shirt to anyone who found a flaw in > Netscape > Communications Corp.'s software, extended the challenge > Friday to > include holes in Microsoft products. > > . . . > I don't know about everyone else, but a T-shirt seems a very small reward for uncovering a "hole" in the encryption algorithm of Microsoft products. Does that apply to any and all bugs?? i.e. not necessarily security problems??

3 2