- cypherpunks-legacy - lists.cpunks.org

SAIC Global Web
by anonymous＠freezone.remailer 17 Dec '03

17 Dec '03

URL: http://www.saic.com/business/locations/index.html *** Business Directory *** _________________________________________________________________ U.S. Locations Alphabetical List o Alabama o Illinois o Nebraska o Rhode Island o Alaska o Indiana o Nevada o South Carolina o Arizona o Kansas o New Hampshire o South Dakota o Arkansas o Kentucky o New Jersey o Tennessee o California o Louisiana o New Mexico o Texas o Colorado o Maryland o New York o Utah o Connecticut o Massachusetts o North Carolina o Virginia o Delaware o Michigan o North Dakota o Washington o Florida o Minnesota o Ohio o Washington D.C. o Georgia o Mississippi o Oklahoma o West Virginia o Hawaii o Missouri o Oregon o Wisconsin o Idaho o Montana o Pennsylvania o Wyoming _________________________________________________________________ Last updated on 07-05-95 ---------- URL: http://www.saic.com/business/locations/others.html *** Business Directory *** _________________________________________________________________ International Locations Alphabetical List CANADA * Halifax * Montreal * Ottawa * Vancouver COLOMBIA * Colombia, LTDA. FRANCE * Paris La Defense/EUROPE (Loc. 596) GERMANY * Germany * Kaiserslautern/SCT (Loc. 826) * Landstuhl/CHCS HONG KONG * Hong Kong (Loc. 789) ICELAND * Keflavik/CHCS MEXICO * Mexico City RUSSIA * Moscow/MIR (Loc. 764) SPAIN * IBERSAIC (Loc. 693) UNITED KINGDOM * Aberdeen (Loc. 797) * Aberdeen/SAIC Ltd (Loc. 728) * Birmingham * Camberly UK/SAIT (Loc. 666) * Cambridge/TOP EXPRESS (Loc. 340) * IBM SAIC (Loc. 667) * London/Andrew Palmer (Loc. 798) * Meriden (Loc. 865) * Stockley Park (Loc. 884) _________________________________________________________________ Last updated on 07-05-95

1 0

Re: Cypherpunks Press release
by James A. Donald 17 Dec '03

17 Dec '03

At 05:26 PM 9/30/95 +1000, Jiri Baum wrote: >All that is needed then is someone with a fax machine to volunteer >to receive the fax, type it in and summarise the response afterwards >(noting points on which there was disagreement, and who disagreed >in what way). Let the dim bulbs subscribe to the list themselves. If they are not capable of that, they will not make any intelligent reports on it anyway. --------------------------------------------------------------------- | We have the right to defend ourselves | http://www.jim.com/jamesd/ and our property, because of the kind | of animals that we are. True law | James A. Donald derives from this right, not from the | arbitrary power of the state. | jamesd(a)echeque.com

1 0

Re: Crypto hardware (was: Using sound cards to accelerate RSA?)
by cman＠communities.com 17 Dec '03

17 Dec '03

Simon-- There is a lot more to cryptography hardware than just making stuff go fast. Any kind of co-processor array could handle the job -- doesn't have to be DSPs. For unsigned integer math, the 486 DX4/100 is a perfectly decent chip, and prices are plumetting. If all you want is to make RSA go fast, you can rack up as many of these as you want, and do your work at Ethernet speeds (which should be more than fast enough for the forseeable future.) Also, you get to use your old familiar (and inexpensive) programming tools to write your code. It also turns out that when you're actually using cryptography to do valuable stuff, a lot of other concerns are just as important as speed -- in particular, physical security over the private keys. Most server-oriented cryptography add-ins are highly tamper-resistant units that can only be re-keyed when some sort of dongle is attached. Said dongle can be kept much more securely than a whole computer. Although other threats still remain, this substantially reduces the threat of key compromise. Incidentally, good hardware of this sort uses ASICs that give substantially more bang for the buck than the DSP solutions you're suggesting. Certainly messing around with DSPs is fun -- I've done it and enjoyed it -- but I don't think they will ever be significant as cryptographic co-processors. >That's another question. A DSP chip can also be used for crypto - yet >sound cards and nexts aren't ITARed, and aren't really considered >dual-use. A Modular exponentiator isn't a crypto device (hey - >it's a bignum accelerator for Mathematica). Now, if I had a pipelined >WSI chip capable of delivering one result per cycle, I could think of >some useful applications, but ... > >Simon

1 0

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

17 Dec '03

I haven't read the SSL spec for a while but my understanding was that the server passed it's public key to the client via a certificate signed by a mutually trusted certificate authority (i.e., Verisign). How would the filter be able to forge such a certificate ? - Don > From jbass(a)dmsd.com Sat Sep 30 16:47:11 1995 > Date: Sat, 30 Sep 95 16:39:57 -0600 > From: jbass(a)dmsd.com (John L. Bass) > To: www-security(a)ns2.rutgers.edu, cypherpunks(a)toad.com > Subject: Re: NetScape's dependence upon RSA down for the count! > > > jbass(a)dmsd.com writes: > > > 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. > > > > Yeah, but in order for this to work, the fake server needs to know > > netscape.com's private (secret) key, no? > > > > -jon > > No ... the public part of any server private key is held by the filter > and not returned to the client. The client only encrypts with public > keys provided by the filter. The Server only encrypts with public keys > provided by the filter. The filter has cleartext of the entire session. > > John > >

1 0

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