- cypherpunks-legacy - lists.cpunks.org

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

17 Dec '03

Well guys and gals ... I spent some time reading documentation on the www servers for NetScape and Community ConneXion (c2.org) The "messenger attack" as described in my earlier posts regarding public key encryption and key management seems to apply to NetScape's SSL. I have a Fifty dollar bill for the first person to submit to the mail box nethack(a)dmsd.com a working Unix server (with cleartext session logs) which accepts all connections on a unix based host to the www port and redirects them to netscape.com leaving a clear text log of each session's SSL packets in /tmp by session. All entries become the property of DMS Design. The winner and I will submit a claim for one of Community COnneXion's "I HACKED NETSCAPE" tee shirts as a server hack. (Have Fun!!) After a careful examination of NetScapes public documentation it appears that SSL which is based upon RSA's public key technology may be down for the count. The fall of SSL would doom NetScapes current claim of "Strong exhortable cryptography for credit card-based financial transactions" as outlined in Taher Elgamal's (NetScape's Chief Scientist) white paper titled "COMMERCE ON THE INTERNET: CREDIT CARD PAYMENT APPLICATIONS OVER THE INTERNET" Version 1.00 dated July 14, 1995 which can be found on the www as http://home.netscape.com/newsref/std/credit.html. SSL doc can be found as http://home.netscape.com/newsref/std/SSL.html. John L. Bass Owner, DMS Design

1 0

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

17 Dec '03

Ok, several people have asked: > Please explain to me how you can break SSL using the above method. I > don't follow your line of thought. How could my fake www server > intercept and redirect packets to netscape.com short of hacking a DNS > server? client -> filter Client sends packet with K(c) filter -> Server filter forwards packet with K(f) filter <- Server Server sends encrypts with K(f) client <- filter filter re-encrypts with K(c) As the protocol progresses the filter also uses the master key, and follows the renegotiation as the master key expires. The existance of a working filter is enough to invalidate the security in NetScape's claims. hacking a DMS server is one way, spoofing a DNS reply to named is easier, simply packaging the filter into a router/bridge close to the server is more effective ... even if hacking the incoming phoneline/T1 line to the server and inserting a very transparent bridge AKA a phone tap. There is enough dollars to make the risks ... :) John BTW ... how do I join for these two list? Where are they archived to catchup with past traffic?

1 0

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

17 Dec '03

At 4:14 PM 9/28/95, cjs wrote: >Hello all. > >Someone mentioned this on IRC last night, and it sounded like a really >cool idea, so I thought I'd mention it. > >The idea is to generate random numbers using a geiger counter tube and >a small portion of radioactive substance (like perhaps the stuff they >use in smoke detectors?) Would that be random enough? > >I thought it was a neat idea anyway. It's a well-known idea. My FAQ has a section on this, and the Cypherpunks archives have many mentions of this. For the newcomers, here are some of the issues, very briefly presented: 1. Incorporating a "Geiger counter tube" is nontrivial. A solid-state detector does the same thing, and is a better approach. 2. Incorporating Am-241 or other alpha emitters in microcurie levels would require licensing, regulatory oversight, etc., etc. Don't count on it. 3. Data rates are fairly low. Anything that "clicks" at high rates (> 1K counts per second) would be too radioactive to ship. 4. Zener diodes and other random noise sources are cheaper to build, more consistent in output, and easier to integrate into actual products. --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."

3 2

Re: "Notes" to be Eclipsed by "Netscape"
by Rich Salz 17 Dec '03

17 Dec '03

> I've seen Notes running ... > but my access to it was only marginal. > But, knowing the software, it wouldn't surprise me if there were > some serious bugs in the security code. Er, sounds to me like you're leaping to some conclusions... At any rate, one of the designers of Notes's security was Charlie Kaufman (formerly of Digital, recent author of a security book mentioned here) and he is No Slouch. /r$

1 0

RSA's comments on RC4 weak keys
by baldwin 17 Dec '03

17 Dec '03

Well, I seem to be falling into the role of spokesperson for RSA on the net. It gives me something to do other than design reviews and programming. Here is our response to the excellent work that Andrew Roos has been doing on RC4. I am glad that people are looking at RC4 critically. --Bob ----------------------------- September 29, 1995 statement from RSADSI RSA Data Security Inc. has been following the emerging reports of a weakness in certain keys for the RC4 cipher. RSADSI's researchers have been aware of this particular property of the RC4 cipher for over a year. Most ciphers have a property whereby an enormous amount of known plaintext will provide a slight reduction in exhaustive key searching. The linear cryptanalysis of the DES cipher is an well known example of this. Limitations like this in the underlying ciphers are addressed by following sound advice on the design of the overall cryptographic system. Products that include RC4 from RSADSI are not compromised by this attack. Companies that license the BSafe cryptography toolkit have always been given advice that overcomes this limitation of the RC4 cipher, and this is true even for products that were built >before< this specific problem was discovered by the researchers at RSADSI. These researchers also monitor all developments in the field of cryptography and cryptanalysis so they can keep RSADSI's customers appraised relevant developments.

3 2

MITM attacks, the day after ...
by jbass＠dmsd.com 17 Dec '03

17 Dec '03

I suppose C2 got as many "do you know how hard it is" complaints as I have, or more. But dispite that, several people broke keys. There seem at this point to be two messenger or man in the middle attacks on SSL that have enough merit to explore further. #1 Attack client binaries to suppress certificate validation, and accept ones forged by the filter/MITM. The binary attack could occur during down load from NetScape (a good ISP level attack) or after the fact with a virus. The client binary would be normally functioning with servers other than the attacking MITM filter. #2 Present client with the filters valid certificate and hope that in the rare case the user looks, that they will not question it, or even know what a valid one from the real server is. Since detection is possible in both of these, attack only a few percent of the traffic until the heat is on, then lay dormant or move to a different site. Suggested to me this morning was taking a harder look proxy servers. John

2 1

WWW Proxy Server Vulnerabilities
by brianm＠cs.bu.edu 17 Dec '03

17 Dec '03

Regarding WWW SSL middle-man attacks, John L. Bass writes: : Ok, several people have asked: : : client -> filter Client sends packet with K(c) : filter -> Server filter forwards packet with K(f) : filter <- Server Server sends encrypts with K(f) : client <- filter filter re-encrypts with K(c) : : hacking a DMS server is one way, spoofing a DNS reply to named is easier, : simply packaging the filter into a router/bridge close to the server : is more effective ... even if hacking the incoming phoneline/T1 line : to the server and inserting a very transparent bridge AKA a phone tap. : Consider the following attack: Many organizations, especially ones with low bandwidth localnet-to-internet connections and those with firewalls, have implemented `proxy-servers' to retrieve documents from the outside world and cache them for fast future localnet access. ALL WEB TRAFFIC FROM THE LOCALNET TO THE INTERNET GOES THROUGH THESE PROXY SERVERS, transparently to the client and web servers after the client has been configured to do so. If one of these servers were to be compromised, an attacker could easily implement the the middle-man scheme described above. Note that proxy servers are fairly common (especially since firewalls require them), so the apparatus already exists for the middle-man attack outside of modifying DNS servers and routers. The irony of the situation is that it is the most secure organizations who have implemented firewalls that are the most vulnerable to the middle-man attack. Brian Mancuso Boston University Computer Science Dept. PGP DF FA C0 EF 51 B0 23 54 Tel: 617.352.6552 Net: brianm(a)cs.bu.edu KFP 5C 8D E0 50 C6 39 C6 0F

2 1

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

17 Dec '03

> From ses(a)tipper.oit.unc.edu Sat Sep 30 20:43:51 1995 > My currently recommended approach is to enforce the verisign requirement > that all valid hostnames for the server be included in the certificate as > CN values. This allows the check to be made below the application layer. > Unfortunately a lot of currently issued certificates are non-compliant > (even Verisign and netscape :-); any fully automated implementation needs > a static table of hostnames aliases- interactive applications can > display certificates for manual review. 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 definition (e.g. InterState online banking service). > This is not really much protection. Getting hold of any key is much > easier than getting a specific key, and don't forget there are a number > of vulnerable keys floating around until their expiration dates pass. Well of course, if the secret key of the server (or worse yet, certificate authority) is compromised, all bets are off. That's true of just about any protocol you can dream up. Are you just referring to the problem of accurate and up to date certificate revocation lists (CRL) being available ? If so, you're right, this is a very difficult problem to solve without having a truly reliable and pervasive key-distribution & CRL system deployed throughout the world. - Don

3 2

Re: WHERE did this [NOISE] come from?
by Alan Olsen 17 Dec '03

17 Dec '03

At 10:38 PM 9/30/95 GMT, you wrote: >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. Well, at the bottom of the post, it listed contact info at: >National Alliance can also be reached at: > >WORLD WIDE WEB: http://www.natvan.com (if unavailable, try our ftp site) >FTP SITE: ftp.netcom.com, path /pub/NA/NA (I find it funny that they go through the trouble of forging an e-mail address yet they give ftp and web sites at the end of the page.) Hopefully that bit of targeting information will be of some use... | Visualize whirled keys | alano(a)teleport.com | |"It's only half a keyserver. I had to split the | Disclaimer: | |other half with the government man." - Black Art | Ignore the man | | -- PGP 2.6.2 key available on request -- | behind the keyboard.| | http://www.teleport.com/~alano | <fnord> |

1 0

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