[cryptography] Mixing RdRand with other CPU-based entropy sources?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Aloha! Here is a question: If we (barely) trust RdRand enough to use it as an entropy source in combination with another source to feed our RNG - would it be wise to use another CPU-based entropy source such ad Haveged [1], DakaRand [2], Jytter [3] or the CPU Jitter Random Number Generator [3] by Stephan Müller? Or should the second one alway be a CPU-external source? A tengential question - is running these entropy sources ([1]..[2]) in parallel a good idea? [1] http://www.issihosts.com/haveged/ [2] http://dankaminsky.com/2012/08/15/dakarand/ [3] http://jytter.blogspot.se/ [4] http://www.chronox.de/ - -- Med vänlig hälsning, Yours Joachim Strömbergson - Alltid i harmonisk svängning. -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlKyq/cACgkQZoPr8HT30QGALACeJhV2LbPEpMHQQl0GteZEVNmq kVYAn3YGrGKTgUgzUSlB8exFvbCMJDI3 =qTBy -END PGP SIGNATURE- ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Mixing RdRand with other CPU-based entropy sources?
It's always a good idea to use several entropy sources and cryptographically mix their outputs into your pool. They won't reduce your total entropy either way, any predictable sources will only be adding less entropy than promised. - Sent from my phone Den 19 dec 2013 09:19 skrev Joachim Strömbergson joac...@strombergson.com : -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Aloha! Here is a question: If we (barely) trust RdRand enough to use it as an entropy source in combination with another source to feed our RNG - would it be wise to use another CPU-based entropy source such ad Haveged [1], DakaRand [2], Jytter [3] or the CPU Jitter Random Number Generator [3] by Stephan Müller? Or should the second one alway be a CPU-external source? A tengential question - is running these entropy sources ([1]..[2]) in parallel a good idea? [1] http://www.issihosts.com/haveged/ [2] http://dankaminsky.com/2012/08/15/dakarand/ [3] http://jytter.blogspot.se/ [4] http://www.chronox.de/ - -- Med vänlig hälsning, Yours Joachim Strömbergson - Alltid i harmonisk svängning. -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlKyq/cACgkQZoPr8HT30QGALACeJhV2LbPEpMHQQl0GteZEVNmq kVYAn3YGrGKTgUgzUSlB8exFvbCMJDI3 =qTBy -END PGP SIGNATURE- ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Mixing RdRand with other CPU-based entropy sources?
Am Donnerstag, 19. Dezember 2013, 09:58:06 schrieb Natanael: Hi Natanael, It's always a good idea to use several entropy sources and cryptographically mix their outputs into your pool. They won't reduce your total entropy either way, any predictable sources will only be adding less entropy than promised. I would not concur with this statement, if the entropy collection process implies or heuristicially estimates some value of entropy associated with the incoming information. Assume you have two noise sources which draw more or less from the same phenomenon (like Haveged and my proposed Jitter RNG which both use CPU execution time variations), which independent of each other would produce a bit stream with some entropy X and Y. Now, you have a collection process which draws from both noise sources at more or less the same time, as a baseline (i.e. unless you can prove otherwise) you must assume that there are some dependencies / correlations between these two bit streams. That means, your entropy collector cannot assume that the two bit streams have the combined entropy of X + Y, but that combined entropy is expected to be less as a baseline (i.e. unless you have a rationale why you still have an independence). That said, using the CPU execution time variations as a noise source, all my research showed that each measurement is independent of the previous measurement. That said, even two noise sources running in parallel (which means that they never truly execute in parallel on the same CPU) are always independent. So, the use of two different implementations drawing from the CPU execution time variations should be ok. You clearly see that particular problem with /dev/random and the newly introduced fast_pool. The noise sources for HID and block devices also always generate interrupts. Now, it is important that the interrupt noise collection function is implemented in a way that breaks its dependency/correlation to the other noise sources. That is (hopefully, but I have not seen any analysis yet) achieved with the fast_pool that collects and mixes at least 64 interrupts before mixing its state into the input_pool. Furthermore, you see that also in the fact that any mix of fast_pool into input_pool is assumed to only provide 1 bit of entropy. Ciao Stephan ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] NIST Randomness Beacon
After all that discussion of the randomness beacon, it belatedly occurs to me to ask if anyone has ever applied, even for fun, any of the various tests for randomness to the transmissions from the various shortwave numbers stations. http://en.wikipedia.org/wiki/Numbers_station --dan ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
