Re: entropy depletion (was: SSL/TLS passive sniffing)
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Enzo Michelangeli Sent: Tuesday, January 04, 2005 7:50 PM This entropy depletion issue keeps coming up every now and then, but I still don't understand how it is supposed to happen. If the PRNG uses a really non-invertible algorithm (or one invertible only with intractable complexity), its output gives no insight whatsoever on its internal state. I see much misunderstanding of entropy depletion and many misstatements because of it. It is true you don't know what the internal state is but the number of possible internal states tends to reduce with every update of the internal state. See Random Mapping Statistics by Philippe Flajolet and Andrew M. Odlyzko (Proceedings of the workshop on the theory and application of cryptographic techniques on Advances in cryptology, Houthalen, Belgium, Pages: 329 - 354, year 1990) for a thorough discussion. The jist is that a well behaved state update function for a PRNG will have one very long cycle. This cycle will be shorter than the number of possible values that the state can hold. States not on the cycle are on branches of states that eventually land on the cycle. Flajolet and Odlyzko go on to show that the expected cycle length for a 1000 bit state will be around 2^500 iterations. So, you start your PRNG by filling the state with 1000 bits of real entropy. You have 2^1000 possible states. You use your PRNG and update the state. Now, there are a certain number of states that the PRNG cannot be in. After one state update, the PRNG cannot be in the states at the ends of the chains of states branched off from the aforementioned cycle. This means that, after one state update, you have slightly less than 1000 bits of entropy. When you update the state again, you now have more states that the PRNG cannot be in, thus reducing your entropy again. Every time you use your PRNG, you reduce your entropy in this way and you keep on doing so in an asymptotic way until, after many many iterations, you are close enough to 500 bits that you don't care anymore. In the real world, our PRNG state update functions are complex enough that we don't know if they are well behaved. Nobody knows how many cycles exist in a PRNG state update function using, for example, SHA-1. You run your PRNG long enough and you may actually hit a state that, when updated, maps onto itself. When this occurs your PRNG will start producing the same bits over and over again. It would be worse if you hit a cycle of 10,000 or so because you may never realize it. I don't know of any work on how not-so well behaved PRNG state update function lose entropy. I figure the state update functions we as a community use in what we consider to be well designed PRNGs probably have multiple long cycles and maybe a few scary short cycles that are so unlikely that nobody has hit them. I don't even know what multiple cycles means for entropy. Because of the lack of knowledge, cryptographic PRNGs have more state than they probably need just to assure enough entropy - at least that is one thing I look for when looking at cryptographic PRNGs. -Michael Heyman - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: Your source code, for sale
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Finney, Hal (CR) [SNIP discussion on ripping cash] The problem is that if the source code you are purchasing is bogus, or if the other side doesn't come through, you're screwed because you've lost the value of the torn cash. The other side doesn't gain anything by this fraud, but they harm you, and if they are malicious that might be enough. Quick fix for seller incentive: the seller rips some amount of their own cash in such a way that they cannot recover it unless the buyer provides the remainder of the buyer's ripped cash. -Michael Heyman - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: dual-use digital signature [EMAIL PROTECTED]
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Peter Gutmann Sent: Saturday, July 24, 2004 9:07 PM [SNIP] A depressing number of CAs generate the private key themselves and mail out to the client. Replies to this talked about business cases to have control of the private key not only under the identity upheld by the certificate. I would like to point out that whether or not a CA actually has the private key is largely immaterial because it always _can_ have the private key - a CA can always create a certificate for Alice whether or not Alice provided a public key. Whether or not Alice has complete control over her private key makes no difference to Bob. If the CA works properly, Bob and Alice can have a authenticated and private communications. If the CA is compromised (or inherently malicious), Bob will think he is having authenticated and private communications with Alice but will actually have it with an agent of the CA's choosing. This is the way the system was designed. Bob trusts the CA to provide for authenticated and private communications with Alice. 2 centsIn the business cases pointed out where it is good that the multiple parties hold the private key, I feel the certificate should indicate that there are multiple parties so that Bob can realize he is having authenticated and private communications with Alice _and_ Alice's employer. X.509 does not provide a standard way to encode multiple subjects./2 cents -Michael Heyman - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: Question on the state of the security industry
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ian Grigg Sent: Wednesday, June 30, 2004 6:49 AM Here's my question - is anyone in the security field of any sort of repute being asked about phishing, consulted about solutions, contracted to build? Anything? McAfee Research has proposed solutions to some of their larger customers and has an anti-phishing white paper: http://www.networkassociates.com/us/_tier2/products/_media/mcafee/wp_an tiphishing.pdf Press release: http://www.networkassociates.com/us/about/press/mcafee_enterprise/2004/ 20040315_094318.htm -Michael Heyman - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
FYI: 3 qubits encrypted
Apparently, it is as hard (or harder) to produce random qubits as random bits. There are some sentences in this article that don't make sense so I am guessing the author doesn't really understand the subject. From: http://www.trnmag.com/Stories/2004/011404/Quantum_dice_debut_011404.htm l ...random operators would be useful for quantum communications tasks like encryption, said Emerson. The idea is to randomize a specific configuration of qubits containing the message, and then transmit this randomized state, he said...The researchers tested the method on a three-qubit prototype liquid nuclear magnetic resonance (NMR) quantum computer. -Michael Heyman - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: quantum hype
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Dave Howe Peter Fairbrother may well be in possession of a break for the QC hard problem - his last post stated there was a way to clone photons with high accuracy in retention of their polarization [SNIP] Not a break at all. The physical limit for cloning is 5/6ths of the bits will clone true. Alice need only send 6 bits for every one bit desired to assure Eve has zero information. For a 256-bit key negotiation, Alice sends 1536 bits and hashes it down to 256 bits for the key. -Michael Heyman - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
