December 2003 - cypherpunks-legacy

Re: [NOISE] Re: Easter Eggs
by william＠interval.net 17 Dec '03

17 Dec '03

alano(a)teleport.com <Alan Olsen> ]: > obNetscapeHack: There is a feature called a "cookie file" in > Netscape that is ripe for exploitation as a security leak. If you > are using a Netscape server (and you may not even need that), you > can feed all sorts of information into it without the user's > knowlege. I have heard of one page that overloads the cookie file > until the machine runs out of drive space. I am sure that there > are other exploitable holes there... Any takers? Umm. The spec says that there is a maximum cookie size and a maximum number of cookies that should be sent. I'll be the last to claim that Netscape created a 'standards-compliant' product, but they have at least recognized that these things aren't supposed to be infinitely large. rfb(a)lehman.com <Rick Busdiecker> ]: > Yikes! That sounds really bad. Do you have any more information on > this? For example, can the server write to anything other than > $HOME/.netscape-cookies? If I write protect that file, but it's still > owned by me, will Netscape still modify it? The server can't write anything. Cookies are returned as HTTP response headers, which will either be: A) Ignored by a cookie-ignorant browser, or, B) Processed by a cookie-aware browser. In either case, the cookie cache reading/writing is done by the browser. If the browser is running as 'you' then it can access files that 'you' own. If you write protect it against yourself, then its likely that your user-agent (Netscape) running as 'you' can't write to that file. Cheers! w. archibald =

1 0

Re: Hack Microsoft?
by James A. Donald 17 Dec '03

17 Dec '03

At 10:33 AM 9/26/95 EDT, Dan Bailey wrote: >>For fun ways to hack NT, check out http://www.somar.com/security.html. >> Some of these are really laughable. You can use NT's LogonUser API >>call to repeatedly guess passwords until you hit it, since NT offers >>no way to limit number of login attempts. At 12:10 PM 9/26/95 -0400, RJ Harvey wrote: > I don't believe that's correct; under User Manager, select >the Account option under the Policies menu item; it lets you >select whether to lock-out the account after a given number >of invalid logon attempts, and to set the number. The main >problem here is that by default, I don't believe the 'lock out' >option is enabled Similarly there is an awful lot of other stuff that is left wide open by default, most notably important parts of the registry, in particular \HKEY_LOCAL_MACHINE\SOFTWARE Permissions on this are usually set to give every use write access, so that every user can install software. None of the installation programs reset their registry key to exclude write access by anyone other than the administrator or the person installing the program, as a result any user can muck with the environment of any program installed by any other user. As a result any user can force feed most programs strings which the program would ordinarily assume are internally generated, and can therefore be trusted. A low privilege user can muck with the internals of a program installed by a high privilege user. This of course is a bug in the installation programs, rather than a bug in the operating system, but it is an almost universal bug. (But before you Unix folk gloat, consider how few Unix programs *have* installation programs, also that Unix has no registry security problem because it has no registry.) --------------------------------------------------------------------- | We have the right to defend ourselves | http://www.jim.com/jamesd/ and our property, because of the kind | of animals that we are. True law | James A. Donald derives from this right, not from the | arbitrary power of the state. | jamesd(a)echeque.com

1 0

Re: Timothy C. May: Mini-mailbombs and Warning Letters
by Travis Corcoran 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- Message-Signature-Date: Wed Sep 27 12:28:47 1995 > Date: Tue, 19 Sep 1995 10:57:32 -0700 > To: cypherpunks(a)toad.com > From: tcmay(a)got.net (Timothy C. May) > Subject: Mini-mailbombs and Warning Letters > > I've received a couple of "automatically generated" pieces of > e-amil which tell me that, in the generator's opinion, something is > wrong with my public key, or it could not be found at the keyserver > > As the saying goes, "Sigh." > > Being on a list with 700 subscribers, some of whom are running > increasingly sophisticated automatic checking agents, I foresee an > increase in these "warning letters" from their checking agents who > feel posts are not adequate in some way. As the author of the package in question, I would like to point out: (1) the email msg Tim refers to (hereafter refered to by me as "query-mail") was a request for information, not a warning (2) the query-mail did not refer to any inadequacy in the original posting. It explicitly refers to the fact that the original poster PGP signed a message, but did not make the public key to verify the message easilly available. (3) the query-mail was sent to an actual person only after several non-intrusive methods had failed. (4) checking right now, I find that the finger command does indeed fail to get a public key from Tim's address. (5) checking right now, I find that BAL's keyserver does indeed fail to give any key with the address "tcmay(a)got.net" (6) the query-mail is not a purely robotic spam: there is a human in the loop (7) the keyserver used by query-mail generator defaults, not to some arbitrary preference, but to BAL's keyserver, which is the most used server that I know of, and which (to the best of my knowledge) receives regular updates from several other keyservers. (8) given that "increasingly sophisticated automatic checking agents" can make it much easier for individuals to gather keys, check incoming messages, and sign or encrypt outgoing messages, it seems that such "agents" tend to increase the usage and acceptance of cryptography, which is a good thing for all concerned. A question: in a situation like this one, where an individual signed a message with a key then did not make a key with the return address of his message available either through his .plan, or a keysever (the two de facto standards), what next step -if any- do people think is more appropriate than sending mail to the individual asking them for a copy of the key ? > I'm dealing with it the same way I'm dealing with the few people > who have something in their MIME setup that triggers my mailer > (Eudora Pro 2.1) to treat their text as attachments. Namely, by > filtering them out. This is a fine anarchistic solution to the problem (and that's a compliment!), from your point of view (although, I hasten to point out, not quite as good as submitting a key with a valid address on it to a keyserver). If anyone else wishes to ignore requests for keys, the subject string to add to your email kill-file is "please send me your PGP public key" Because I do think that automating parts of the the encryption/signing/verification/decryption/key-retrieval process will make cryptography more wide-spread (in so far as there is not a backlash against this automation), I do not want to ignore the concerns of others. So...how would people do things differently if they were writing this sort of software? One idea proposed by Jiri Baum <jirib(a)cs.monash.edu.au> is to find the key ID used to sign the message, and then query the keyserver with this ID, as opposed to an email string. I'm not sure whether or not I like this idea (for security reasons), but that question is moot, as it seems to be impossible given the current keyservers. Any other suggestions or ideas? - -- TJIC (Travis J.I. Corcoran) http://www.openmarket.com/personal/tjic/ Member EFF, GOAL, NRA. opinions (TJIC) != opinions (employer (TJIC)) "Buy a rifle, encrypt your data, and wait for the Revolution!" PGP encrypted mail preferred. Ask me about mail-secure.el for emacs. -----BEGIN PGP SIGNATURE----- Version: 2.6 Comment: auto-signed by mail-secure.el v 0.998 using mailcrypt.el Comment: Processed by Mailcrypt 3.3, an Emacs/PGP interface iQCVAwUBMGl7wIJYfGX+MQb5AQErpQP/XvoJ0QF4TEtPhJuxk5ifsUlXrl4RSvyP dFh1MkTQWl4/D+jFHI0MW+gyi2/EmzxEW+8zYUCLENBIq8H3QJgQDnQ9NRM3JiGU c9yd4EeE9bH8r+KppF5WfJfuE4hJ6YFRO0sdal0oJs3RfuF2ZIHoLoKPR5G97EGv dmWg2J784ZM= =xnv7 -----END PGP SIGNATURE-----

1 0

It's Wednesday
by Duncan Frissell 17 Dec '03

17 Dec '03

Do you know where your new Netscape is?

3 3

Re: Another Netscape Bug (and possible security hole)
by donlonm＠ccmail.mcclellan.af.mil 17 Dec '03

17 Dec '03

Ray, You wrote: >I've found a Netscape bug which I suspect is a buffer overflow and >may have the potential for serious damage. If it is an overflow bug, >then it may be possible to infect every computer which accesses a web >page with Netscape. Is there any way to avoid/prevent this problem by changing options in NetScape? Thanks, Mike D.

3 2

Microsoft & new Internet Security specs
by Harry S. Hawk 17 Dec '03

17 Dec '03

http://www.prnewswire.com/cnoc/story/569463/18018 > [Company News on Call] [Return to Company Listing] > [Return to Headlines] > > MICROSOFT PUBLISHES SPECIFICATIONS DESIGNED TO HELP > IMPROVE SECURITY ON THE INTERNET > > ATLANTA, Sept. 27 /PRNewswire/ -- Microsoft Corp. (Nasdaq: MSFT) > today announced the publication of two specifications that address key > Internet security issues. Software designed with these specifications > will enable developers to incorporate improved security technology into > their applications, giving businesses and consumers confidence that > their transactions and communications will be secure. > The two specifications -- Secure Transaction Technology (STT) and > Private Communication Technology (PCT) -- were published today on the > Internet. To help encourage widespread adoption of STT and PCT, > Microsoft is making the specifications available at no charge to all > software developers, businesses, card brands and financial institutions > that want to create STT-compliant and PCT-compliant applications. Both > can be found on the Microsoft home page (http//:www.microsoft.com). > "We set out a year ago to build STT, a security system that meets > the strict requirements of the payment-card industry. STT's design uses > sophisticated cryptographic techniques to help protect and authenticate > consumers, merchants and financial institutions that use bank cards to > conduct business on the Internet," said Craig Mundie, senior vice > president of the consumer systems division at Microsoft. "After doing > so, we felt we could also apply our expertise to the Internet's need for > general-purpose security. PCT builds upon Secure Sockets Layer by > incorporating strong authentication and other technologies we developed > for STT." > STT, jointly developed with Visa International, is supported by the > Internet Shopping Network, RSA Data Security Inc. and Spyglass Inc. The > PCT specification is supported by Cylink Corp., FTP Software Inc., > Internet Shopping Network, NetManage Inc., OpenMarket Inc., Spyglass > Inc. and Starwave Corp. > "We cannot afford to have doubt cast over the ability to conduct > business on the Internet," said Marc Miller, executive vice president of > marketing and business development for Spyglass Inc. "We applaud > Microsoft for approaching the security issue as it should be approached > -- in an open forum within the Internet community. Our whole business > model is based on partnerships. We're happy to be working with > Microsoft to provide an open, specifications-based solution to help > ensure the viability of this exciting new medium." > The Secure Transaction Technology specification, jointly developed > by Microsoft and Visa, is designed to provide a secure method for > handling credit-card transactions across private and public networks. > By providing a technology that can be completely integrated with the > current bank-card system, STT will serve as a reliable payment system > for software providers to incorporate into their products. STT also > preserves the branded transaction relationships that merchants and > financial institutions have with their customers. > The Private Communication Technology specification is designed to > secure general-purpose business and personal communications on the > Internet. PCT includes features such as privacy, authentication and > mutual identification. As a secure communications technology, PCT > builds on the earlier advances embodied in Secure Sockets Layer (SSL). > PCT enhances SSL by separating authentication from encryption. This > means that PCT allows applications to use authentication that is > significantly stronger than the 40-bit key limit for encryption allowed > by the U.S. government for export. > "The Internet Shopping Network is committed to providing the most > secure online shopping environment possible," said Boris Putanec, vice > president of engineering for the Internet Shopping Network. "STT > delivers one of the highest levels of security and authentication for > shopping transactions, boosting electronic commerce." > Microsoft plans to incorporate both STT and PCT into its own > products, such as the Microsoft(R) Internet Explorer 2.0, which ships > with the Window(R) operating system, and is encouraging other software > developers to do the same. > The specifications released by Microsoft include use of encryption > capabilities based on technology from RSA Data Security Inc. > Founded in 1975, Microsoft is the worldwide leader in software for > personal computers. The company offers a wide range of products and > services for business and personal use, each designed with the mission > of making it easier and more enjoyable for people to take advantage of > the full power of personal computing every day. > Microsoft is either a registered trademark or trademark in the > United States and/or other countries.

1 0

Re: Timothy C. May: Mini-mailbombs and Warning Letters
by tcmay＠got.net 17 Dec '03

17 Dec '03

At 4:28 PM 9/27/95, Travis Corcoran wrote: >As the author of the package in question, I would like to point out: > >(1) the email msg Tim refers to (hereafter refered to by me as "query-mail") > was a request for information, not a warning I've received several of these, not just the one Travis sent. I don't sign my messages, never have, so I see no way this "agent" Travis ran could find such a signed message from me.m (It's conceivable he found an old--really old--message with a faked-up sig, as perhaps for a demonstration or spoof I was doing, but I'm skeptical. In any case, I suspect only an "automated searcher" could find the one or two messages that may look like this. If Travis produces the message here, I'm sure this will be what the situation is.) >(4) checking right now, I find that the finger command does indeed > fail to get a public key from Tim's address. > >(5) checking right now, I find that BAL's keyserver does indeed fail > to give any key with the address "tcmay(a)got.net" Like I said, I don't sign messages. My PGP 2.0 key was signed at the second CP meeting and, they tell me, submitted on the original MIT ring. "tcmay(a)netcom.com" was my e-mail address at that time. >A question: in a situation like this one, where an individual signed a >message with a key then did not make a key with the return address of >his message available either through his .plan, or a keysever (the two >de facto standards), what next step -if any- do people think is more >appropriate than sending mail to the individual asking them for a copy >of the key ? Ignore it. Why hassle people who have no plan or finger configurations? (I don't have a shell account.) Besides, people who really want to communicate with me with PGP simply ask for it. If you don't like this, fine. But don't robo-interrogate and send robo-warnings. --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."

2 1

Re: macworld crypto articles
by Steve Bryan 17 Dec '03

17 Dec '03

>> In article <4444rl$nrh(a)life.ai.mit.edu> Chen writes: >> > It's truly a deplorable state of affairs. >> >> For the next version, include PGP free with every version of Quicken, >> and have Quicken just "call" PGP. >> >> Of course, users can encrypt their files now with PGP. Is there an >> Intuit bboard where someone could post instructions? > >This is a good idea. I'll bring it up with the appropriate people. > >Right now, we only have some cheesy forums going on Compuserve and >Prodigy; however, keep your eyes peeled. We have other stuff in the >works. PGP is probably too unweildy for the non-hobbyist to comfortably use. I don't know if anyone else has suggested it but I'd strongly encourage Intuit to make CryptDisk for the Mac easily available. I use it to maintain an encrypted partition for my financial data and the user interface is quite simple. I believe the DOS equivalent is SecureDisk. +---------------------------------------------------------------------- |Steve Bryan Internet: sbryan(a)gofast.net |Sexton Software CompuServe: 76545,527 |Minneapolis, MN Fax: (612) 929-1799 |PGP key fingerprint: B4 C6 E2 A6 5F 87 57 7D E1 8C A6 9B A9 BE 96 CB +----------------------------------------------------------------------

2 1

(fwd) CYLINK Q&A on PKP Arbitration Decision
by Childers James 17 Dec '03

17 Dec '03

Newsgroups: sci.crypt,talk.politics.crypto,alt.security.pgp Path: news.unt.edu!cs.utexas.edu!howland.reston.ans.net!ix.netcom.com!netcom.com!jkennedy From: jkennedy(a)netcom.com (John Kennedy) Subject: CYLINK Q&A on PKP Arbitration Decision Message-ID: <jkennedyDFK1tA.57D(a)netcom.com> Keywords: Cylink, PKP, RSA, Public Key Organization: CYLINK Date: Wed, 27 Sep 1995 08:19:58 GMT Lines: 277 Sender: jkennedy(a)netcom23.netcom.com Xref: news.unt.edu sci.crypt:39749 talk.politics.crypto:12787 alt.security.pgp:43387 ----------------------------------------------------------------- CYLINK Q&A on PKP ARBITRATION The following statement from Cylink Corporation has been posted to sci.crypt, talk.politics.crypto, and alt.security.pgp since we believe it will be of interest to a large and diverse set of readers. Please choose the appropriate newsgroup(s) to direct any follow- ups. A copy of this statement is also being placed on Cylink web page (http://www.cylink.com) Additional related materials and updates will also appear there. Feel free to distribute this statement to other appropriate newsgroups, mailing lists, and individuals. -John C. Kennedy, Cylink Corporation {ph: 408.735.5885 , jkennedy(a)cylink.com} ---------------------- Cylink Corporation ------------------------- September 26, 1995 IMPACT OF CYLINK VS. RSA ARBITRATION AWARD FREQUENTLY ASKED QUESTIONS Q. Why is the recent arbitration award between Cylink and RSA Data Security significant for RSA's licensees and vendors of public key cryptography in general? A. The arbitration award is important to RSA's licensees for two reasons: First, the award makes it very clear that RSA does not have the right to authorize its customers to copy RSA's software; it doesn't matter whether the RSA customer is merely copying object code versions of RSA's products. The right to copy RSA software requires a patent license. Second, until now RSA has claimed itself to be the de facto standard in public key cryptography. This claim was possible only so long as RSA could prevent its competitors from getting patent licenses from Public Key Partners. Now that the arbitrators have dissolved PKP, Cylink can enable vendors to practice low cost public key technology without the use of RSA. The market will finally enjoy vigorous competition based on technology and price. Q. In a recent statement, RSA's president still makes the claim that the use of RSA software does not require a separate patent license. Is that true? A. That statement is not true for any RSA licensee who needs the right to copy RSA software. The heart of RSA's business is licensing so-called tool kits; the vendor takes one copy, incorporates it into the vendor's own product and then makes all of its own copies. The only RSA customers who don't need a patent license are those who don't copy RSA software. Q. That could be pretty serious for RSA and its customers. Can you back up this statement? A. Absolutely. Read the arbitrators' award at p. 14. If you haven't received a copy from RSA you can find it on Cylink's home page (http://www.cylink.com) Don't take our word for it. When RSA's own attorneys pleaded with the arbitrators to change their decision, they admitted that "... every single RSA licensee will now be required to obtain a Stanford Patent License from Cylink or run the risk of being sued" (ask RSA for a copy its attorneys' letter dated September 7). In a second decision dated September 12, the arbitrators flatly rejected RSA's pleas and confirmed their restrictions on the rights of RSA's customers. (a copy is also available from Cylink's home page). Q. RSA's president promises to indemnify all of its customers. Why should they be concerned? A. If you compare RSA's size against the size and number of its customers copying RSA's software, one should ask whether RSA's pockets are deep enough to reimburse its customers for the damage RSA has caused. Q. Did RSA know it did not have all of the rights it promised its customers in RSA's software licenses? A. Shortly after RSA gave up its patent rights to PKP, Cylink began warning RSA that its did not have all of the rights it was promising some of its customers. Unfortunately, Cylink had to finally bring the arbitration to straighten this out. Q. Why do RSA's customers need a license to the Stanford patents simply to copy RSA's software? A. Two reasons. The Stanford Hellman-Merkle patent is the very first patent to describe Dr. Hellman's brilliant invention of public key cryptography. All subsequent refinements on this pioneer patent which implement Dr. Hellman's concept, such as the RSA algorithm, require a license to Dr. Hellman's patent. Secondly, the Diffie-Hellman key exchange technique is a standard feature in many of RSA's tool kits, which is also covered by Stanford's Diffie-Hellman patent. Finally, if RSA were correct in its statements that you don't need a Stanford license to use RSA's software, why would they embark on yet another expensive lawsuit to attack the patents? Q. Isn't the Hellman-Merkle patent limited to practicing something called the knapsack? A. No. As the pioneer patent in public key, the inventors were required to disclose only one implementation to support their ground breaking invention. Even if no one is using the knapsack itself, this particular patent continues to cover all practice of public key. Only improvements, such as the RSA algorithm described in MIT's patent, are limited to the specific enablement described in the patent. Again, don't just take our word for it. RSA itself admits that RSA software is covered by these patents. Just look at their license for RSAREF, Paragraph 6 (before they have time to change it). Q. But RSA has now brought suit to invalidate the Stanford Patents. Doesn't this protect RSA's customers? A. RSA's attempt to invalidate the very patents it had been licensing as a partner in PKP does nothing for RSA's customers. First of all, the fact that someone else is challenging the validity of a patent doesn't make an infringer immune from suit. RSA's challenge to the Stanford patent would not prevent Cylink from suing and obtaining damages and an injunction against any infringer. (Indemnity for damages, by the way, is cold comfort if an RSA customer is enjoined from selling any public key software.) Second, anyone who waits around for RSA's case to be resolved is taking a big gamble. Patents are presumed valid and RSA will have to prove invalidity under the "clear and convincing" burden of proof (which is higher than the traditional "preponderance of the evidence" standard and just below the criminal "reasonable doubt" standard). If RSA looses the suit, all of its customers will be left hanging. An RSA indemnity won't be worth much if RSA goes into bankruptcy. Q. RSA claims that Cylink "confirmed" to RSA licensees "in writing" "that no separate patent licenses were necessary if they licensed RSA software." Is this true? A. No. During the arbitration, however, one prospective RSA licensee approached Cylink and said that RSA kept assuring them that they didn't need a patent license to make their own copies of RSA public key software, but they had gotten suspicious when their own lawyers looked at the question closely. Cylink told the prospect that a patent license was needed for some of their projects, but in this instance Cylink would not interfere with the pending RSA deal. RSA customers who take the initiative and contact Cylink (as in this special case) can expect cooperation in resolving the patent problem. Q. Why was PKP formed? A. Cylink formed PKP with RSA to pool both parties' rights to the Stanford and MIT patents, promote public key technology, and generate licensing revenue for the partners, the universities which owned the patents, and the inventors. Q. Why was PKP dissolved? A. Obviously great animosity has grown between the parties. The main reason is that RSA frustrated Cylink's efforts to settle the U.S. Government's efforts to license the Digital Signature Standard. Now that Cylink has the Stanford patents back, the DSS as well as other public key techniques can begin competing with RSA in the market. Q. How will these public key implementations compete with RSA? Isn't RSA a "de facto" standard? A. If anything, RSA software (which includes Stanford algorithms such as Diffie-Hellman) has been prevalent by "default" - not by choice. Now the market will have a choice between multiple vendors competing on price as well as technical implementation. Only after RSA's software faces the test of competition can it fairly claim to be a standard. Q. In his recent statement, RSA's president makes numerous accusations about Cylink's use of the RSA algorithm. What are the facts? A. The arbitrators award is very clear that Cylink in fact has certain rights to license the MIT patent. Specifically, Cylink has an option to license the MIT patent provided it uses some software provided by RSA. This places Cylink in a better position than RSA's other customers who have no rights to the Stanford patents. It is important to remember that Cylink built its business for the last ten years on the use of Stanford public key technology - which proves our point that you don't need RSA or its software to practice public key. Q. Doesn't Cylink use the RSA algorithm in one of its products. A. Yes, and only one. What RSA fails to mention is that Cylink's largest customer, SWIFT, already holds its own PKP license which the arbitrators forced RSA to grant. This license allows Cylink to make the product for SWIFT. Q. RSA claims that Cylink was offered a license to the RSA Patent, and that Cylink turned it down. Is that true? A. Like a lot of what RSA says, it's a half-truth. In June, 1994, RSA did offer a patent license, and Cylink did turn it down. Why? Because a condition of the license was that Cylink release RSA for all liability for its licensing practices. In other words, the price for the license was more than just the royalty. Cylink was being asked to forgive RSA for the wrongs it committed over the years, and this Cylink would not do. Q. Why did Cylink decide to use RSA is this one product? A. During PKP's existence, RSA frequently sought Cylink's support for its technology by asking Cylink to use RSA. While RSA now tells a different story, RSA's own newsletter (see, for example RSA's "Ciphertext" Fall 1993 issue) and corporate profile frequently promoted Cylink's use of RSA long before the parties fell into their dispute over licensing DSS. Having cooperated with RSA, and agreed to use their technology in one product, RSA tried to blackmail Cylink to stop PKP's settlement with the Government. In any event, the restrictions imposed by the arbitrators on RSA's licensing business are far more severe than the minor inconvenience Cylink may experience in retro-fitting its product with Stanford technology. Q. What will Cylink do with the Stanford patents now? A. Before the arbitrators' decision many of RSA's customers had no reason to doubt RSA's word. Those RSA customers who now come forward will be offered very favorable agreements. Cylink is more interested in establishing commercial relationships with RSA's licensees and promoting public key technology than in disrupting existing business. Q. Will Cylink attempt to stop the non-commercial use of public key (such as in PGP)? A. No. Although, technically, a Stanford patent license is needed for the public domain software such as PGP, Cylink intends to promote the use of public key on the Internet. Cylink intends to announce a royalty-free license for personal use after meeting with a spokesperson for the PGP community. Watch Cylink's home page for details. (http://www.cylink.com) Q. What advice can you give? A. Get the facts first. Read the arbitrators decision, including their September 12 ruling which denied RSA's request for modification. Then call us. (Call Bob Fougner at 408-735-5893, fax 408-735-6642, e-mail: fougner(a)cylink.com) ---------------------- Cylink Corporation ------------------------- John Kennedy Cylink Corporation 408-735-5885 jkennedy(a)cylink.com -- "Freedom is meaningless unless | ic58(a)jove.acs.unt.edu - James Childers you can give to those with whom| No man's freedom is safe you disagree." - Jefferson | while Congress is in session EA 73 53 12 4E 08 27 6C 21 64 28 51 92 0E 7C F7

1 0

Re: Fax encryption software
by shamrock＠netcom.com 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- In article <Pine.3.89.9509262116.A7081-0100000@netcom7>, grafolog(a)netcom.com (Jonathan Blake) wrote: > I saw this article in alt.privacy. > > Anybody think the described encryption actually is worth > looking at. [...] >We are talking about a 72 bit engine that is more than >sufficiently strong for time sensitive general business purposes. [...] >>>It is fully licensed, without restriction for export, by the >U.S. >>>Department of Commerce. NO PGP WORRIES. These two statements are mutually exclusive. Snakeoil. - -- - -- Lucky Green <mailto:shamrock@netcom.com> PGP encrypted mail preferred. - --- [This message has been signed by an auto-signing service. A valid signature means only that it has been received at the address corresponding to the signature and forwarded.] -----BEGIN PGP SIGNATURE----- Version: 2.6.2 Comment: Gratis auto-signing service iQBFAwUBMGmmZyoZzwIn1bdtAQFrsQF/edmKXMashWa+yP9E4N/M0c/Rgwa4I6rm 0g0K8TzPc8hl4dP01Euiqcm1LAgHqbiL =rRO8 -----END PGP SIGNATURE-----

1 0