December 2003 - cypherpunks-legacy

Re: Ray Cromwell: Another Netscape Bug (and possible security (fwd)
by sameer 17 Dec '03

17 Dec '03

Forwarded message:

2 1

Re: awards for hacking microsoft
by Andrew Loewenstern 17 Dec '03

17 Dec '03

> What else, Chaum's Digicash. If you are unwilling to part with > any of your own, perhaps you can collect contributions, or maybe > the Digicash people will pony-up some extra cyberbucks for a good > cause. After all, they are worth the paper they're printed on. > :-) Don't tell that to the people on the ECM mailing list! People there have been trading cyberbucks for RealMoney. The last successful trade I saw was 100 cyberbucks for 4 UK pounds... andrew

2 1

53 of the FAX No's. are GOOD!
by carolann＠censored.org 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- 53 of the Fax numbers were good. About 15 were no good, and the rest turned in no answers. I will update this URL tomorrow, when I can completely check the list; http://www.c2.org/~carolann/enda001.html is where the list is at on the WWW. Love Always, Carol Anne -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMGt9S4rpjEWs1wBlAQE5iQP/e74RL+Rmui47LgWT9hk4LNlfISGkHYS2 fdVsut/mbLF/FrRIeETecaSJOOxOBXBr84OYzRLicka+Lm01ciW32pbXYvILftLS vNs7ppWoIs+C343cd3TOZx0p2Q8QuSZSUSGSYCEk1dwZTl/rd1iHTU3DW2ALZ66P xOTLPUV8p1Y= =dJpK -----END PGP SIGNATURE----- -- Member Internet Society - Certified BETSI Programmer - Webmistress *********************************************************************** Carol Anne Braddock (cab8) carolann(a)censored.org 206.42.112.96 My Homepage The Cyberdoc *********************************************************************** ------------------ PGP.ZIP Part [017/713] ------------------- M8H,),S$8G>&.WP(8IRA`-M['+`Q%&_C"">5-F%LX@<_Q$;*P'',Q$Z/AA[8M MF=O0H+*%(-S%&>S%+FS&<LS%3(Q&#W1"<]2%`H^;,]^1C$'HBN8PX$4SYAU^ MPGD<Q0ZLA0D+,`MCT!LA**4M[-JPAK9F?40!AJ,CW"'%DR#:'9?Q)3[%<DQ` ------------------------------------------------------------- for next chunk to export --> http://dcs.ex.ac.uk/~aba/export/

1 0

No Subject
by nobody＠REPLAY.COM 17 Dec '03

17 Dec '03

Subject: Re: 25 Crays a Year to Break STT > Although no encryption system was totally secure, Mr Dent > estimated it would take "25 Cray supercomputers a year" to > break the STT codes. Is it just me, or does someone need to be humbled? STTbruter anyone?

3 2

Q&A on the RSA/Cylink legal dispute
by baldwin 17 Dec '03

17 Dec '03

Here is RSA's Question & Answer sheet on the arbitration. It is available on our web site, www.rsa.com. --Bob ______________________________ Forward Header __________________________________ [RSALogo] --------------------------------------------------------------- Q&A ON THE RSA/CYLINK LEGAL DISPUTE This page contains general questions that have been brought up to us regarding the legal dispute between RSA and Cylink. We are providing these answers in hopes that you may better understand the issues. ---------------------------------------------------------------------------- September 25, 1995 Q. How did RSA's legal disputes with Cylink begin? A. It began in April of 1994 when Cylink filed an Arbitration Demand seeking to have a panel rule that Cylink was entitled to a retroactive patent license to RSA, also called the MIT patent. That was the extent of their Arbitration Demand at that time. The dispute was precipitated by RSA's discovery that Cylink had entered into a secret deal to provide products incorporating the patented MIT technology - even though Cylink knew it did not have a license. ------------------ Q. Why didn't PKP/RSA just sell them one? Isn't that their business? A. We offered them one several times. They wanted to pay essentially nothing for it. Although Cylink denied it, the fact that we offered them a license was confirmed by the Arbitrators in their ruling. ------------------ Q. Patents are routinely licensed and royalties routinely paid; why did Cylink go to the extraordinary length of suing RSA Data Security to obtain a license? A. We learned that in April of 1994 Cylink had won, over other bidders, a very substantial business deal with SWIFT (an international banking consortium) to provide X.25 encryption units for use by SWIFT on a worldwide basis. SWIFT had insisted that these products use the RSA patented technology for key management and authentication. Cylink had represented to SWIFT in their April 1994 contract that Cylink had a license to provide RSA technology. But they didn't. Cylink chose to sue us to win a retroactive license rather than simply admit what they had done and pay for a license. Cylink never informed us of their use of RSA or the representation to SWIFT. They never paid a penny to PKP or RSA for their unlicensed use of the RSA technology. They never even put any royalties aside. None of these facts are in dispute and are all a matter of public record. ------------------ Q. How did the litigation go beyond a limited Arbitration over a license? A. We didn't understand it at the time, but it's obvious now. While more claims and counterclaims were added to the Arbitration demand, Cylink knew of their SWIFT problem and other similar problems; we didn't. We believe that they were desperately trying to cover their unlicensed use of RSA by trying to litigate us into submission before it was discovered. It didn't work. ------------------ Q. What were the additional claims by each side? A. Charges were made by each RSA and Cylink that the other had breached the exclusive licensing authority of PKP among other wrongful acts. This brought a second set of issues for the Arbitrators. Finally, both parties asked to have PKP dissolved as we obviously could not continue as business partners; this was the third issue to be decided. It's quite clear in the Arbitration Panel's ruling that there were only three issues to be decided: (a) is Cylink entitled to a retroactive license to use RSA; (b) did either party breach the Partnership Agreement; and (c) should PKP be dissolved. The answers were no, no, and yes. ------------------ Q. If that's true, then how does Cylink claim that the Panel's ruling determined that RSA software customers are infringing the Stanford patents? A. The Arbitration Panel did not determine that the use of RSA software by RSA licensees or that the practice of RSA infringes the Stanford patents. It is most certainly true that the ruling was very limited; the Ruling itself starts out by stating the questions. The Panel did not, under any interpretation, rule on patent validity or determine that anyone was infringing. Cylink's claims to the contrary, along with their claims that somehow Cylink can rely on the Ruling to prove infringement is simply not true and ignores many other facts. ------------------ Q. What other facts? A. The Panel's ruling was very specific. Everything it said about third parties, including RSA customers who use software, refers to their need for patent licenses. If you bought software from RSA and RSA itself had the rights to make that software and license it to you, you don't need a separate patent license; rights to the patents came with the product. The Ruling also states, "RSA has a right to license its software." ------------------ Q. Under what circumstances would you need a separate patent license? A. If you want to make your own product -as opposed to buying one, such as RSA's software- you need a patent license. If you bought a software product but didn't use it, meaning you wrote your own, or re-wrote it, then you may need a separate patent license to do that. We believe the Panel was simply making it clear that just because you bought software from RSA, that fact alone doesn't mean you are free from the need for a separate patent license if you're not using the RSA software and making your own. You didn't get an explicit patent license with the software, you got rights under the patents as necessary to use the software. If you're using RSA's software -you didn't write your own- you don't need a separate patent license under either the MIT or Stanford patents. ------------------ Q. Are there other relevant facts that Cylink has ignored? A. Perhaps the most important fact that Cylink is carefully ignoring is that Cylink knows RSA did indeed have rights to make products under the MIT and Stanford patents. Cylink, for over five years, knowing full well what RSA sold and how, has not only referred customers to us, but in some cases where the customer was being cautious, Cylink confirmed to them in writing at their request that no separate patent licenses were necessary if they licensed RSA software. In other words, prospects of RSA's went to Cylink and said, "We're going to license this software from RSA. Do we need separate patent licenses from Cylink or PKP?" Cylink confirmed the answer - no. (And those companies then did in fact license our software. Cylink didn't turn around and sue them.) This alone should deter Cylink from bringing infringement suits against RSA customers. Nothing in the Panel's ruling changes any part of these facts. In fact, Cylink acknowledgment that RSA had such rights came out in the Arbitration proceeding itself. It's a matter of record. Cylink would also not like anyone to be aware that a suit was filed in Federal Court in 1994 to invalidate the Stanford patents, and that a ruling is due in December. ------------------ Q. How is RSA protecting its customers from action by Cylink? A. We have filed a Declaratory Relief Action in Federal Court. In that action, we have essentially said that Cylink is estopped -prevented- from taking action against anyone for infringing the Stanford patents for several reasons. The main reason is that companies who licensed software from RSA Data Security rather than "build their own" software do not need separate licenses to the MIT or Stanford patents. Since Cylink has confirmed this many times since 1990, they should not sue anyone for infringement. Another reason is that the Stanford patents are unenforceable and/or invalid. This action by RSA means that any suit brought by Cylink against anyone for infringement of the Stanford patents should be stopped until the resolution of the Declaratory Relief action, and Cylink will have to prevail on all the points above before they can assert any infringement. We have also indemnified our customers against claims such as those implicitly threatened by Cylink. RSA intends to stand behind these indemnity agreements fully. Anyone can bring a lawsuit for just about any reason. If Cylink tries to sue an RSA customer, RSA has both the determination and the resources to defend any such action. Read the Cylink press release carefully. Cylink huffs and puffs a lot, but is not directly threatening to sue anyone -that would mean they would be forced to fight the virtually impossible battle of prevailing on every point in our Declaratory Relief action- but instead are saying that buying a license can eliminate any risk. ------------------ Q. Has anyone else challenged the Stanford patents? A. A suit was filed in Federal Court last year by Roger Schlafly to invalidate the Stanford patents. A ruling is due in December. From what we've seen, Schlafly's claims raise disturbing questions about the Stanford patents. This whole business of the Stanford patents may be moot in a few months. There may be no risk - and no need to try to get any money back from Cylink. ------------------ Q. What will be the significance of PKP being dissolved? A. The most important change we see is that licenses to the MIT patent will be available for the first time in over five years without Cylink interference. * There is a tremendous amount of pent-up demand, and we are very busy filling it. Many of the largest companies in Europe, Asia, and the US are purchasing licenses to bring RSA-based products to market, including many low-cost chips and smart cards. We have already licensed a number of large and small companies that are bringing RSA-based electronic commerce, access control, and Internet security systems to market; we expect many, many more. ------------------ Q. Why can't RSA and Cylink simply settle their differences? A. That's a good question. The fact is that RSA recognizes this litigation is not beneficial to anyone and has offered to settle the dispute by granting Cylink a license to the MIT patent. Cylink has consistently overestimated the strength of its legal position and has refused all reasonable offers. Cylink now finds itself in the unenviable position of trying to sell its security products without RSA technology - which is the de facto industry standard. No amount of "spin doctoring" in press releases by Cylink changes that fact. ------------------ * During its existence from April of 1990 until September of this year, PKP could not grant any license without the approval of both partners. As a result of PKP's dissolution, the rights to the Stanford patents were returned to Cylink, and the exclusive right to license the MIT patent (RSA) was returned to RSA Data Security, Inc. Cylink currently has no rights to sell any products incorporating the MIT patented technology. ---------------------------------------------------------------------------- (C) 1995 RSA Data Security, Inc. All rights reserved. Permission granted for unlimited reproduction and distribution unmodified.

3 2

worldwide announce: New OTP Mail/FTP apps
by Doug Hughes 17 Dec '03

17 Dec '03

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. In the words of Winn Schwartau: "This really fucks with your brain" Both he and David Kahn have gotten information out of non-disclosure, as well as several other un-named experts in cryptography about the nature of this new development. They were astounded and have provided assurances as to its authenticity and ability to work as advertised. So far they have no released the complete protocol, but plan to do so as soon as the Patent issues pending in several countries have been resolved. The protocol will be completely published and subject to scrutiny by everybody. To me it looks like it would be trivial for them to integrate it into any and all kinds of browsers, clients and applications. Of course, I do not have a complete knowledge of the entire protocol, but the brief overview was simple enough to understand in concept. If it can work in FTP, it can surely work in telnet as well, it's just a different front end over a TCP/IP connection. I realize that there will be those out there on this list who will immediately dismiss this as a hoax, as would have I had I not seen it operate with my own eyes, and sat through the conference. It was a case of serendipity for me, showing up at the booth and getting an invite to the press conference on the one day I decided to attend Networld/Interop. It works something like this: (I may not have it completely right, but this is what I understood of the broken English of the man without the microphone) A third party generates random numbers, or one of the two communicating parties. The numbers do not have to be secret. There is also a published table of mappings.. Something like, a number, and an operation.. 1 -> add 23 2 -> add 21 3 -> add 40 4 -> add 57 90 -> sub 23 One initial connection is all that is needed to have a secure connection for the lifetime of the two communicating parties. This initial connection can be accomplished via any number of ways. It does involve an initial one time only shared secret. This is much different than the many shared secrets and key management issues of private and public key systems. For the initial connection you can stick the machines back to back if you are really worried about security. This initial transaction serves as a seed for subsequent transactions. All subsequent transactions depend on preceding transactions. A degree of randomness comes from the randomness of the messages. Each next word in the message is random. (the argument goes like this: If you already know what the next word in the message is, there is no point in sending the message in the first place, because you know what all the words in the message are.) This imparts some degree of randomness, as no two beings will have an entire conversation over their lives the same as their conversation with anybody else: similar arguments can be applied to file transfers. After the initial exchange every message sent subsequently gets randomized from the previous randomness of the messages plus something in the table. If somebody else makes an exact copy of your machine, and sends a message as you, then you can no longer send messages to the other party as you are out of sync, and an Intruder alert is flagged if you do try to send a message. Then you and the foreign party can resynchronize. This new state is the basis for new messages. Argument: "That's fine, but how to I communicate securely with someone over the Internet with email that I'm not able to setup a secure channel with." Apparently each distribution disk is encoded with a unique ID and some kind of unique (and as yet undisclosed table and algorithm). This table allows the two parties to somehow setup a secure session and send mail. This does not solve authentication problems. If somebody steals your disk and sends mail to someone, they can appear to be you (or anybody). However, the minute you try to send mail to that same person, there is state on the remote machine with the imposter that you do not possess that flags an intruder problem, and new negotiations can begin. However, snoopers of the original message will still be unable to decode the one time pad. Winn Schwartau and Dr. David Karn have both signed non-disclosure and both made announcements to the affect that it does work as advertised. Also, it is not strictly random numbers in the traditional sense. It relies on the fact that the message is composed of a random series of words to create the one time pad. However, the one time pad does not repeat itself due to the continuing diversity of subsequent messages. They have reviewed the math and the algorithms and stated that it's a completely new way to think about cryptography, and the math is valid. Usability: point and click.. Click on the little lock button and the message is encrypted on the fly. The mail browser decrypts the message on the fly. After it is decrypted it is stored on the hard drive in plain text. (As it would have to be, unless you encrypt it with some conventional secret-key algorithm like DES or IDEA). This is fine as they say you have to have some degree of physical security anyway, and this is only to protect you on the networks in between the two machines. I'm inclined to agree. Notes: It's fast!! I'm just telling you what I heard. I have no idea how or what is stored as state information if anything. (part of the currently undisclosed algorithm). I was very skeptical at first, but have affected cautious optimism at this point. (until it is published). I just have a couple things to add. If it's true and works as advertised, we're in for a real treat, and the NSA and FBI are going to be really upset. :) Those drug smugglers and kiddie porn pushers are going to be immune to network wire taps. Next step: illegal algorithms, illegal XOR. ;)

3 4

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

Netscape and privacy
by csmyth＠blaze.cs.jhu.edu 17 Dec '03

17 Dec '03

The Communications Week issue of September 25 1995 contains an interesting interview with Netscape Chairman Jim Clark in which he outlines the future that he envisions for his company. The interview also contains a passage discussing the Netscape browser software that I find somewhat disturbing. Many cypherpunk list members are concerned with the general issue of electronic privacy and with the programming of WWW browsers, so I think this post is relevant to the list. Clark's apparent attitude toward privacy makes me uneasy. Begin excerpt Comm Week: How do you track usage? Clark: We have worked out schemes to tell us when you use our program and for how long you use it. That capability is easy to add. We can tell each and every time you turn it on and we can tell whether you have paid for it or not. We were getting 10 million hits a day at our Web site. It has doubled since our IPO. End excerpt I personally oppose the collection of this type of behavioral tracking information without my explicit consent, and I would reconsider using software which implements the type of tracking Clark mentions above. Note, Clark's reply is ambiguous because it does not indicate if the `schemes' have been implemented or deployed at this time. Some list member associated with Netscape may wish to clarify Clark's comments. It is true that a user automatically contacts the Netscape Web cite when starting the browser if he or she has not reset the default home page. I reset my home page long ago, but I do not know if the Netscape site is still contacted anyway. Nor do I know if Netscape is contacted when I quit the browser, or if elapsed usage time is tracked. The future Clark posits for his corporation depends on people adopting Netscape software for a wide variety of tasks. He wants the browser to evolve toward being a general multimedia web browser, mail handler, newsreader, and collaboration tool. Such a tool would handle large amounts of private and/or proprietary information and the creator of such a tool must be extremely sensitive to privacy concerns in my opinion. Collecting and relaying information about usage is potentially a significant violation of the privacy users will expect. Certainly, it is tempting to gather information for marketing purposes and other reasons. For example, some browser company unconcerned about privacy might program its browser to regularly transmit information about bookmarks and histories to a database site for analysis and data-mining. But ignoring privacy concerns risks invoking the fervent ill-will of many users. Perhaps I am over-reacting to Clark's comments. Even if I am over-reacting, Netscape should consider developing a statement of its privacy policy and making it available at its web site. It is not easy to craft clear, concise and general privacy guidelines. Below are two crudely crafted suggestions for properties that should be satisfied by a browser. 1) Information about browser usage will never be collected and/or transmitted surreptitiously to any other agent on the net. 2) Transfer of information should be done openly with the explicit initiation/agreement of the browser user. Note, currently the Netscape browser (and other browsers) apparently transmit identification information such as the browser type, version number, and machine name when making a connection. The browser user should probably be told about this information in my opinion. Chris Smyth csmyth(a)blaze.cs.jhu.edu

5 4

MD4 collision
by norm＠netcom.com 17 Dec '03

17 Dec '03

Hans Dobbertin in Germany has found two messages to which MD4 assigns the same hash.

1 0

ARTICLES
by Tim Philp 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- Copyright (C) 1995 Tim Philp Brantford, Ontario Canada Article appeared in The Expositor, Brantford, Ont., Canada June 10th, 1995 - COMPUTER CRYPTOGRAPHY - - PROTECTING YOUR PRIVACY - by Tim Philp Last week I discussed ways that the computer has made our lives less private. Today we take up that thread and talk about the stuff of spy novels.Cryptography, in the context that we are discussing it, is a means of preventing unauthorized people from reading our files or correspondence. Cryptography is not new. It has been used throughout history and has played its part in shaping events. Mary Queen of Scots was beheaded because the cipher that she used to arrange a rebellion against Elizabeth I was decoded by the government. Julius Caesar used a primitive cipher, now known as a Caesar Cipher, to disguise his messages to Rome during his military campaigns. Every letter in his messages was replaced by the letter three letters farther in the alphabet. Thus A would become D, B would become E, until you reached the end of the alphabet. You would then wrap around to make X equal to A, Y equal to B and Z equal to C. In this way the word CAESAR would become FDHVDU. Simple substitution ciphers like this one are easily broken and today are used in puzzle books to provide a few moments diversion to puzzle fanciers. The role of computers in cryptography goes back to the early days of computers. One of the first computers was used to help decode enemy messages in England during the second world war. The 'boffins of Bletchley' were the true progenitors of the computer, not IBM. Cryptography has progressed far beyond the simple Caesar Cipher. Indeed, today's methods of encoding messages have progressed to the point where the ciphers are unbreakable within any reasonable amount of effort. It does no good to break a cipher if it takes 1500 years of computer time to do it! Of interest to computer users is the development of a type of cryptography called Public Key Cryptography. With this method you have two keys, a public key and a private key. Simply speaking, a key is a very long number that is used by your program to encode and decode messages. Each person that you want to communicate with has a public key that is published and is known by everyone. To send a message to your friend you would use his public key to encode the message. Your friend receives the message and uses his private key to decode the message. The beauty of this technique, is an eavesdropper can intercept the encoded message and the public key of the recipient, but he cannot use this information to decode the message without the secret key of the recipient. In older systems you had to transmit the secret key to the recipient. The secret key could be intercepted and used to decode the messages. Public key systems require that only the public key be transmitted to the recipient. The message cannot be decoded using only the public key and the message. The availability to the general public of secure, military grade cryptographic methods has generated considerable controversy. The US government has placed this software under export control and has suggested the use of their own system called Clipper. Clipper has a 'backdoor' that will allow the government to decode secret messages. They claim that they need this power to combat drugs and crime. Civil libertarians claim that the government has no business intercepting private communications. Cryptography can be used to protect E-Mail messages and computer files. The software to do this is freely available on the Internet (search for PGP). The US government, it seems, is locking the barn door after the horses have escaped. This file may not be reproduced by any means without the permission of the author -----BEGIN PGP SIGNATURE----- Version: 2.6 iQCVAwUBMHM8unseeMISF+fVAQFesQP/YxFgW3BAjnvDCMU4SfksgpKLEGMDMv9M YQpn/0BqUZSUnO3yye1bIN5KsDofePaCd6PcE6RcnvZJTBVu9PiZvxiBkr/a76wf 5Ft+F4p2tH0gxPunXZyjDqEnfHDcXY+X0FM7JgmeMyjDxzbq6GIqEX7gLoPAszwp Ayu4jIl2smg= =76yF -----END PGP SIGNATURE----- =================================== For PGP Public Key, Send E-mail to: pgp-public-keys(a)swissnet.ai.mit.edu In Subject line type: GET PHILP ===================================

1 0