Re: [cryptography] random number generator
On 2014-11-22 03:01, d...@deadhat.com wrote: Rather than me listing names, why not just let it rip and run your own randomness tests on it? Because that won't tell me if you are performing entropy extraction. Jytter assumes an x86 machine with multiple asynchronous clocks and nondeterministic physical devices. This is not a safe assumption. Linux assumes entropy in interrupt timing and this was the result https://factorable.net/weakkeys12.extended.pdf. This falls under the third model of source in my earlier email. Your extractor might look simple, but your system is anything but simple and entropy extracted from rdtsc and interrupts amounts to squish. Looking at the timing on your system and saying it looks random to me does not cut it. Portable code has to have a way to know system timing is random on every platform it runs on. The above paper shows that it isn't. Jytter does something neat but the broad claims you are making and the broader claims the Jytter web site makes do not pass the sniff test. By and large, usually, interrupt timing is somewhat random, and, if not random, unknowable to the adversary. But this is not guaranteed, and likely to be untrue if you have several identical systems, such as routers, which need randomness at boot up. All your routers are likely to wind up generating keys from a rather small set of possible keys. It is extremely easy to get true randomness, or at least randomness unknowable to the adversary. It is extremely hard to get true randomness reliably in an unknown or arbitrary system. You really have to tinker your entropy collection to your situation, to your particular system. 128 bits of entropy is enough for forever, so the big problem is start up. A long running system is bound to have plenty of entropy - anything more than 128 is plenty. So if it writes a unique secret key to each boot up image, and each boot up has access to a good approximation to the current time, we are golden. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] random number generator
On 2014-11-22 06:31, d...@deadhat.com wrote: OK, if you think my Jytter TRNG is weak, I did not say it was weak. I said Jytter (and any other algorithm) is deterministic when run on an entropy free platform. This is a simple fact. All platforms have entropy. If they boot from a physical disk, microturbulence creates true randomness in data availability. If they are on the net, packets arrive at random times with random delays. If they are using wifi, not only are packets arriving at random times, but are affected by random noise. The question is, does all this entropy show up in Jytter? I rather think it does. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] random number generator
On Sat, Nov 22, 2014 at 08:13:31PM +1000, James A. Donald wrote: The question is, does all this entropy show up in Jytter? I rather think it does. the question is: is your adversary nature, or human nature? -- otr fp: https://www.ctrlc.hu/~stef/otr.txt ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] random number generator
All, in the interest of clarity: 1. Let's do the math. Let's assume that we have a really dumb entropy extractor which waits around for 128 interrupts to occur. It just sits in a loop sampling the timestamp until this criterion is satisfied. It saves all these time stamps to a big chunk of memory. Suppose, further, that this system is so very quiescent (but not _perfectly_ so) that the timing of each interrupt arrives predictably, but for an error of 1 CPU clock tick, at random. So for instance the time between interrupts is either 10 or 11 ticks. Thus 128 interrupts gives us 128 bits of entropy. In other words, taken in the aggregate, the timestamp stream will be worth 128 bits of entropy. But of course we need to produce a short output in the interest of practicality, so let's say we hash this long timestamp stream through a cryptographically wonderful PRNG, yielding 128 bits of noise. Applying the reflexive density constant, we expect that (1-1/e) or so of the 2^128 _theoretically_ possible hashes will be _actually_ possible. So, roughly speaking, we drop down to 127 bits of entropy. Next, adjust for the fact that maybe our PRNG ain't so wonderful after all because it has unseen biases, and maybe we're down to 120 bits. Whatever. We still have a freaking strong random number at the end of the day -- all from a very coldbootish system. 2. Empirically, it seems to me that, historically, entropy extractors have paid none too careful attention to hash quality. So for instance, we end up doing a commutative operation on the aforementioned timestamp stream. In that case, the _sum_ would be uncertain by something like +/-11 (root 128). So then we somehow manage to get this code into general circulation, and no one one looks at it until stuff starts getting hacked. Finally, we end up with a paper like in DJ's link, which makes some of us assume that coldbootishness is too blame for poor entropy, when in fact it was the bias of the timestamp stream hash. Jytter's hash, in particular, is noncommutative and reasonably fair; there are vastly better hashes which could be implemented, but not without touching memory in such a way as to risk autopseudorandomness (i.e. confusing the TRNG's own pseudorandom timing with true background system entropy). 3. world's leading experts: Stu has spoken to way more people than I have about Jytter. But most of his conversations are covered under NDA. I only met one of these experts personally, who said he had run the gammot of statistical tests on Jytter and couldn't find a weakness. Then again, he didn't do the biasing trick that I previously suggested. I would recommend that everyone assume that no one has ever tested Jytter at all, so therefore you need to test it yourself and demonstrate how weak it is. Russell Leidich On Sat, Nov 22, 2014 at 10:13 AM, James A. Donald jam...@echeque.com wrote: On 2014-11-22 06:31, d...@deadhat.com wrote: OK, if you think my Jytter TRNG is weak, I did not say it was weak. I said Jytter (and any other algorithm) is deterministic when run on an entropy free platform. This is a simple fact. All platforms have entropy. If they boot from a physical disk, microturbulence creates true randomness in data availability. If they are on the net, packets arrive at random times with random delays. If they are using wifi, not only are packets arriving at random times, but are affected by random noise. The question is, does all this entropy show up in Jytter? I rather think it does. ___ 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] random number generator
On 11/22/2014 4:08 AM, James A. Donald wrote: On 2014-11-22 03:01, d...@deadhat.com wrote: Rather than me listing names, why not just let it rip and run your own randomness tests on it? Because that won't tell me if you are performing entropy extraction. Jytter assumes an x86 machine with multiple asynchronous clocks and nondeterministic physical devices. This is not a safe assumption. Linux assumes entropy in interrupt timing and this was the result https://factorable.net/weakkeys12.extended.pdf. This falls under the third model of source in my earlier email. Your extractor might look simple, but your system is anything but simple and entropy extracted from rdtsc and interrupts amounts to squish. Looking at the timing on your system and saying it looks random to me does not cut it. Portable code has to have a way to know system timing is random on every platform it runs on. The above paper shows that it isn't. Jytter does something neat but the broad claims you are making and the broader claims the Jytter web site makes do not pass the sniff test. By and large, usually, interrupt timing is somewhat random, and, if not random, unknowable to the adversary. But this is not guaranteed, and likely to be untrue if you have several identical systems, such as routers, which need randomness at boot up. All your routers are likely to wind up generating keys from a rather small set of possible keys. It is extremely easy to get true randomness, or at least randomness unknowable to the adversary. It is extremely hard to get true randomness reliably in an unknown or arbitrary system. You really have to tinker your entropy collection to your situation, to your particular system. 128 bits of entropy is enough for forever, so the big problem is start up. A long running system is bound to have plenty of entropy - anything more than 128 is plenty. So if it writes a unique secret key to each boot up image, and each boot up has access to a good approximation to the current time, we are golden. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography If this was already brought up I apologize, but how about looking into the NIST Randomness Beacon? -- Kevin --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] random number generator
On Sat, Nov 22, 2014 at 11:58 PM, Russell Leidich pke...@gmail.com wrote: 1. Let's do the math. Let's assume that we have a really dumb entropy extractor ... that the timing of each interrupt arrives predictably, but for an error of 1 CPU clock tick, at random. ... 128 interrupts gives us 128 bits of entropy. ... ... let's say we hash this long timestamp stream through a cryptographically wonderful PRNG, yielding 128 bits of noise. Applying the reflexive density constant, we expect that (1-1/e) or so of the 2^128 _theoretically_ possible hashes will be _actually_ possible. So, roughly speaking, we drop down to 127 bits of entropy. Next, adjust for the fact that maybe our PRNG ain't so wonderful after all because it has unseen biases, and maybe we're down to 120 bits. Whatever. We still have a freaking strong random number at the end of the day -- all from a very coldbootish system. John Denker's Turbid paper treats the math for this in some detail with explicit, fairly weak, assumptions about properties of the hash. It shows that, given a reliable figure for minimum input entropy per sample (in Turbid, proven, but you could use an estimate get a weaker result) you can get within epsilon of full output entropy by using slightly more inputs. in your case, hash 128+N samples to get, say, 127.99 bits of entropy per hash output. N is small, under 20 I think. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] random number generator
in your case, hash 128+N samples to get, say, 127.99 bits of entropy per hash output. N is small, under 20 I think. Yeah this certainly inspiring with respect to milking decent entropy from coldbootish environments. If we assume the use of a good hash, then the problem reduces to one of asking how much entropy a sample is worth. But this is where Pandora's box opens up: modern systems -- even mobile phones -- are so complicated that autopseudorandomness can look very convincingly like a TRNG. For instance, we could have predictable cache stalls, bus stalls, pipeline stalls, etc. which interact like a decent PRNG in order to render the appearance of physical entropy even in the absence of interrupts. But we could still end up with a painfully narrow set of possible outputs, which would still be too large to perceive. For instance, our 128-bit random number might be worth only 70 bits, so we likely wouldn't detect that weakness until it comes back to bite us in the future. Massively parallel testing is the way to go. While we can't hope to cover any decent fraction of a 128-bit space, we _can_ smell the quality of a TRNG from the LMICBR test with rootish numbers of samples relative to the whole space: http://jytter.blogspot.com/2012/08/characterization.html Russell Leidich On Sat, Nov 22, 2014 at 6:46 PM, Sandy Harris sandyinch...@gmail.com wrote: On Sat, Nov 22, 2014 at 11:58 PM, Russell Leidich pke...@gmail.com wrote: 1. Let's do the math. Let's assume that we have a really dumb entropy extractor ... that the timing of each interrupt arrives predictably, but for an error of 1 CPU clock tick, at random. ... 128 interrupts gives us 128 bits of entropy. ... ... let's say we hash this long timestamp stream through a cryptographically wonderful PRNG, yielding 128 bits of noise. Applying the reflexive density constant, we expect that (1-1/e) or so of the 2^128 _theoretically_ possible hashes will be _actually_ possible. So, roughly speaking, we drop down to 127 bits of entropy. Next, adjust for the fact that maybe our PRNG ain't so wonderful after all because it has unseen biases, and maybe we're down to 120 bits. Whatever. We still have a freaking strong random number at the end of the day -- all from a very coldbootish system. John Denker's Turbid paper treats the math for this in some detail with explicit, fairly weak, assumptions about properties of the hash. It shows that, given a reliable figure for minimum input entropy per sample (in Turbid, proven, but you could use an estimate get a weaker result) you can get within epsilon of full output entropy by using slightly more inputs. in your case, hash 128+N samples to get, say, 127.99 bits of entropy per hash output. N is small, under 20 I think. ___ 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] random number generator
On 2014-11-23 09:47, Russell Leidich wrote: in your case, hash 128+N samples to get, say, 127.99 bits of entropy per hash output. N is small, under 20 I think. Yeah this certainly inspiring with respect to milking decent entropy from coldbootish environments. If we assume the use of a good hash, then the problem reduces to one of asking how much entropy a sample is worth. But this is where Pandora's box opens up: modern systems -- even mobile phones -- are so complicated that autopseudorandomness can look very convincingly like a TRNG. For instance, we could have predictable cache stalls, bus stalls, pipeline stalls, etc. which interact like a decent PRNG in order to render the appearance of physical entropy even in the absence of interrupts. But we could still end up with a painfully narrow set of possible outputs, which would still be too large to perceive. For instance, our 128-bit random number might be worth only 70 bits, so we likely wouldn't detect that weakness until it comes back to bite us in the future. If there is any true randomness in the system, autopseudorandomness will mix it with everything else, and so Jytter will collect it. But in coldboot system, there may well be very little true randomness. So, every boot image should have its own unique 128 or 256 bit secret unpredictable to an adversary. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] random number generator
Rather than me listing names, why not just let it rip and run your own randomness tests on it? Because that won't tell me if you are performing entropy extraction. Jytter assumes an x86 machine with multiple asynchronous clocks and nondeterministic physical devices. This is not a safe assumption. Linux assumes entropy in interrupt timing and this was the result https://factorable.net/weakkeys12.extended.pdf. This falls under the third model of source in my earlier email. Your extractor might look simple, but your system is anything but simple and entropy extracted from rdtsc and interrupts amounts to squish. Looking at the timing on your system and saying it looks random to me does not cut it. Portable code has to have a way to know system timing is random on every platform it runs on. The above paper shows that it isn't. Jytter does something neat but the broad claims you are making and the broader claims the Jytter web site makes do not pass the sniff test. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] random number generator
OK, if you think my Jytter TRNG is weak, then maybe you're right. Here is how someone can straightforwardly attempt to break it: do a WRMSR instruction to set the timestamp counter to some constant value immediately before running it. (Or, close enough, save the TSC value on entry to the function, and subtract it from the TSC after every RDTSC instruction.) This basically simulates the extreme case of coldbootness, where every machine in the world runs Jytter with the same starting TSC. Then show us what you find in terms of statistical bias in the 32-bit outputs. Yes, if you simulate Jytter, you can of course create any bias you want. The question is, is there a realistic cold boot scenario which would have bias to an extent which would endanger security? Perhaps... let's see the data. BTW that's a pretty sobering paper, although I don't immediately see the Jytter connection. Jytter doesn't naively read the timer N times or even wait for N interrupts or N milliseconds, then assume that it has enough entropy; nor does it depend on pseudorandomness to mask its would-be biases (although it does use some crude pseudorandomness techniques because it somehow has to hash the (very long) timestamp stream it observes into a 32-bit output). It looks for events which it regards as unique based the uniqueness of their durations. It's sensistive to the permutative order and the duration of such events, in addition to the timestamp stream itself. So you're correct in the sense that you can never be 100% sure that some platform out there isn't super-quiescent and therefore insecure with respect to timing-based entropy. But then, what would be better? A third-party hardware TRNG register that you can't trust? A quantum dot camera, which might be broken or worn out, which is connected across a bus that radiates frame data into the environment, and therefore might easily leak the entropy? A trusted platform module which has both of these weaknesses? If we could have an on-CPU TRNG register based on totally unbiased quantum switches or something like that, then great, but who has the xray and other equipment to verify that it's not just a simulation of said TRNG? And how portable is that, unless every chip manufacturer decides to implement it? Russell Leidich On Fri, Nov 21, 2014 at 5:01 PM, d...@deadhat.com wrote: Rather than me listing names, why not just let it rip and run your own randomness tests on it? Because that won't tell me if you are performing entropy extraction. Jytter assumes an x86 machine with multiple asynchronous clocks and nondeterministic physical devices. This is not a safe assumption. Linux assumes entropy in interrupt timing and this was the result https://factorable.net/weakkeys12.extended.pdf. This falls under the third model of source in my earlier email. Your extractor might look simple, but your system is anything but simple and entropy extracted from rdtsc and interrupts amounts to squish. Looking at the timing on your system and saying it looks random to me does not cut it. Portable code has to have a way to know system timing is random on every platform it runs on. The above paper shows that it isn't. Jytter does something neat but the broad claims you are making and the broader claims the Jytter web site makes do not pass the sniff test. ___ 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] random number generator
OK, if you think my Jytter TRNG is weak, I did not say it was weak. I said Jytter (and any other algorithm) is deterministic when run on an entropy free platform. This is a simple fact. By all meas design new and interesting ways to extract platform entropy, but condition your claims on that entropy being there. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] random number generator
For the record, I agree with both of those paragraphs. If I gave the impression somewhere that running Jytter in the absence of physical platform entropy would still make a good TRNG, then I was definitely off my rocker at the time. On Fri, Nov 21, 2014 at 8:31 PM, d...@deadhat.com wrote: OK, if you think my Jytter TRNG is weak, I did not say it was weak. I said Jytter (and any other algorithm) is deterministic when run on an entropy free platform. This is a simple fact. By all meas design new and interesting ways to extract platform entropy, but condition your claims on that entropy being there. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] random number generator
There's an implementation of Fortuna, which is a computationally secure PRNG, in PyCrypto: https://github.com/dlitz/pycrypto/tree/master/lib/Crypto/Random/Fortuna Unfortunately, gathering entropy is rather non-generic; otherwise decentish operating systems get this wrong. The various BSDs' source is probably the best place to start poking around, if you really want. -dlg On Wed, Nov 19, 2014 at 3:59 AM Givon Zirkind givo...@gmx.com wrote: Plz excuse if inappropriate. Does anyone know of a decent (as in really random) open source random generator? Preferably in PHP or C/C++? Thanks. ___ 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] random number generator
On Fri, 21 Nov 2014, d...@deadhat.com wrote: OK, if you think my Jytter TRNG is weak, I did not say it was weak. I said Jytter (and any other algorithm) is deterministic when run on an entropy free platform. This is a simple fact. By all meas design new and interesting ways to extract platform entropy, but condition your claims on that entropy being there. Indeed, and I'm still waiting for this claim to be vindicated: ``Jytter does all of this and has been validated and proven by the worlds leading random number experts'' The OP shouldn't have any hesitation in naming these worlds [sic] leading random number experts, nor in providing pointers to such proofs. As a dabbler in crypto and with a mathematical background, I really would like to learn from these experts. -- Dave Horsfall DTM (VK2KFU) Bliss is a MacBook with a FreeBSD server. http://www.horsfall.org/spam.html (and check the home page whilst you're there) ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] random number generator
http://burtleburtle.net/bob/rand/isaac.html Isaac works. On Wed, Nov 19, 2014 at 3:54 AM, Givon Zirkind givo...@gmx.com wrote: Plz excuse if inappropriate. Does anyone know of a decent (as in really random) open source random generator? Preferably in PHP or C/C++? Thanks. ___ 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] random number generator
Plz excuse if inappropriate. Does anyone know of a decent (as in really random) open source random generator? Preferably in PHP or C/C++? Thanks. Getting back to the initial question, the answer I think is 'no'. You haven't expressed clearly what you want from this RNG, but you're asking in a crypto forum and you said 'really random', which I take to mean you want something that is suitable for crypto applications, like generating keys, feeding key search algorithms, random IVs, nonces and all the other fun stuff we do. I take it to mean you are not just looking for a CS-PRNG. For this you need an algorithm that A) Measures the physical world in a way that translates quantum uncertainty into digital bits with a well defined min-entropy. and B) Cryptographically processes these numbers such that they are unpredictable (in specific ways) and indistinguishable from random. and maybe C) Uses that to seed a CS-PRNG to give you lots of numbers with low overhead and guaranteed computational bounds on the adversary. An algorithm in C, C++ or PHP in isolation cannot offer the necessary properties because those languages can only be used to express deterministic behaviors. The hardware you run on must provide the source of non determinism. This could be by sampling local physical events that happen to be entropic or from a local entropy source circuit, or by reaching out over the internet to other sources (this has issues) or a combination of all three. In a pinch you can look at the whole system as assume entropy is leaking in through its pores, and then sample the system state in complicated ways. But this approach is tightly bound to the chosen system. It is not portable. So knowing this, you can know what to go looking for. 1) A physical source of entropy - Check your hardware specs 2) An entropy extractor - http://en.wikipedia.org/wiki/Randomness_extractor 3) A CS-PRNG - http://en.wikipedia.org/wiki/Cryptographically_secure_pseudorandom_number_generator Code for 2 and 3 are spread all over the internet. For 1, buy one, buy a computer that has one or get out your soldering iron. Bill Cox has been discussing his interesting design for such a thing right here. DJ ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] random number generator
Jytter does all of this and has been validated and proven by the worlds leading random number experts. Its been validated as a TRNG (not a PRNG) that operates in userspace. And its only 11 assembly language instructions. Sent from my iPhone On 21 Nov, 2014, at 1:41, d...@deadhat.com wrote: Plz excuse if inappropriate. Does anyone know of a decent (as in really random) open source random generator? Preferably in PHP or C/C++? Thanks. Getting back to the initial question, the answer I think is 'no'. You haven't expressed clearly what you want from this RNG, but you're asking in a crypto forum and you said 'really random', which I take to mean you want something that is suitable for crypto applications, like generating keys, feeding key search algorithms, random IVs, nonces and all the other fun stuff we do. I take it to mean you are not just looking for a CS-PRNG. For this you need an algorithm that A) Measures the physical world in a way that translates quantum uncertainty into digital bits with a well defined min-entropy. and B) Cryptographically processes these numbers such that they are unpredictable (in specific ways) and indistinguishable from random. and maybe C) Uses that to seed a CS-PRNG to give you lots of numbers with low overhead and guaranteed computational bounds on the adversary. An algorithm in C, C++ or PHP in isolation cannot offer the necessary properties because those languages can only be used to express deterministic behaviors. The hardware you run on must provide the source of non determinism. This could be by sampling local physical events that happen to be entropic or from a local entropy source circuit, or by reaching out over the internet to other sources (this has issues) or a combination of all three. In a pinch you can look at the whole system as assume entropy is leaking in through its pores, and then sample the system state in complicated ways. But this approach is tightly bound to the chosen system. It is not portable. So knowing this, you can know what to go looking for. 1) A physical source of entropy - Check your hardware specs 2) An entropy extractor - http://en.wikipedia.org/wiki/Randomness_extractor 3) A CS-PRNG - http://en.wikipedia.org/wiki/Cryptographically_secure_pseudorandom_number_generator Code for 2 and 3 are spread all over the internet. For 1, buy one, buy a computer that has one or get out your soldering iron. Bill Cox has been discussing his interesting design for such a thing right here. DJ ___ 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] random number generator
On Fri, 21 Nov 2014, Stu wrote: Jytter does all of this and has been validated and proven by the worlds leading random number experts. Its been validated as a TRNG (not a PRNG) that operates in userspace. And its only 11 assembly language instructions. And just who would these experts be, exactly? -- Dave Horsfall DTM (VK2KFU) Bliss is a MacBook with a FreeBSD server. http://www.horsfall.org/spam.html (and check the home page whilst you're there) ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] random number generator
Well I don't want to name drop on the basis that no-one will really care, and if anyone does, I don't want to risk them getting spammed. You can google it. For what it's worth, I have no vested interest in Jytter, I don't stand to make any money from it (it's open source duh), or fame as I had nothing to do with its creation. I just know that in my professional career with various defence agencies, TRNG's were a big thing, and this one smashed every test, be it die-hard, reflexive density, blah blah. And I've passed it to many reputable companies and universities who now use it. It can be slow, but it kicks ass. Rather than me listing names, why not just let it rip and run your own randomness tests on it? As with any TRNG, it will draft and deviate to the edges of Die-Hards etc etc and come back to the centre, as you'd expect... but judge for yourself. If you still think it sucks, go ahead and use get_random_number() or whatever, but here we've yet to find something better if only it was faster! :) Plus, yesterday it produced a 7, and we all know 7 is random. stu On Fri, Nov 21, 2014 at 10:10 AM, Dave Horsfall d...@horsfall.org wrote: On Fri, 21 Nov 2014, Stu wrote: Jytter does all of this and has been validated and proven by the worlds leading random number experts. Its been validated as a TRNG (not a PRNG) that operates in userspace. And its only 11 assembly language instructions. And just who would these experts be, exactly? -- Dave Horsfall DTM (VK2KFU) Bliss is a MacBook with a FreeBSD server. http://www.horsfall.org/spam.html (and check the home page whilst you're there) ___ 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
