December 2003 - cypherpunks-legacy

SecureDrive News - Win95, non-USA ftp sites
by edgar＠highnrg.sbay.org 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- I have received the following information about running SecureDrive 1.4 with Win95, thanks to Ed Stone, This is what I sent to a person who asked how to use secdrive on win95...... >>>>>>>>>>>>>>>>>>>>>inserted text follows Try this: in your autoexec.bat file enter this, using your path to secdrive: C:\your-path-to-secdrive\SECTSR C:\your-path-to-secdrive\LOGIN your-encrypted-disk-letter: /S C:\your-path-to-secdrive\login your-encrypted-disk-letter: During normal win95 startup, you will be asked to enter your passphrase. Now when 95 come up, the tsr is running, your passphrase has been entered, and everything operates as if the disk is not encrypted. EXCEPT.... the tsr you have loaded (sectsr) makes windows load real-mode drivers for the disk, instead of protected mode drivers. This will make disk access somewhat slower, but not a big deal. When you startup win95 and you don't need to use secdrive, just hit enter when the boot process asks for your passphrase, and it will behave as if you entered a "wrong passphrase" and that drive will not be visible to win95, and protected mode drivers will load... Hope this helps. In particular that the normal drivers will load even with sectsr resident if the correct passphrase isn't entered is new and valuable information. I have also just learned that SecureDrive 1.4 is now available on some non-USA (and so not export-controlled) ftp sites, ftp://utopia.hacktic.nl/pub/disk/secdr14.zip ftp://ftp.ox.ac.uk/pub/crypto/misc/secdr14.zip I have verified that the hacktic file is an exact copy of the zip I released in the USA. Edgar W. Swank <edgar(a)HighNRG.sbay.org> SecureDrive Co-author -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBMG2BIt4nNf3ah8DHAQH49AP/YzmRhOLk+JdPx3emgWxv7vcX/2e7KR/Y WK0p1hiPUAHDsG3ZEd3fD+DZyILxq0oJcQSsrdtsAFiSnw955i/g+XsGFVT8UGku YzTXB4LXnJE4IqA2qd8aUKU9xk9S57xN1p+xrLlEK2jJrFMg+h9cPMp1a0lwivvP Ff2lF1+lthI= =DYRV -----END PGP SIGNATURE----- --- edgar(a)HighNRG.sbay.org Keep Freestyle Alive!

1 0

Re: NetScape's dependence upon RSA down for the count!
by jbass＠dmsd.com 17 Dec '03

17 Dec '03

> BTW your 'offer' is silly- this is not a trivial amount of work, and you > would not deserve any credit for coming up with so ordinary an > attack. Write the code yourself, or pay the market rate for it. > -- > Eric Murray ericm(a)lne.com ericm(a)motorcycle.com http://www.lne.com/ericm So is the Tee Shirt offer, and so is cracking the RSA public key algorithm ... the point is that at least two teams did it. My offer is trival in $$'s I agree, but the challenge I offer is to focus on the weaknesses of SSL rather than it's strengths (large keys). I suspect this is easier than most people think, so maybe I should offer a Tee Shirt instead? I suspect the certificates can be attacked in one of several ways. The most likely is that the filter can use the servers certificate and fake, forge, or simply subsititue a valid one in the filters name for the client. This might mean that the filter has to become a trusted server as well. I don't see any problems with the filter playing client to the server given the SSL protocol. Another is since the clients are often distributed over the net, that another filter is installed recognize clients and alter them on the fly to avoid the client/filter problem in the future. Another tack is based on getting very close to the server (in a bridge or router in the direct path to the server) in which the filter might acutally be able to get the get valid certificates signed in the servers name, while eating the real requests. The reality is that all three parties are strangers, and I have had doubts about the very nature of certificates & public key in this case. John Bass DMS Design

2 1

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