Re: building a true RNG
At 03:18 PM 7/29/2002 -0700, David Wagner wrote: I don't even think anyone has analyzed the entropy preservation of a theoretically perfect random oracle Well, I know this particular point wasn't central to your email, but I'm not sure I agree with you on this small point. I believe it should be more or less straightforward to analyze the entropy preservation of a random oracle (alas, so straightforward you probably won't find any paper on it in the literature). Actually, it's covered very well (but briefly) in HAC (in section 2.1.6) and they refer to a seminal work by Flajolet and Odlyzko (Google finds references to it quite easily). regards, Greg. Greg Rose INTERNET: [EMAIL PROTECTED] Qualcomm Australia VOICE: +61-2-9817 4188 FAX: +61-2-9817 5199 Level 3, 230 Victoria Road,http://people.qualcomm.com/ggr/ Gladesville NSW 2111232B EC8F 44C6 C853 D68F E107 E6BF CD2F 1081 A37C - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: building a true RNG
David Wagner said, The problem can really be divided into two parts: 1. Is our entropy crunching algorithm secure when used with a random oracle instead of SHA1? 2. Does SHA1 behave enough like a random oracle that the answer to question 1. is in any way relevant to the real world? I suspect that question 1. is not hard to answer in a formal, rigorous, provable way. It is only question 2. that is hard to answer. It is absolutely true that we have no proof for question 2. That said, we should keep in mind that none of our cryptographic algorithms (even 3DES) come with a proof of security. All we have to rest on is years of unsuccessful cryptanalysis. But there's a big difference: the random oracle `assumption` is clearly not valid for SHA-1 (or any other specific hash function). Since this is trivial, it is less clear what is the cryptoanalytical problem that SHA1 was tested for. SHA-1 (and similar functions) were tested mainly for collision-resistance (and also for one-wayness). But clearly these properties are not sufficient for the proposed use (to extract entropy). So the question is again: what is an assumption which we can test SHA-1 against, and which is sufficient to make the `entropy crunching alg` secure? I found that when trying to explain and define hash functions and their properties, I didn't find a satisfactory definition for the `randomness` properties. Best Regards, Amir Herzberg See http://amir.herzberg.name/book.html for lectures and draft-chapters from book-in-progress, `Introduction to Cryptography, Secure Communication and Commerce`; feedback appreciated! - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: building a true RNG
-- On 30 Jul 2002 at 17:02, Amir Herzberg wrote: I found that when trying to explain and define hash functions and their properties, I didn't find a satisfactory definition for the `randomness` properties. Randomness is of course indefinable. A random oracle is however definable. If SHA-1 is indistinguishable from a random oracle without prior knowledge of the input, then we would like to prove that for an attacker to make use of the loss of entropy that results from the fact that it is not a random oracle, the attacker would be need to be able to distinguish SHA-1 from a random oracle without prior knowledge of the input. --digsig James A. Donald 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG CxPM+cm8zcgy+aC2EA+wlmYH4DUaMzSLmaJFJN6v 225C9EmZaK85VbOoLT5EpF24GeytUdtyW9T/FjXgw - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: building a true RNG
Amir Herzberg wrote: But there's a big difference: the random oracle `assumption` is clearly not valid for SHA-1 (or any other specific hash function). Well, the random oracle model has problems, but I think those problems are a bit more subtle than just an assumption that is true or false. So the question is again: what is an assumption which we can test SHA-1 against, and which is sufficient to make the `entropy crunching alg` secure? Hmm; I thought I answered this before. Was it unclear? If so, please ask. In any case, here's a summary. In the standard model (without random oracles), there is *no* such assumption. There's no hope for finding such an assumption, if you want to build a general-purpose entropy cruncher that works for any distribution on the input samples. One can prove this. No matter what function you choose, there is an input distribution that makes this function inadequate. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Announcement: OpenSSL 0.9.6e (Security related upgrade)
OpenSSL version 0.9.6e released === OpenSSL - The Open Source toolkit for SSL/TLS http://www.openssl.org/ The OpenSSL project team is pleased to announce the release of version 0.9.6e of our open source toolkit for SSL/TLS. This new OpenSSL version is a security and bugfix release and incorporates several changes to the toolkit (for a complete list see http://www.openssl.org/source/exp/CHANGES). The most significant changes are: o Important security related bugfixes. o Various SSL/TLS library bugfixes. We consider OpenSSL 0.9.6e to be the best version of OpenSSL available and we strongly recommend that users of older versions upgrade as soon as possible. OpenSSL 0.9.6e is available for download via HTTP and FTP from the following master locations (you can find the various FTP mirrors under http://www.openssl.org/source/mirror.html): o http://www.openssl.org/source/ o ftp://ftp.openssl.org/source/ [1] OpenSSL comes in the form of two distributions this time. The reasons for this is that we want to deploy the external crypto device support but don't want to have it part of the normal distribution just yet. The distribution containing the external crypto device support is popularly called engine, and is considered experimental. It's been fairly well tested on Unix and flavors thereof. If run on a system with no external crypto device, it will work just like the normal distribution. The distribution file names are: o openssl-0.9.6e.tar.gz [normal] o openssl-engine-0.9.6e.tar.gz [engine] Yours, The OpenSSL Project Team... Mark J. Cox Ben Laurie Andy Polyakoff Ralf S. Engelschall Richard Levitte Geoff Thorpe Dr. Stephen Henson Bodo Möller Lutz JänickeUlf Möller -- Lutz Jaenicke [EMAIL PROTECTED] OpenSSL Project http://www.openssl.org/~jaenicke/ - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
[Announce] OpenSSL 0.9.7-beta3 (Security)
The third beta release of OpenSSL 0.9.7 is now available from the
OpenSSL FTP site URL: ftp://ftp.openssl.org/source/. Quite a lot
of code changed between the 0.9.6 release and the 0.9.7 release, so
a series of 3 or 4 beta releases is planned before the final release.
SECURITY INFORMATION:
o Several security fixes were newly introduced to OpenSSL 0.9.6e,
see OpenSSL Security Advisory [30 July 2002].
o OpenSSL 0.9.7-beta3 is the first 0.9.7-beta release containing these
fixes. Users of older beta versions or snapshots are urged to
upgrade to 0.9.7-beta3.
To make sure that it will work correctly, please test this version
(especially on less common platforms), and report any problems to
[EMAIL PROTECTED].
Application developers that use OpenSSL to provide cryptographic
routines or SSL/TLS support are kindly requested to test their
software against this new release to make sure that necessary adaptions
can be made.
Changes between 0.9.6x and 0.9.7 include:
o New library section OCSP.
o Complete rewrite of ASN1 code.
o CRL checking in verify code and openssl utility.
o Extension copying in 'ca' utility.
o Flexible display options in 'ca' utility.
o Provisional support for international characters with UTF8.
o Support for external crypto devices ('engine') is no longer
a separate distribution.
o New elliptic curve library section.
o New AES (Rijndael) library section.
o Change DES API to clean up the namespace (some applications link also
against libdes providing similar functions having the same name).
Provide macros for backward compatibility (will be removed in the
future).
o Unifiy handling of cryptographic algorithms (software and
engine) to be available via EVP routines for asymmetric and
symmetric ciphers.
o NCONF: new configuration handling routines.
o Change API to use more 'const' modifiers to improve error checking
and help optimizers.
o Finally remove references to RSAref.
o Reworked parts of the BIGNUM code.
o Support for new engines: Broadcom ubsec, Accelerated Encryption
Processing, IBM 4758.
o Extended and corrected OID (object identifier) table.
o PRNG: query at more locations for a random device, automatic query for
EGD style random sources at several locations.
o SSL/TLS: allow optional cipher choice according to server's preference.
o SSL/TLS: allow server to explicitly set new session ids.
o SSL/TLS: support Kerberos cipher suites (RFC2712).
o SSL/TLS: allow more precise control of renegotiations and sessions.
o SSL/TLS: add callback to retrieve SSL/TLS messages.
o SSL/TLS: add draft AES ciphersuites (disabled unless explicitly requested).
--
Lutz Jaenicke [EMAIL PROTECTED]
OpenSSL Project http://www.openssl.org/~jaenicke/
-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
