Re: [cryptography] Enranda: 4MB/s Userspace TRNG
I was actually surprised how uncompressible the timedelta stream does not make any sense. the result of a complex recursive chaotic calculation always appears uncompressible, unless you know the proper underlying model. trying to compress it only puts an upper limit on entropy, but never an estimation, let alone lower bound. Exactly so. Because entropy is measured over counterfactuals, it can never be known from observation, only from theory. Which is sort of weird, seeing as there is something observable about the fact that things run down and fall apart. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Enranda: 4MB/s Userspace TRNG
On Fri, May 29, 2015 at 12:25 AM, Russell Leidich pke...@gmail.com wrote: I'm the first to admit that I don't understand where the entropy is coming from. knowing where the entropy is coming from and knowing the amount of entropy is the same thing. it is because we don't have a way to measure entropy. we can only infer the amount from theoretical models. the output of RC4 (or any other stream cipher) appears totally random for any practical analysis if you don't know the key. therefore this sentence: I was actually surprised how uncompressible the timedelta stream does not make any sense. the result of a complex recursive chaotic calculation always appears uncompressible, unless you know the proper underlying model. trying to compress it only puts an upper limit on entropy, but never an estimation, let alone lower bound. 4MB/s is the entropy rate from the internal perspective of Enranda. But in any event, for the record, I agree with Krisztian Pinter's statement B if you replace CPU with complete computer system. can we expect some corrections on the website then? ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Enranda: 4MB/s Userspace TRNG
I see a few problems with that. First 128 bits of entropy is a lot to ask from a human and you'll end up with a string of however many 'a' character you asked for. You're right, but there's nothing that can be done to help someone who enters cat as his password, either. I personally don't think you can blame any of that on the user : how should he know or care that it is important ? Because you print text in bold letters explaining this. Not reading STOP signs can also cause catastrophic problems, but that's not the fault of the highway administration. Where is he supposed to find those 100+ (that seems low actually) digits. passwords have thought us that when users don't care we end up with extremely low variability Maybe mouse movement is a better source. At least, the installer can verify how far you move, back and forth, and how quickly, and thereby conclude with confidence that your neurology is operating outside the envelope in which any human could possibly control the cursor with pixel precision, to the tune of 128 bits. And you explain this to the user, anyway. If they push a button on their mouse to fake the movement so they don't need to move their wrist, it's their own fault. Another issue is in a lot of cases (think cloud/virtualization) OS are setup without human interaction. True. I would just seed the child from the parent CSPRNG, so the chain of security authority remains intact. Last thing is you can't completely rely on a well seeded CSPRNG forever : you need to be able to reseed it in case of compromise and since you won't necessarily know when the compromise happened it's good practice to reseed from time to time No one would disagree with this. But if good security practices are in place, then I would expect this reseeding interval to be on the order of days, at least. That's well within the realm of shake the mouse for a few seconds. Russell Leidich On Fri, May 29, 2015 at 2:55 PM, Alexandre Anzala-Yamajako anzal...@gmail.com wrote: I still think it's important that TRNGs be practical in real usage contexts. As mundane as it sounds, perhaps the safest practice is just to ask the user to enter 50 random digits when they install the OS (or shake the mouse or whatever). At some point (100 digits?), even an uncreative person is going to produce enough entropy to be worth 128+ bits. From that point on, it's all CSPRNG. That way, we don't need to worry about timedelta predictability or how to securely acquire a new USB randomness device when it gets lost somewhere far away from the IT department. I see a few problems with that. First 128 bits of entropy is a lot to ask from a human and you'll end up with a string of however many 'a' character you asked for. I personally don't think you can blame any of that on the user : how should he know or care that it is important ? Where is he supposed to find those 100+ (that seems low actually) digits. passwords have thought us that when users don't care we end up with extremely low variability Another issue is in a lot of cases (think cloud/virtualization) OS are setup without human interaction. Last thing is you can't completely rely on a well seeded CSPRNG forever : you need to be able to reseed it in case of compromise and since you won't necessarily know when the compromise happened it's good practice to reseed from time to time -- Alexandre Anzala-Yamajako ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Enranda: 4MB/s Userspace TRNG
Things do indeed seem to run down and fall apart, although it's possible to encounter local maxima in the entropy of discrete systems which are not global maxima (depending on how you define entropy). So it ain't totally straight downhill. I guess that bodes well for the health supplement industry. As I said before, when I say entropy, I'm speaking from the perspective of the observer, i.e. that which he does not know. When you say it, you're speaking from the underlying physical perspective, assuming an observer who also knows as much about the underlying physical situation as he could possibly know, ahead of time. So when I refer to compressibility, I mean from the former perspective. But obviously you're correct in that, if I had a perfect simulation of my system, I would see less entropy down to some lower bound that represents unpredictable physical events. I already updated the website yesterday. I figured the best thing to do, rather than to resummarize everything that's been said here and risk mischaracterizing it, is just to put a note about the criticisms on the front page, and link to this thread. Which I did. I still think it's important that TRNGs be practical in real usage contexts. As mundane as it sounds, perhaps the safest practice is just to ask the user to enter 50 random digits when they install the OS (or shake the mouse or whatever). At some point (100 digits?), even an uncreative person is going to produce enough entropy to be worth 128+ bits. From that point on, it's all CSPRNG. That way, we don't need to worry about timedelta predictability or how to securely acquire a new USB randomness device when it gets lost somewhere far away from the IT department. Russell Leidich On Fri, May 29, 2015 at 9:22 AM, Krisztián Pintér pinte...@gmail.com wrote: On Fri, May 29, 2015 at 12:25 AM, Russell Leidich pke...@gmail.com wrote: I'm the first to admit that I don't understand where the entropy is coming from. knowing where the entropy is coming from and knowing the amount of entropy is the same thing. it is because we don't have a way to measure entropy. we can only infer the amount from theoretical models. the output of RC4 (or any other stream cipher) appears totally random for any practical analysis if you don't know the key. therefore this sentence: I was actually surprised how uncompressible the timedelta stream does not make any sense. the result of a complex recursive chaotic calculation always appears uncompressible, unless you know the proper underlying model. trying to compress it only puts an upper limit on entropy, but never an estimation, let alone lower bound. 4MB/s is the entropy rate from the internal perspective of Enranda. But in any event, for the record, I agree with Krisztian Pinter's statement B if you replace CPU with complete computer system. can we expect some corrections on the website then? ___ 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] Enranda: 4MB/s Userspace TRNG
On second thought, there is this particular case, wherein you would need internally generated entropy: 1. You have a cloud server which has been compromised. 2. You issue a remote reboot, with the firmware instructed to boot from the network. 3. In order to obtain the new OS image, the cloud server needs to do a key exchange with a machine controlled by a human sysadmin. 4. However, to guard against replay attacks of a previous key exchange (which could be used to reinstall the vulnerable OS), the child must create a nonce. It cannot do this, absent local entropy. So in this particular scenario, unless the sysadmin can somehow walk over to the cloud server, I think you are correct: local physical entropy is required. Russell Leidich On Fri, May 29, 2015 at 2:55 PM, Alexandre Anzala-Yamajako anzal...@gmail.com wrote: I still think it's important that TRNGs be practical in real usage contexts. As mundane as it sounds, perhaps the safest practice is just to ask the user to enter 50 random digits when they install the OS (or shake the mouse or whatever). At some point (100 digits?), even an uncreative person is going to produce enough entropy to be worth 128+ bits. From that point on, it's all CSPRNG. That way, we don't need to worry about timedelta predictability or how to securely acquire a new USB randomness device when it gets lost somewhere far away from the IT department. I see a few problems with that. First 128 bits of entropy is a lot to ask from a human and you'll end up with a string of however many 'a' character you asked for. I personally don't think you can blame any of that on the user : how should he know or care that it is important ? Where is he supposed to find those 100+ (that seems low actually) digits. passwords have thought us that when users don't care we end up with extremely low variability Another issue is in a lot of cases (think cloud/virtualization) OS are setup without human interaction. Last thing is you can't completely rely on a well seeded CSPRNG forever : you need to be able to reseed it in case of compromise and since you won't necessarily know when the compromise happened it's good practice to reseed from time to time -- Alexandre Anzala-Yamajako ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Enranda: 4MB/s Userspace TRNG
This reminds me of an issue that (at one time, I'm not current on it) was an issue with OpenSSL in virtual environments. When you restore a virtual machine snapshot, OpenSSL would maintain the entropy state from the snapshot. It apparently did not refresh it's userspace pool very often, so multiple VMs running the same snapshot would produce identical random numbers until OpenSSL refreshed from its entropy source. Yet another case of userspace PRNGs failing spectacularly. On Fri, May 29, 2015 at 10:50 AM, Russell Leidich pke...@gmail.com wrote: On second thought, there is this particular case, wherein you would need internally generated entropy: 1. You have a cloud server which has been compromised. 2. You issue a remote reboot, with the firmware instructed to boot from the network. 3. In order to obtain the new OS image, the cloud server needs to do a key exchange with a machine controlled by a human sysadmin. 4. However, to guard against replay attacks of a previous key exchange (which could be used to reinstall the vulnerable OS), the child must create a nonce. It cannot do this, absent local entropy. So in this particular scenario, unless the sysadmin can somehow walk over to the cloud server, I think you are correct: local physical entropy is required. Russell Leidich ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Enranda: 4MB/s Userspace TRNG
I still think it's important that TRNGs be practical in real usage contexts. As mundane as it sounds, perhaps the safest practice is just to ask the user to enter 50 random digits when they install the OS (or shake the mouse or whatever). At some point (100 digits?), even an uncreative person is going to produce enough entropy to be worth 128+ bits. From that point on, it's all CSPRNG. That way, we don't need to worry about timedelta predictability or how to securely acquire a new USB randomness device when it gets lost somewhere far away from the IT department. I see a few problems with that. First 128 bits of entropy is a lot to ask from a human and you'll end up with a string of however many 'a' character you asked for. I personally don't think you can blame any of that on the user : how should he know or care that it is important ? Where is he supposed to find those 100+ (that seems low actually) digits. passwords have thought us that when users don't care we end up with extremely low variability Another issue is in a lot of cases (think cloud/virtualization) OS are setup without human interaction. Last thing is you can't completely rely on a well seeded CSPRNG forever : you need to be able to reseed it in case of compromise and since you won't necessarily know when the compromise happened it's good practice to reseed from time to time -- Alexandre Anzala-Yamajako ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Enranda: 4MB/s Userspace TRNG
I'm the first to admit that I don't understand where the entropy is coming from. I was actually surprised how uncompressible the timedelta stream actually is (as shown by timedeltasave and timedeltaprofile, on my rather idle system). Perhaps more of it is from DMAs competing for main memory access, than cache transactions, for instance. In that case, the real underlying entropy could be well into the megabits (for instance, video, CPU, and main memory clocks competing with each other). Clearly James Donald is correct that busier systems are richer in entropy, and I agree that quantifying it is probably impossible, other than to offer some vague upper bounds implied by clock frequencies and cache size. 4MB/s is the entropy rate from the internal perspective of Enranda. But in any event, for the record, I agree with Krisztian Pinter's statement B if you replace CPU with complete computer system. Russell Leidich On Thu, May 28, 2015 at 8:04 AM, Krisztián Pintér pinte...@gmail.com wrote: On Thu, May 28, 2015 at 6:59 AM, James A. Donald jam...@echeque.com wrote: The system can be thought of as pseudorandom number generator that is continually seeded by a small amount of true randomness. beware about seeding. as the wisdom goes, once you seeded your prng with at least 128 bit entropy, you don't need to seed it anymore. but this is true only if you use a csprng. that is, a system that hides its internal state no matter how much output you observe. i have a strong guess that the CPU is not a csprng. you can reseed. but if you do, make sure you do it with at least 128 bit at a time. if you add entropy in small chunks, an attacker knowing the previous internal state and observes the output can brute force search for the added entropy. How much true randomness is an empirical question. I rather think that for normal systems, connected to the internet and physical disk drives, that is quite a lot of true randomness. can be, but we still need an estimation. saying that the entropy comes from the CPU, and is 4Mb/s is false advertising. compare these statements: A, our method generates 4Mb/s true randomness B, we believe that on a desktop pc, with network, hdd, keyb, etc, after booting a regular opsys, we have at least 128 bit. we also believe that the CPU as a mathematical system combined with our extractor together form a csprng. quite different, aren't they? ___ 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] Enranda: 4MB/s Userspace TRNG
On Thu, May 28, 2015 at 6:59 AM, James A. Donald jam...@echeque.com wrote: The system can be thought of as pseudorandom number generator that is continually seeded by a small amount of true randomness. beware about seeding. as the wisdom goes, once you seeded your prng with at least 128 bit entropy, you don't need to seed it anymore. but this is true only if you use a csprng. that is, a system that hides its internal state no matter how much output you observe. i have a strong guess that the CPU is not a csprng. you can reseed. but if you do, make sure you do it with at least 128 bit at a time. if you add entropy in small chunks, an attacker knowing the previous internal state and observes the output can brute force search for the added entropy. How much true randomness is an empirical question. I rather think that for normal systems, connected to the internet and physical disk drives, that is quite a lot of true randomness. can be, but we still need an estimation. saying that the entropy comes from the CPU, and is 4Mb/s is false advertising. compare these statements: A, our method generates 4Mb/s true randomness B, we believe that on a desktop pc, with network, hdd, keyb, etc, after booting a regular opsys, we have at least 128 bit. we also believe that the CPU as a mathematical system combined with our extractor together form a csprng. quite different, aren't they? ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Enranda: 4MB/s Userspace TRNG
Hi Steve, Yeah, the TSD bit probably should have been set from day one. But it wasn't, so userspace TRNGs are possible. Nonetheless, TSD does not constitute a threat to randomness: it would just result in a CPU privilege violation, followed by shutdown of Enranda. Not good, but certainly not ambiguous. And very rare in the wild. SMIs only _help_ randomness by messing with timing (due to slow firmware code). Yeah, another core might issue an SMI just to slow down Enranda. OK, so it slows down. Entropy density is unaffected. The SMI handler might be moronic and corrupt the TSC, but that's a firmware bug, not an Enranda bug. Maybe I missed your point here? As to Ptacek's article, I don't see any problem with /dev/urandom, but having both /dev/urandom and a userspace TRNG is at least as secure (assuming both are bugless). It also avoids dependency on Linux and/or worrying about urandom implementation. And finally, one could implement a userspace TRNG with no OS calls whatsoever (and certainly not /dev/ access), given only TSC access. In some regimes, that makes things a lot easier to implement and minimally latent. So it seems to me that a lot of security experts want to avoid userspace TRNGs because they assume that there's somewhere else to go which is actually safer (nevermind cross-OS), even though those places are all far removed from the app developer and the relative security of the CPU die. Sure, entropy from the PCI or USB bus is better than what the TSC has to offer by way of bandwidth, and possibly unpredictability. But OTOH they are more prone to wireless snooping and perhaps wireless influence. Personally, I would prefer to stay close to the core and away from those busses, especially the screeching serial lines beyond the southbridge. But a hybrid of the two would be safest. We could throw in the CPU randomness registers as well, when available. At least, Enranda is an adjunct to other randomness sources for those who don't trust any of them. If you don't like it, then at least, you are able to modify it at will. Russell Leidich On Wed, May 27, 2015 at 3:28 AM, Steve Weis stevew...@gmail.com wrote: On Tue, May 26, 2015 at 7:27 PM, Russell Leidich pke...@gmail.com wrote: Unfortunately, that page doesn't provide insights as to why that piece of advice was issued. On Wed, May 27, 2015 at 2:11 AM, Naveen Nathan nav...@lastninja.net wrote: Avoid: userspace random number generators, havaged, prngd, egd, /dev/random. Source: https://gist.github.com/tqbf/be58d2d39690c3b366ad The author Thomas Ptacek has a longer post on why people should just use /dev/urandom: http://sockpuppet.org/blog/2014/02/25/safely-generate-random-numbers/ Relying solely on the TSC seems like a bad idea because: 1) userspace access may be disabled for security purposes with the TSD bit 2) TSC measurements may be influenced by processes on other cores able to induce SMIs. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Enranda: 4MB/s Userspace TRNG
On 2015-05-27 22:14, Krisztián Pintér wrote: On Wed, May 27, 2015 at 3:12 AM, Russell Leidich pke...@gmail.com wrote: if your proposed method comes with a complex extractor, it is bullshit OK point well taken. I should offer a raw mode. no, you actually shouldn't. you should offer raw mode only. maybe some clever compression just to reduce the amount of data going into the slower secure whitening. What this leaves behind is the aperiodic residue. Or more specifically, ((the hashes (of all sequences)) that have not been seen in the last 2^16 such hashes). I realize that this isn't hard proof (as nothing in physical hardware can be proven) this is much worse than not a hard proof. it is next to nothing. you have a hypothesis, which you don't clearly state, and then you have a countermeasure, which you don't explain. cache misses, pipeline stalls, CPU circuit clock gating, etc. that provide the majority of the protoentropy. the CPU is a deterministic system. cache misses and all the other stuff are not random, but depend on previous instructions, thus the internal state of the cpu. this is NOT a source of entropy. the source of entropy comes from outside of the CPU, namely anything that changes its internal state. these are: responses from mass storage or other IO drivers, user input, network events, etc. that is: IRQs. the CPU as a system is chaotic, and so tiny differences in those inputs cause huge differences later. but this is NOT entropy. this is a completely deterministic process. The system can be thought of as pseudorandom number generator that is continually seeded by a small amount of true randomness. But it truly is seeded by a small amount of true randomness. How much true randomness is an empirical question. I rather think that for normal systems, connected to the internet and physical disk drives, that is quite a lot of true randomness. If on the other hand, your system is booting up from ROM, then early in the boot process, not much. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Enranda: 4MB/s Userspace TRNG
On 5/26/15, Kevin kevinsisco61...@gmail.com wrote: Are we talking about entropy taken from hard drive turbulence, the keyboard or mouse, heat decay, or what? ... requiring nothing but a timer (ideally, the CPU timestamp counter) for comparison, i run XSTORE on 1Ghz Padlock enabled processor at 100Mbps. better than nothing, but not close to an actual hw entropy system. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Enranda: 4MB/s Userspace TRNG
On 5/25/15, Russell Leidich pke...@gmail.com wrote: ... Enranda is a cryptographically secure (in the postquantum sense) true random number generator requiring nothing but a timer (ideally, the CPU timestamp counter). It produces roughly 4 megabytes of noise per second, which puts it in the same bandwidth league as physical quantum dot entropy sources (from camera pixel noise). Russell these claims are laughable and unsupported in ways you don't even understand. others may provide constructive criticism, as you seem sincere in your desire for building useful entropy collection. but this solution is worse than nothing, as it provides absurd claims of false security. best regards, ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Enranda: 4MB/s Userspace TRNG
On 5/25/2015 11:01 PM, Russell Leidich wrote: As annouced here in the original Jytter blog: http://jytter.blogspot.com It has been a long 3 years since Jytter was released. Enranda is now available for download, analysis, and criticism. It's open source with awesome licensing terms, courtesy of Tigerspike: http://tigerspike.com Enranda is a cryptographically secure (in the postquantum sense) true random number generator requiring nothing but a timer (ideally, the CPU timestamp counter). It produces roughly 4 megabytes of noise per second, which puts it in the same bandwidth league as physical quantum dot entropy sources (from camera pixel noise). It would be easy to reach much higher bandwidths by reading the timer in a tight loop while feeding it into a PRNG, but probably not safely so. The documentation goes to considerable lengths to explain this assertion. If you can demonstrate that Enranda is biased in a measurable way, or simply buggy, then you rock. You can get the commandline demo, the documentation, and even a text capture of the live demo at: http://enranda.blogspot.com By the way, Enranda's hardness is based in part on Dyspoissometer, a new statistical analysis package focussed on measuring dyspoissonism, that is, the extent to which a discrete set deviates from what we would asymptotically consider to be a Poisson distribution. You can get the demo, the documentation, and a demo capture at: http://dyspoissonism.blogspot.com May your ideas be random! Russell Leidich ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography Are we talking about entropy taken from hard drive turbulence, the keyboard or mouse, heat decay, or what? ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Enranda: 4MB/s Userspace TRNG
On 5/26/2015 2:01 PM, coderman wrote: On 5/25/15, Russell Leidich pke...@gmail.com wrote: ... Enranda is a cryptographically secure (in the postquantum sense) true random number generator requiring nothing but a timer (ideally, the CPU timestamp counter). It produces roughly 4 megabytes of noise per second, which puts it in the same bandwidth league as physical quantum dot entropy sources (from camera pixel noise). Russell these claims are laughable and unsupported in ways you don't even understand. others may provide constructive criticism, as you seem sincere in your desire for building useful entropy collection. but this solution is worse than nothing, as it provides absurd claims of false security. best regards, ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography And I did for one indeed question this system. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Enranda: 4MB/s Userspace TRNG
On 5/26/2015 1:46 PM, coderman wrote: On 5/26/15, Kevin kevinsisco61...@gmail.com wrote: Are we talking about entropy taken from hard drive turbulence, the keyboard or mouse, heat decay, or what? ... requiring nothing but a timer (ideally, the CPU timestamp counter) for comparison, i run XSTORE on 1Ghz Padlock enabled processor at 100Mbps. better than nothing, but not close to an actual hw entropy system. Got it. Don't know how I missed that. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Enranda: 4MB/s Userspace TRNG
On 5/26/15, coderman coder...@gmail.com wrote: ... others may provide constructive criticism, as you seem sincere in your desire for building useful entropy collection. but this solution is worse than nothing, as it provides absurd claims of false security. speaking of, ''' 'If you can demonstrate that Enranda is biased in a measurable way, or simply buggy, then you rock.''' - how about a BTC bounty to show any amount of bias, even against local attacker sharing processor? then i'll at least write a longer reply :P best regards, a lover and hater of unpredictability and entropy, most of all when they diverge! ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Enranda: 4MB/s Userspace TRNG
Hi coderman, I would welcome your longer reply, which would surely interest others here, as well. For starters, how do you envision this BTC boundary attack occurring? And yes, it's totally legit to attack Enranda by executing a process on the same CPU, for example, in another terminal window on a single-CPU system. For that matter, what other attacks do you foresee? I won't argue with your point about hardware TRNGs being superior to software ones. If you trust your chip vendor, then it all works just fine. Russell Leidich On Tue, May 26, 2015 at 7:47 PM, coderman coder...@gmail.com wrote: On 5/26/15, coderman coder...@gmail.com wrote: ... others may provide constructive criticism, as you seem sincere in your desire for building useful entropy collection. but this solution is worse than nothing, as it provides absurd claims of false security. speaking of, ''' 'If you can demonstrate that Enranda is biased in a measurable way, or simply buggy, then you rock.''' - how about a BTC bounty to show any amount of bias, even against local attacker sharing processor? then i'll at least write a longer reply :P best regards, a lover and hater of unpredictability and entropy, most of all when they diverge! ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Enranda: 4MB/s Userspace TRNG
On 5/26/15, Krisztián Pintér pinte...@gmail.com wrote: i call bullshit on this one, just as i called bullshit on havege... dakarand is the other to add to this set, as well as the high resolution timer based userspace rng daemon mods... best regards, ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Enranda: 4MB/s Userspace TRNG
i call bullshit on this one, just as i called bullshit on havege. a proper hwrng always outputs the raw, unfiltered random bits. and an estimate of the the entropy content. whitening is easy, and can be done various ways, it is not interesting. many times we don't even want whitening, because we already have an entropy accumulator arrangement, like linux /dev/random (whatever crap it is). conclusions: 1, if your proposed method comes with a complex extractor, it is bullshit 2, if your method comes without a detailed analysis and measurements on the entropy content of the raw data, it is bullshit for start, where your entropy is coming from? it all comes from IRQ-s, otherwise the CPU runs quite predictably. it is already fishy to say that you can collect 4Mbit/s from IRQ alone. also it is very different on different platforms. embedded systems without user interaction tend to have less IRQ noise. where are the estimates? where are the calculations? Russell Leidich (at Tuesday, May 26, 2015, 5:01:20 AM): Enranda is a cryptographically secure (in the postquantum sense) true random number generator requiring nothing but a timer (ideally, the CPU timestamp counter). http://enranda.blogspot.com ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Enranda: 4MB/s Userspace TRNG
On 5/26/15, Russell Leidich pke...@gmail.com wrote: ... I would welcome your longer reply, you are patient and friendly in response to me, a jerk flinging opinions! i will send a longer response about my specific concerns for these types of entropy gathering when time permits - thank you for courtesy un-deserved! ... how do you envision this BTC... Bounty, as in compensation for a successful attack in the form of digital currency :P no matter, i am compelled to delineate concerns and risks, as said above. And yes, it's totally legit to attack Enranda by executing a process on the same CPU, for example, in another terminal window on a single-CPU system. For that matter, what other attacks do you foresee? i am glad the post-quantum hardness has constraints, regarding the rest, another tangent. as said above. I won't argue with your point about hardware TRNGs being superior to software ones. If you trust your chip vendor, then it all works just fine. i trust them more if the design provides raw sample access and the observed entropy density, bias, failure modes, as observed over extended sanity and continuous run-checks on the sampled bit stream. ... CPU instructions another tangent, which i've written about separately wrt RDRAND/RDSEED vs. XSTORE entropy sources. best regards, and my apologies for first, ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
[cryptography] Enranda: 4MB/s Userspace TRNG
As annouced here in the original Jytter blog: http://jytter.blogspot.com It has been a long 3 years since Jytter was released. Enranda is now available for download, analysis, and criticism. It's open source with awesome licensing terms, courtesy of Tigerspike: http://tigerspike.com Enranda is a cryptographically secure (in the postquantum sense) true random number generator requiring nothing but a timer (ideally, the CPU timestamp counter). It produces roughly 4 megabytes of noise per second, which puts it in the same bandwidth league as physical quantum dot entropy sources (from camera pixel noise). It would be easy to reach much higher bandwidths by reading the timer in a tight loop while feeding it into a PRNG, but probably not safely so. The documentation goes to considerable lengths to explain this assertion. If you can demonstrate that Enranda is biased in a measurable way, or simply buggy, then you rock. You can get the commandline demo, the documentation, and even a text capture of the live demo at: http://enranda.blogspot.com By the way, Enranda's hardness is based in part on Dyspoissometer, a new statistical analysis package focussed on measuring dyspoissonism, that is, the extent to which a discrete set deviates from what we would asymptotically consider to be a Poisson distribution. You can get the demo, the documentation, and a demo capture at: http://dyspoissonism.blogspot.com May your ideas be random! Russell Leidich ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
