Re: Netscape's random numbers

-----BEGIN PGP SIGNED MESSAGE-----

>Congrats, nice job!

Yes, well done.

>The Netscape license explicitly prohibits decompiling (except where such
>prohibition is illegal).  When this hits the media it will be important
>to avoid being tarred with the "hacker breaks rules and breaks in" brush.
>More subtly, it's probably a bad idea to call into question the overall
>business model of client binaries on the net.
>
>Instead, emphasize importance of open code, public reviews, ability to
>link in your own code that meets public specs, etc.  All of these things
>the Internet was designed to do, and U.S. ITAR regulations are designed
>to prohibit (globally, anyway).  And also that the bad guys will never
>play by the rules.  And re-emphasize that solutions are possible, just
>that the U.S. government prevents them from being deployed in a global
>economy.

Before we go to the news, perhaps we should demonstrate the exploitation of
this hole. It would certainly make selling this story a whole lot easier.


-----BEGIN PGP SIGNATURE-----
Version: 2.6.2

iQBgAwUBMF27PHIf3YegbdiBAQGI7AJXY5d2Su52MWXrh6tP20vOai/Rsbd6+oqx
urWUP34wPv5dqMv1Mw6XDlstX5Q3KmOMeTOjAwcjuJXY5Z3RhkL0gi0nMBUS/IdZ
b/GN
=vhHo
-----END PGP SIGNATURE-----

Dietrich Kappe | Red Planet    http://www.redweb.com
Red Planet, LLC| "Chess Space" | "MS Access Products" |  PGP Public Key
1-800-RED 0 WEB|    /chess     |       /cobre         | /goedel/key.txt
Web Publishing | Key fingerprint: 8C2983E66AB723F9 A014A0417D268B84

>Before we go to the news, perhaps we should demonstrate the exploitation of
>this hole. It would certainly make selling this story a whole lot easier.

In the first place it is a bit late for that. The problem is all over the net 
already. Expect press coverage tommorow or Wednesday. Secondly I would prefer a 
solution.


Random number generation and maintenance is a whole lot harder than RFC 1750 
makes out. Although that RFC has some usefull ideas it does not provide a 
blueprint fora secure ergodicity management facility.

When I wrote code for Shen I was very carefull in the use I made of the output 
of the ergodicity manager. In particular correlation is a major concern. If a 
pseudo random output is exposed it must not predjudice other random values.

Consider the class of attacks where Mallet receives a message from Alice and 
uses the knowledge of his random number to discover the random number used in 
Alice's later message to Bob.

I always use hash functions as a "one way trap" to ensure that values cannot be 
reverse engineered to discover the internal state of the random number 
generator. I am also careful to erase all internal state before exiting the 
program. 


	Phill Hallam-Baker

In article <v01510100ac836b357d90@[206.1.161.4]>,
Dietrich J. Kappe <goedel@tezcat.com> wrote:
>>Congrats, nice job!
>
>Yes, well done.
>
>Before we go to the news, perhaps we should demonstrate the exploitation of
>this hole. It would certainly make selling this story a whole lot easier.
>
Too late.  The news (in the form of a call from John Markoff, New York Times)
came to Dave and me first thing this morning.

In other news:

unssl.c is presently in the /pub/cypherpunks/incoming/ directory
on ftp.csua.berkeley.edu.  Remember: you must be a "US person"
to download it blah blah blah.  It will (hopefully) soon move to
a more suitable location under /pub/cypherpunks.

The HP on my desk seems to like compiling it with "gcc -O3 -o unssl unssl.c".
YMMV.

   - Ian "it's now about 1:20 pm PDT; I wonder when it will get exported..."

Now available in /pub/cypherpunks/cryptanalysis
Please do not export.

-- 
sameer						Voice:   510-601-9777
Network Administrator				FAX:	 510-601-9734
Community ConneXion: The NEXUS-Berkeley		Dialin:  510-658-6376
http://www.c2.org (or login as "guest")			sameer@c2.org

> Please do not export.

ftp://utopia.hacktic.nl/pub/incoming