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
participants (5)
-
anon-remailer＠utopia.hacktic.nl -
goedel＠tezcat.com -
hallam＠w3.org -
iagoldbe＠csclub.uwaterloo.ca -
sameer