December 2003 - cypherpunks-legacy

Re: Simple Hardware RNG Idea
by tcmay＠got.net 17 Dec '03

17 Dec '03

At 5:57 PM 9/30/95, zinc wrote: >regarding the use of radioactive material for generating random >numbers, lantern mantles are fairly radioactive. i'd say they would >be able to emit sufficient particles for OTP use, especially if one >builds a device that just constructs the pads all the time (ie, it >just sits there making various pads of X min length and Y max length, >storing them on a hard drive, or RAM if you're that rich). you just >request a pad from the machine when you need it and encrypt whatever >with it... Thorianated lantern mantles are only slightly radioactive. The counts per second is what matters. This will be a function of a lot of things, not the least of which is the detector area and the fluence of alphas intercepted. At the risk of repeating myself, there are easier ways of generating essentially random numbers. --Tim May (P.S., as my last word on this for a while. You may have heard that RAM chips can have bits flipped by the alpha particles emitted by low levels of uranium and thorium present in packaging materials. And that cosmic rays can do the same thing, at a lower error rate. Well, I discovered these effects in 1977 and wrote the original papers on this "soft error" effect. I'm not making an appeal to authority here, just telling you why I'm skeptical of all of these proposals to make a radioactive decay-based random number source. There are much easier ways.) ---------:---------:---------:---------:---------:---------:---------:---- 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."

3 3

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

17 Dec '03

>What you have described is the classic 'man in the middle' attack. >Netscape claims that SSL V.3 is immune to the MITM attack in >appendix D.4 of the SSL V.3 spec. > >You will need to get the 'filter' (MITM) key signed by Verisign. >Or hack Verisign's server-key-signing key. Or hack the Web of Trust used to verify the server's identity. It _is_ still a Web of Trust even if it's a fascistly-hierarchical tree; as long as it's possible to get a certificate without heavy contractual obligations, you can hack it, since the software has no way to check, now that Netscape is being nice and open and allowing non-Verisign certs. Remember that anybody can be a CA, and keys can be signed by multiple CAs. Verisign Business CA signs Carol's Certification Consultants' key. Carol signs Bob's Better Browser Business's key. Bob runs a server, selling really cool web tools. Verisign Business CA signs Moriarty's Mallet Makers' key. Moriarty signs Mr. X's personna key (trust us.) Mr. X makes a key called Bob's Better Browser Business, looking suspiciously like the real thing, only it's signed by M . X, and nobody bothered telling Bob about it. Alice, using Netscape, encounter's http://www.Bob'sBetterBrowser.com/, and decides to order a Better Browser. She gets Bob's public key and X.509 certificates by pressing a button, and receives a key and a pile of certs. Since it's not a secure session yet, is Mr. X intercepting them and sending her _his_ key and cert for "Bob" and his personna key with cert from Moriarty and his key and cert from Verisign? So Mr. X rips off Alice and/or Bob somewhere here, and Alice decides to sue Bob, who says "Hey, that's not my key, see my real set of certs", so they go off after Mr. X, who they can't find, and then go after Moriarty, who says "Hey, it's just a personna certificate; all I guaranteed was that I didn't sign more than one with the same name on it", which in fact appears to be true, and while after one case you can't be sure that there really wasn't a Mr. X somewhere, if three or four people start walking in saying Mr. X ripped them off using a key that Moriarty signed, maybe somebody'll think it's a movement... And remember that if you can finesse a signature, you can fake a Diffie-Hellman session with authenticated keyparts into tolerating your MITM attack, because you can convince Alice's browser into accepting the fake key for Bob, and as far as Bob knows, Alice is just another web-client that he doesn't know from Adam. Now, X.509 certs don't limit themselves to hierarchical or Web use, and most advice on using them recommends limiting the depth of a tree/web that you're willing to trust. Unfortunately, X.509 certs don't even have a comment field, much less a standardized "how much do you trust this person you're signing" field, though I suppose you can cram a bit into the X.400/500-style name formats. So if people want to really trust their digital signature system to prevent forgeries, then either there's got to be a law demanding lots of government- approved is-a-person nationalized ID card Internet Driver's License stuff, or else there's a market need for companies providing heavy-duty contractual backing for their key signatures (e.g. "In return for us signing your CA key with our high-trust CA key, you agree to accept $XM of liability for any misuse of keys you sign with it and to force anybody whose key you sign to also sign a contract like this one"). Probably a need for some standards to go with it. There's also a need for browsers and any associated certificate checkers to provide good user interfaces (so the _user_ can read the signature chain) and good tools to help the user decide what to trust. At minimum, the user interface probably should support things like different required amounts of trust for different categories of communication, e.g. business vs. personal letters vs. politics vs. smuggling. [This whole posting has been very annoying to write; I've just gone and argued that you can munge an X.509 hierarchy back into the Web of Trust and avoid the special-case treatment of Very Important CAs by just signing the top nodes of a hierarchy yourself and treating them like any other web-of-trust chain, and been thanking Netscape for allowing us to use open protocols instead of depending on Big Organizational Infrastructures that are run by the CON, and now I find myself posting a counter-example that says sometimes you have to be very careful and/or reinvent Bigness to avoid getting ripped off. But, hey, while it's not a demonstated hack, it's at least the theory for pulling one off, so even if it doesn't get me a T-shirt, at least it wins me a GIF of one :-) ] #--- # 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

N$ SSL vs M$ PCT
by rah＠shipwright.com 17 Dec '03

17 Dec '03

--- begin forwarded text From: "John Hemming CEO MarketNet" <JohnHemming(a)mkn.co.uk> Date: Sun, 01 Oct 1995 20:36:31 PM PDT To: www-buyinfo(a)allegra.att.com Mime-Version: 1.0 Subject: N$ SSL vs M$ PCT Having found that Micro$oft have produced a standards document about their alternative to SSL I was interested in comparing it to that written by Net$cape. The big question in my view is why did they produce a new proposal is it: a) Because they have found major flaws in the SSL protocol and wish to correct these (note the protocol not the implementation) or is it b) Because M$ want to "own" the Internet Security Software market and take the initiative off N$ who, notwithstanding their problems with implementation, have produced a working system. My personal view is that b) is the case. Comparison I have compared SSL V3 <draft-hickman-netscape-sl-01.txt> (available at www.netscape.com) PCT http://www.microsoft.com/windows/ie/pct.htm <draft-microsoft-PCT-91.txt> Both have status of Internet Draft. I have implemented SSL V2 in a browser (ftp://193.119.26.70/mktnet/pub/horse.zip) and a server (https://alpha.mkn.co.uk/) I have not implemented and do not intend implementing PCT Both SSL V3 and PCT now involve a vast number of different alternatives for Ciphers most of these alternatives do not help in any practical sense and I have not compared the lists. PCT allows for supporting SSL as well by using a bit in the SSL version number to indicate PCT. This means that servers can support both protocols. Clients cannot as the first message is sent by the client and there is no provision for SSL/PCT negotiation. Both PCT and SSL start with an initial session (GET or POST in wwwland) which establishes a master key and allow continuations of that key in later sessions. M$ use the following arguments in support of PCT: 1. it is simpler. PCT uses longer messages with more fields in them. It cuts out the final SERVER-FINISHED and CLIENT-FINISHED messages. It puts some of the data in SSL into other records. I quite like the verification in the CLIENT-FINISHED message which means that bad implementatations crash out at that point rather than putting rubbish into the higher level protocol. However, I consider that in essence there is no real difference. I, therefore, disagree with M$. 2. Message authentication uses different keys to the encryption keys. How this helps, apart from making implementation harder, I cannot quite fathom. We should not be using this secure channel protocol for proper message authentication only. The MAC (Message Authentication Code) is not what I would use for authentication from a legal and contractual background. I prefer Digitally Signed Instructions. 3. They say there is a security hole in SSL's client authentication. When the initial session establishing a session key uses (for example) 40 bit encryption. It does mean that subsequent sessions are also essentially just as insecure. This is the case for PCT and SSL. However, client authentication in SSL uses a digital signature using the client's private key. To get hold of this requires something more than simply being man in the middle. I think M$ are well out of order on this one. 4. They introduce a verify prelude field to make sure that the cipher type and other negotiations have not been tampered with. I suppose this is a fair if disingenuous point. If a "man in the middle" is tampering with your negotiations to make sure that you use a low level of encryption so that it can be cracked then your implementations should not be using such crippleware and cypherpunks will have cracked it ages ago. There is a point that should be made that servers and clients should really indicate the encryption cipher being used. Both my client and server do. So in essence M$ make 4 arguments. Two are IMHO wrong. One is irrelevant from a commercial perspective and the other one does not matter. In the end N$'s version is working. M$ are probably coding like mad. The final formula to determine the result may be if (M$>N$) SSL+=PCT; where M$ and N$ are measured in US Dollars. (MarketN£t is a UK company independent of both M$ and N$ although N$ were helpful in debugging the interoperability of my early essays into SSL for which I am grateful.) --- end forwarded text ----------------- Robert Hettinga (rah(a)shipwright.com) Shipwright Development Corporation, 44 Farquhar Street, Boston, MA 02131 USA (617) 323-7923 "Reality is not optional." --Thomas Sowell >>>>Phree Phil: Email: zldf(a)clark.net http://www.netresponse.com/zldf <<<<<

1 0

DNS Security ( was Re: NetScape's dependence upon RSA down...)
by Donald E. Eastlake 3rd 17 Dec '03

17 Dec '03

DNS security is an important point. People not aware of efforts in this area may want to check out draft-ietf-dnssec-secext-05.txt which has more or less passed working group last call and is being considered by th Security Area Directory / IESG. Reference code is also available (see message pasted at end below). Donald ===================================================================== Donald E. Eastlake 3rd +1 508-287-4877(tel) dee(a)cybercash.com 318 Acton Street +1 508-371-7148(fax) dee(a)world.std.com Carlisle, MA 01741 USA +1 703-620-4200(main office, Reston, VA) ================================ Date: Mon, 11 Sep 1995 10:24:28 -0400 From: James M Galvin <galvin(a)TIS.COM> To: dns-security(a)TIS.COM Subject: ANNOUNCEMENT: TIS/DNSSEC Version 1.2 alpha A new version of TIS/DNSSEC is now available. This version is distinguished from the previous version as follows. in sync with bind Beta26 uses RSAREF For information on how to acquire TIS/DNSSEC retrieve the file /pub/DNSSEC/README on the host ftp.tis.com via anonymous FTP. If you have any questions or problems please send a note to tisdnssec-support(a)tis.com. Enjoy, Jim

2 1

WHERE did this come from?
by rivaud＠rain.org 17 Dec '03

17 Dec '03

Attatched to this is, (I hope), the header text from a unsolicited e-mail message I received. The return address does not work. WHY? How can I inform the sender that I hope to never receive there material again? I tried "reply-all" through Eudora, but my reply got bounced back to me as undeliverable. I have removed the content of the original message. I don't know why it was sent to me, but it contained material that I found offensive. Any help, or words of wisdom and enlightenment would be appreciated. Information would be nice too. Thanks. -------------header should be below here-------------- i hope...--------

6 6

Re: VISA and Microsoft STT Specs available
by Bill Stewart 17 Dec '03

17 Dec '03

At 11:10 AM 9/29/95 -0400, Phill wrote: >Yes, VISA put the ASCII on their site... >We only host the ps version. Thanks! I looked at the Visa site, and it has a usable form of the documents still under construction; I waded through the 73-separate-page HTML version for a while.... There's some good intro material on how you use the stuff and who's responsible for what. Microsoft has the technical specs as one big slightly-HTMLized text file under http://www.windows.microsoft.com/windows/ie/stt.htm ; it's _much_ more readable, and has a pointer to the Visa version. (It's one big <PRE> with a few <B> and hrefs, in black-on-white.) Some cryptographic high points, from a brief scan. - 1024-bit RSA signatures, using PKCS#1 format. - SHA 160-bit hashes - Symmetric bulk crypto includes two options (I haven't yet seen how you choose between them; I assume it's export/domestic?) == RC4/64 with 24 bits of salt leaving 40 bits of real key == DES-CBC - yes, that's single-DES. IV=0. #--- # Bill Stewart, Freelance Information Architect, stewarts(a)ix.netcom.com # Phone +1-510-247-0664 Pager/Voicemail 1-408-787-1281 #---

2 1

Re:
by James A. Donald 17 Dec '03

17 Dec '03

In addition to being totally off topic and spamming lots of lists, Terra Libra is selling Ponzi schemes and pyramid schemes. This is just "make money fast" elaborately dressed in libertarian rhetoric. At 07:11 AM 9/28/95 +0100, Anonymous wrote: > This is the best description of debt currency I've seen. Debt currency >is today's most effective form of slavery. It is today's American slavery. > > The text is from the book: > > THE ECONOMIC RAPE OF AMERICA > WHAT YOU CAN DO ABOUT IT > >by Frederick Mann of Terra Libra > >The book costs $19.95 plus $2 postage and handling. >It can be ordered from: > >Terra Libra >2430 E. Roosevelt #998 >Phoenix, Az 85008 > --------------------------------------------------------------------- | 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

2 1

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

17 Dec '03

On Sun, Oct 1 1995, Simon Spero wrote: > On Sat, 30 Sep 1995, Don Stephenson wrote: > > > I don't think binding hostnames to certificates helps much because > > both hostnames and IP addresses can be spoofed and DNS servers can be > > subverted. The important thing is the binding to the "service" name or > > In this particular case, hostnames do help, because they are information > imbedded in the url used to access the server. By verifying the hostname > in the certificate with the hostname in the url, you can state with a > high degree of confidence that the object retrieved is precisely the > desired object covered by this url. > Hostnames help only a little. Often the host name belongs to the ISP that is providing the server resources. For example when I ordered sushi last night from WOW, the URL was "https://www.ird.net/[...]wow[...]", but the certificate was issued to "www.sunnyside.com" (as displayed by the File->DocumentInformation menu item in Netscape): Version: 00 Serial Number: 02:72:00:00:3C Issuer: C=US, O=RSA Data Security, Inc., OU=Secure Server Certification Authority Subject: C=US, ST=California, L=Palo Alto, O=Sunnyside Computing, Inc., OU=Internet Services, CN=www.sunnyside.com PROBLEMS: (1) The certificate *was* issued with a host name in the CN field, but it did not match the host name in the URL and my browser did not care to warn me of this discrepency (I had to manually request to see the certificate and check it myself -- not a likely precaution for Joe Sixpack). (2) Even if the certificate did match the URL (and my browser did check it) I still have no way to know that "Sunnyside Computing" or "sunnyside.com" or "ird.net" is actually the authentic/official ISP for WOW and not an imposter or MITM. (3) Netscape is making the problem worse (yes, worse) in the next release by allowing the user to specify their own list of trusted CAs. (I will elaborate on this unpopular view below.) NON-PROBLEMS: (1) SSL did its job. It is only a session layer. It assured the application that a secure session was established with the entity named in the certificate. (2) The sushi was very good. :-) DISCUSSION: Re: problem 2, it would be better to have the certificate issued with the subject ... O=Waiters on Wheels ... CN=www.ird.net ... so that the browser can automatically check it against the URL and the user can be assured that (assuming suitable CA policy) ird.net is an authentic/official ISP for WOW. I think the browser should check the CN and hostname in the URL and display a popup warning if they do not match, and (optionally but by default) display a popup whenever a new session is started with a different certificate -- and of course show the certificate. This is not perfect, of course, its just better. Re: problem 3, about how allowing the user to specify their own list of trusted CAs is bad. All it takes is for any web page to put up text like ... "Dear Joe Sixpack, in order to assure your privacy while viewing these naughty pictures you must add the following certificate to your such-and-such file ..." and Joe Sixpack will be happy to do it. Even Mary Moderately-Savy might be tricked in to doing it on the false assumption that it would only affect security for the naughty pictures site (that she may not care about), and not affect security for her stock-broker. This false assumption might be based on the fact that the (legitimate) stock-broker uses a different CA. -Bill

3 2

Elementrix Press Release
by David Van Wie 17 Dec '03

17 Dec '03

ELEMENTRIX ANNOUNCES REVOLUTIONARY ENCRYPTION FOR INTERNET AND ALL DIGITAL COMMUNICATION ANNOUNCED AT NETWORLD + INTEROP POTP Secure Mail, Secure FTP Avoid Limitations of Existing Systems NEW YORK, Sept. 29 /PRNewswire/ -- Elementrix Technologies, Inc. has announced a security technology for digital communications based on the only encryption method which is considered unbreakable. The method, POTP (Power One Time Pad) eliminates the weaknesses that allow break-ins to existing systems. Two products which feature this technology, POTP Secure Mail and POTP Secure FTP were voted the leading security products in the Best of the Show awards announced at the Networld + Interop Show in Atlanta this week. The technology is expected to be a boon to both corporate and individual users of the Internet and a major step forward for electronic commerce. The products are an automatic implementation of One Time Pad (OTP), the only encryption which is considered unbreakable. Prior to the invention of POTP, OTP was used only in extreme situations where cost and logistical constraints were not determining factors. Now POTP(TM) makes this legendary encryption readily available as a commercial software package. As with OTP, POTP creates keys that are as long as the messages they encrypt, and are used only once. But unlike OTP, which requires extensive key distribution and management, POTP(TM) creates real time: random keys are created automatically during the communication process. Therefore, users can instantly send private and sensitive e-mail over the Internet or other open systems with 'point and click security.' "Elementrix has found a logical way to generate non-algorithmic, dynamically changing keys at two separate sites without transmitting them on the line and without using parallel lines," said Dr. David Kahn, the country's leading historian of cryptography and the current visiting historian at the National Security Agency. "Elementrix is well within its rights to call this technology Power One Time Pad. I see no way of reconstructing the encryption key," he said at the press conference announcing the products. "POTP represents a paradigm shift in encryption," said Winn Schwartau, an internationally recognized expert on electronic security who also spoke at the press conference. "The fundamental technology is entirely different from any existing encryption scheme. This is the first system I've ever seen that can make the entire Internet secure for non-expert users." Schwartau also noted the importance of the system for corporate users based on its advantages in the area of key management. "The problem with systems that depend on passwords for security is that the infrastructure required to manage and distribute them is cumbersome, especially in large organizations," he said. "POTP eliminates the need for this infrastructure." POTP(TM) technology can be used to encrypt any digital communication. This can include data communications, secure telephones, wireless, satellite, cable TV and virtually any method of modern, digital communications. All POTP(TM) products are automatic and transparent to the user. The system addresses a paradox in encryption: "If the keys are truly unpredictable then there should be no way for one party to automatically re-create the same keys that are being used by the other," said Isaac Rubinstein, executive vice president of Elementrix Technologies Inc. "However, POTP's dynamically changing random keys are created by a patent pending method during the communication process itself," he said. "After the POTP(TM) between the two parties has been initialized -- only the very first time they communicate -- a One Time Pad process is executed continuously." POTP(TM) is patent pending. This unique method is fully disclosed on an individual basis only, through a non-disclosure agreement. A select group of encryption and security experts, including Kahn and Schwartau, have been fully briefed and have endorsed the new technology. POTP(TM) Secure Mail carries a very low overhead of less than 1.2%. Encryption and decryption are very fast and have virtually no effect on software performance. The system requires an IBM or compatible computer with a 386 or higher CPU and 4MB of RAM; a modem or network card; and any TCP/IP stack for Microsoft Windows. The software is Windows 3.1 and Windows 95 compatible. Professsional Encryption/Personal Privacy In the e-mail package, the entire message including attachments is encrypted in real time as it leaves the PC. Messages remain totally private while stored on the mail server, handled by an Internet provider, and/or sent over communication lines. Messages are sent in standard e-mail format with no need for a special mail server. Any standard SMTP/POP3 mail server will handle the messages. There is no need for any manual key distribution or management: no public and private keys; no master and session keys. Messages remain private and cannot be read by anyone, even system administrators. The manufacturer's suggested list price for the single user is $245. A special price of $198 will be available during the product introduction. Elementrix Technologies Elementrix Technologies Inc., based in New York City, is a subsidiary of Elementrix Technologies Ltd., based in Haifa, Israel. The parent company is a subsidiary of Elron Electronic Industries Ltd., Israel's leading advanced technology holding company. Elementrix was founded in January 1994 in order to develop commercial applications for its POTP(TM) encryption and other security products. CONTACT: Michael Meric, Fusion TMA, 212-977-4600, fax: 212-265-9684, e-mail: mmeric(a)elementrix.co.il, or Maia Aron, VP Marketing, Elementrix, 212-888-8879, fax: 212-935-3882, e-mail: maia(a)elementrix.co.il

5 4

Netscape hole without .Xauthority (fwd)
by Jyri Kaljundi 17 Dec '03

17 Dec '03

Haven't seen this on the cypherpunks yet, sorry if this has been here already. Juri <o Jüri Kaljundi e-mail: jk(a)digit.ee o< >o tel: +372 6308994 o> <o DigiTurg http://www.digit.ee/ o< ---------- Forwarded message ---------- There's a huge hole in the Netscape remote control mechanism for the X-Windows based clients. Potential impact : anybody can become any user that uses Netscape on any system without sufficient X security. Let's suppose that you have an account on a target machine, where somebody is using Netscape, and either the xhost checking is disabled, or you can set the xhost yourself (e.g. if you have an account and the target user has no .Xauthority, as is frequent in university computer rooms). Then you can gain access to the target user's account using the following steps : - make a text file containing only "+ +" accessible (as file, as URL, or whatever you like) to the target Netscape client. This is quite easy, either if you have a personal WWW page (http://... URL) or an account on the target machine (file://... URL), or even by uploading it to an anon FTP - set your DISPLAY environment variable to the target display - run the following set of commands : netscape -noraise -remote "openURL(<put-your-URL-here>)" netscape -noraise -remote "saveAs(.rhosts)" netscape -noraise -remote back In the second command, the path should be specified whenever possible (~ is not accepted). If the target user does not already have a .rhosts and is not looking at that precise moment, then the chances are it worked ! Solution to the problem : every user concerned should either create a Xauthority file, or stop using Netscape. MXK PS: WHY do they bother with PGP and RSA security when they keep such holes ???? +------------------------------------+---------------------------------+ | Denis AUROUX (MXK) | Ecole Normale Superieure | | 255 rue Saint-Jacques | 45 rue d'Ulm | | 75005 PARIS FRANCE | 75005 PARIS | | email: auroux(a)clipper.ens.fr | FRANCE | +------------------------------------+---------------------------------+ | This .sig is SHAREWARE. If you use it often, please send me $50. | | After registering you will receive a fully functional .sig and all | | updates for free. | +----------------------------------------------------------------------+

7 6