Re: [cryptography] urandom vs random
On 8/20/2013 2:33 PM, grarpamp wrote: The subject thread is covering a lot about OS implementations and RNG various sources. But what are the short list of open source tools we should be using to actually test and evaluate the resulting number streams? ___ I like the Markov-Renye test described in the current SP800-90B draft. It handles biased, correlated, non stationary data conservatively and gives you a min-entropy estimate. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] urandom vs random
On Sun, Sep 8, 2013 at 9:57 PM, David Johnston d...@deadhat.com wrote: ... I've argued in private (and now here) that a large entropy pool is a natural response to entropy famine and uneven supply, just like a large grain depot guards against food shortages and uneven supply. this is a good analogy :) ... The natural size for the state shrinks to the block size of the crypto function being used for entropy extraction for best effective performance, it seems memory bus(es) constrains the optimal transmission unit size. 4k extended instructions providing more throughput than repeated instructions at 512bit chunks. the worst case scenarios, you're passing entropy directly into AES native instructions, and/or onward to PCIe lanes... This is one of the things that drove the design decisions in the RdRand DRNG. With 2.5Gbps of 95% entropic data, there is no value in stirring the data into a huge pool (E.G. like Linux) you keep coming back to this assumption that RDRAND is entirely trusted and always available. consider adding additional entropy sources like USB keys, scavengers like Dakarand or Haveged, and so forth. conversely to your argument, there is no harm in aggressively mixing a large pool with a high rate hardware entropy source. if you are one of the worst case scenarios, like seeding an entire new volume for full disk encryption with entropy, then you can manage accordingly and cut out the OS level, kernel pool middle man, system call boundary, and other overhead accordingly. A consequence of Linux having a big pool is that the stirring algorithm is expensive because it has to operate over a many bits. but not effectively expensive! again, i find very few the situations in which my modern processor is unable to keep a properly refilled aggressively reseeded /dev/random up to any demanded rate of consumption for high speed network services, common client side uses, most key generation, and so forth. if you are one of the worst case scenarios, like seeding an entire new volume for full disk encryption with entropy, then you can manage accordingly and cut out the OS level, kernel pool middle man, system call boundary, and other overhead When I count my raw data in bits per second, rather than gigabits per second, I am of course going to use them efficiently and mix up a large pot of state, so I can get maximum utility. With the RdRand DRNG, the bus is the limiting factor, not the supply or the pool size. fair enough, but consider the inverse, particularly for a skeptical audience knowing what we do now: why not mix aggressively with multiple sources if you have the CPU budget? why not provide access to the raw, un-mixed, un-encrypted, un-whitened, un-obfuscated state of the raw entropy bits for those so inclined to use it in such a manner? efforts to drive RDRAND into direct use instead of the kernel entropy pool in the linux kernel, efforts to steadfast refuse access to the raw entropy stream, are thus viewed with elements of suspicion and provide an air of lack of credibility. even with all of these concerns, i have publicly said and will continue to assert, using RDRAND is better than nothing. the current state of entropy on most operating systems and especially virtual machine environments on these operating systems, is very poor. it is just a shame this resource cannot be used to greater utility and confidence, as would be provided, were raw access be available. best regards, ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] urandom vs random
Just appeared on the GnuPG list: NeuG 0.11 was released. NeuG is an implementation of True Random Number Generator based on quantization error of ADC of STM32F103. It is basically intended to be used as a part of Gnuk, but we also have standalone USB CDC-ACM version (you can get random stream from /dev/ttyACM0). Standalone version is useful to feed entropy to /dev/random on GNU/Linux. Its generation speed is = 50kB/sec, and it's more when connected to USB 2.0 Hub. The output is tested NIST STS 2.1.1 and Dieharder 3.31.1. Highlights are: * Replacement of kernel (thread library) Instead of ChibiOS/RT, we now use Chopstx. * Improved performance The output of random numbers got faster than the previous implementation by 30% or so. * Unsupported targets CQ_STARM, STBEE, STBEE Mini, and STM32_PRIMER2 are not supported in this release, but porting should be easy. Here are some links for NeuG, Gnuk and FST-01 (the hardware). NeuG (under Gnuk Repository): http://gitorious.org/gnuk/neug Gnuk News: http://www.fsij.org/gnuk/ FST-01 introduction: http://www.seeedstudio.com/wiki/index.php?title=FST-01 FST-01 QA site: http://no-passwd.net/askbot/questions/ Japanese Documentation for FST-01 and Gnuk Token: http://no-passwd.net/fst-01-gnuk-handbook/index.html Enjoy, ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] urandom vs random
In terms of usability engineering, /dev/random is fairly cumbersome and in dire need of reform and expansion. A user, might want more control of /dev/random - which sources of entropy, when, and which applications. e.g. I want my Geiger counter to feed communications and radio noise to feed data. I want 3000 from 9am-5pm and 200 otherwise. I want all this'd in a GUI or config file. A developer, might want to tell /dev/random don't give me keyboard and mouse crap, instead give me 80% rdrand and 20% audio source. Naturally, the better alternative is a widely implemented open sources TRNG, but good luck convincing manufacturers. So why concentrate on what you can't fix. Reform /dev/random and empower user and developer with choice over quality and amount of randomness! Randomness is hard to prove but you can test quality with dierharder. Open eSignForms yoz...@gmail.com wrote: We all know that randomness is required for good crypto, but what is the a measurable difference in the quality of the crypto if using a Linux PRNG (or in our case the Java SecureRandom PRNG)? How much easier is it to crack an encrypted file done with such weaker PRNGs compared to the hardware RNGs, especially if it's so hard to determine the quality of the randomness. On Tue, Aug 20, 2013 at 4:10 PM, James A. Donald jam...@echeque.com wrote: On 2013-08-21 7:33 AM, grarpamp wrote: The subject thread is covering a lot about OS implementations and RNG various sources. But what are the short list of open source tools we should be using to actually test and evaluate the resulting number streams? __**_ You cannot test and evaluate a supposedly random number stream. True randomness and cryptographically strong pseudo randomness are not directly observable qualities. You have to look at the underlying generation mechanism and deduce randomness, or the lack thereof. If you apply a whitening expander to the source stream 000 the output stream will look convincingly random, but will be completely non random to anyone who knows the whitening expander and knows or suspects that the source stream is completely non random __**_ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/**mailman/listinfo/cryptographyhttp://lists.randombit.net/mailman/listinfo/cryptography ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography -- Yazid Boukerroui ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] urandom vs random
On 8/22/13 9:40 AM, Nico Williams wrote: My suggestion is /dev/urandomN where N is one of 128, 192, or 256, and represents the minimum entropy estimate of HW RNG inputs to date to /dev/urandomN's pool. If the pool hasn't received that much entropy at read(2) time, then block, else never block and just keep stretching that entropy and accepting new entropy as necessary. That sounds like the perfect interface! The existing dichotomy between random and urandom (on Linux) is horrible, and it's nice to be able to specify how much entropy you are in need of. --Patrick ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] urandom vs random
On Fri, Aug 23, 2013 at 12:54 AM, Patrick Pelletier c...@funwithsoftware.org wrote: On 8/22/13 9:40 AM, Nico Williams wrote: My suggestion is /dev/urandomN where N is one of 128, 192, or 256, and represents the minimum entropy estimate of HW RNG inputs to date to /dev/urandomN's pool. If the pool hasn't received that much entropy at read(2) time, then block, else never block and just keep stretching that entropy and accepting new entropy as necessary. That sounds like the perfect interface! The existing dichotomy between random and urandom (on Linux) is horrible, and it's nice to be able to specify how much entropy you are in need of. Instead of a bunch of additional devices in /dev, the could add support to use fcntl(2) and ioctl(2) system calls to control it. That would allow for more granular control (although not be as convenient from languages where fcntl and ioctl are not supported such as the shell or Java. On second thought, scrap that idea. Of course, as far as blocking / non-blocking I/O, one should be able to change that behavior by a flag to the open(2) system call; e.g., int fd = open(/dev/random, O_RDONLY | O_NONBLOCK); or for /dev/urandom, int fd = open(/dev/urandom, O_RDONLY | ~O_NONBLOCK); At least that much could be supported from Java if not from the shell. Then if it is opened not to block, any read(2) request should either return whatever is available or -1 with errno set to EWOULDBLOCK when the normal result would be to block because there is not sufficient entropy. It would be up to the application to repeat the read() attempt (hopefully sleeping awhile in between) if they haven't read enough bytes. -kevin -- Blog: http://off-the-wall-security.blogspot.com/ The most likely way for the world to be destroyed, most experts agree, is by accident. That's where we come in; we're computer professionals. We *cause* accidents.-- Nathaniel Borenstein ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] urandom vs random
You can use DieHarder, which is a collection of statistical tests to evaluate if somethings looks random. grarpamp grarp...@gmail.com schrieb: The subject thread is covering a lot about OS implementations and RNG various sources. But what are the short list of open source tools we should be using to actually test and evaluate the resulting number streams? ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography -- Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] urandom vs random
On 21. Aug 2013, at 09:32 AM, Dominik domi...@dominikschuermann.de wrote: You can use DieHarder, which is a collection of statistical tests to evaluate if somethings looks random. Problem is that you have to use the suite in a proper way. Checking a single weak Debian SSL key pair probably would not have raised the problem. You'd have had to generate many keys ( 2^16) with that Debian SSL version to learn that they repeat. So simply running DieHarder is not enough. Regards, Sebastian ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] urandom vs random
On Mon, Aug 19, 2013 at 09:41:20AM -0400, Jeffrey Walton wrote: On Mon, Aug 19, 2013 at 9:20 AM, Aaron Toponce aaron.topo...@gmail.com wrote: ... It's a shame http://entropykey.co.uk is no longer in business. I was able to procure 5 entropy keys just before they folded, and they're awesome. Yeah, I really liked EntropyKey. I tried to place an order last year (or early this year). It was never fulfilled and no one responded. I knew the were having some troubles, but I could not determine the cause. Why did they fold? A combination of medical and family issues. (I used to work there.) B. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] urandom vs random
On Mon, Aug 19, 2013 at 07:20:45AM -0600, Aaron Toponce wrote: On Sun, Aug 18, 2013 at 05:07:49PM -0700, coderman wrote: i am surprised this has not surfaced more often in this thread: if you need good entropy: use a hardware entropy generator! It's a shame http://entropykey.co.uk is no longer in business. I was able to procure 5 entropy keys just before they folded, and they're awesome. They should be available again by the end of the year, if all goes well. B. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] urandom vs random
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/20/2013 05:33 PM, grarpamp wrote: The subject thread is covering a lot about OS implementations and RNG various sources. But what are the short list of open source tools we should be using to actually test and evaluate the resulting number streams? I've done some non-scientific experiments (i.e., sated my curiosity) with ENT (formerly at http://www.fourmilab.ch/random/, now maintained at http://packages.debian.org/sid/ent). I found the results interesting and somewhat useful. - -- The Doctor [412/724/301/703] [ZS] Developer, Project Byzantium: http://project-byzantium.org/ PGP: 0x807B17C1 / 7960 1CDC 85C9 0B63 8D9F DD89 3BD8 FF2B 807B 17C1 WWW: https://drwho.virtadpt.net/ Meeble! Meeble meeble meeble! -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlIU6D4ACgkQO9j/K4B7F8Hi1QCgi6Bm8JqfK6YdlVJJme0FkMS6 ofoAnj5Xy4JxstfcoJjSg6rO4KuYOHB8 =KMra -END PGP SIGNATURE- ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] urandom vs random
On Tue, Aug 20, 2013 at 12:46:42PM +1200, Peter Gutmann wrote: I don't see what the point is though, given that there's more than enough noisy data available on a general-purpose PC. True. I use http://www.issihosts.com/haveged/ on physical hardware, and the entropy keys by Simtec for virtual machines and containers. -- . o . o . o . . o o . . . o . . . o . o o o . o . o o . . o o o o . o . . o o o o . o o o pgpHl2fdbjiSU.pgp Description: PGP signature ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] urandom vs random
grarpamp grarp...@gmail.com wrote: The subject thread is covering a lot about OS implementations and RNG various sources. But what are the short list of open source tools we should be using to actually test and evaluate the resulting number streams? Two good ones are listed linked here http://en.citizendium.org/wiki/Random_number#Testing_for_Randomness My system is running Xubuntu. Randomness testers that are in its repositories, and presumably quite a few others, are ent(1) and dieharder(1). See other posts in the thread for limitations of such testing. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] urandom vs random
On Tue, Aug 20, 2013 at 05:33:05PM -0400, grarpamp wrote: The subject thread is covering a lot about OS implementations and RNG various sources. But what are the short list of open source tools we should be using to actually test and evaluate the resulting number streams? As already mentioned in the thread, you can only identify a random source, which in order to be truly random, must come from some chaotic random source, such as radioactive decay. However, you can make statistical judgements on the output, to determine if the source is 'random enough'. This is where the Die Hard and FIPS 140-2 checks come into play. The trick is sampling for a long period of time, rather than a few minutes here and there. # timeout 1h rngtest /dev/random rngtest 2-unofficial-mt.14 Copyright (c) 2004 by Henrique de Moraes Holschuh This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. rngtest: starting FIPS tests... rngtest: bits received from input: 79369360032 rngtest: FIPS 140-2 successes: 3965374 rngtest: FIPS 140-2 failures: 3094 rngtest: FIPS 140-2(2001-10-10) Monobit: 378 rngtest: FIPS 140-2(2001-10-10) Poker: 393 rngtest: FIPS 140-2(2001-10-10) Runs: 1205 rngtest: FIPS 140-2(2001-10-10) Long run: 1128 rngtest: FIPS 140-2(2001-10-10) Continuous run: 0 rngtest: input channel speed: (min=419.675; avg=25223.970; max=28892.382)Kibits/s rngtest: FIPS tests speed: (min=6.227; avg=143.700; max=155.069)Mibits/s rngtest: Program run time: 360102 microseconds ~.078% failure rate for these tests. -- . o . o . o . . o o . . . o . . . o . o o o . o . o o . . o o o o . o . . o o o o . o o o pgp9uG1y9f79F.pgp Description: PGP signature ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] urandom vs random
On 20/08/13 03:46 AM, Peter Gutmann wrote: shawn wilson ag4ve...@gmail.com writes: It's not like they're the only ones that sell these, but they /were/ the only ones to sell USB PRNG at $800. You can get them for as little as $50 in the form of USB-key media players running Android. Or if you really insist on doing the whole thing yourself, get something like an EA-XPR-003 ($29 in single-unit quantities from Digikey, http://www.digikey.com/product-detail/en/EA-XPR-003/EA-XPR-003-ND/2410099) and solder on a zener diode and a few I2C environmental sensors for noise/unpredictability generation. I don't see what the point is though, given that there's more than enough noisy data available on a general-purpose PC. Has anyone done a survey? On a related point, what name do we give to the design/pattern for entropy sources == mix/pool == deterministic expansion function ? I was asked this seconds after tasking my intern to build one :-/ iang ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] urandom vs random
ianG i...@iang.org writes: On a related point, what name do we give to the design/pattern for entropy sources == mix/pool == deterministic expansion function ? The standard way to do things? Or a standard CSPRNG (continually seeded PRNG). Peter. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] urandom vs random
On 20 August 2013 01:46, Peter Gutmann pgut...@cs.auckland.ac.nz wrote: I don't see what the point is though, given that there's more than enough noisy data available on a general-purpose PC. A general purpose cloud VM where an attacker has a chance to run his VM on the same underlying hardware may be more problematic. But also harder to fix with a DIY USB device -- alan.bragg...@gmail.com http://www.chiark.greenend.org.uk/~armb/ ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] urandom vs random
On 2013-08-20 1:31 AM, ianG wrote: It's a recurring theme -- there doesn't seem to be enough market demand for Hardware RNGs. Every microphone is a hardware RNG ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] urandom vs random
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 20/08/13 07:08, ianG wrote: On a related point, what name do we give to the design/pattern for entropy sources == mix/pool == deterministic expansion function ? I was asked this seconds after tasking my intern to build one :-/ Seems like HKDF's extract-then-expand terminology might be appropriate here, albeit in a slightly different context. Cheers, Michael -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iQEcBAEBAgAGBQJSE0tnAAoJEBEET9GfxSfMm+kIAIqGmzYYBigujiLsjJqkhfAF JpdMmUHIlH/SP2U/Vz+qMf3Hp/4dLiw8iIcUherJVylRvBUT/ngA+Roc65pQXlkC PdPKzu1HECIFMyYXx1wQtNFAdNfNHFgKSV/rDyR/F/kf4MRDkALKHyWSImu3xyee FKeZnb6PEGa+KLGwJ9CaQqsCYjy/95jBPAFhMdH0qpwGozQrvtoy9TuubZKARu85 O/QvLI/TrzE1J9orOQNCsDxGDSLa4Dx/ElyqqieIhdwbK4A/fN1EgnyTyJ+e+1Yf HefIN1y7DXTY91d2BZncIygKZgzMdsFNLAMnw1UsiWvwmFTWB8/w6+tHteolj6s= =g2GX -END PGP SIGNATURE- ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] urandom vs random
Not exactly. I think havaged is better at this as you're relying on the same type of data but with a single source. I also don't believe you want a microphone inline in order to do this. You should rely purely on electric noise with the ADC/mixer. I don't even think the volume level affects the quality of the randomness. Though I think you generate more random bits at higher levels. Again, at this point, I trust a modern linux kernel or havaged more than a rigged solution. -Original Message- From: James A. Donald jam...@echeque.com To: cryptography@randombit.net Sent: Tue, 20 Aug 2013 5:54 Subject: Re: [cryptography] urandom vs random On 2013-08-20 1:31 AM, ianG wrote: It's a recurring theme -- there doesn't seem to be enough market demand for Hardware RNGs. Every microphone is a hardware RNG ___ 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] urandom vs random
The subject thread is covering a lot about OS implementations and RNG various sources. But what are the short list of open source tools we should be using to actually test and evaluate the resulting number streams? ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] urandom vs random
Most regular people can't accurately test or evaluate the output. Numbers aren't random, the sources are. You can't just judge a PRNG by it's output. For all you know the PRNG could be doing nothing more than doing SHA256 of a fixed value plus a counter, and if somebody would know that fixed value then bruteforce is trivial since testing a few thousand counter values isn't all that hard. And yet the output would *look* random. 2013/8/20 grarpamp grarp...@gmail.com: The subject thread is covering a lot about OS implementations and RNG various sources. But what are the short list of open source tools we should be using to actually test and evaluate the resulting number streams? ___ 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] urandom vs random
On Tue, Aug 20, 2013 at 5:58 PM, Natanael natanae...@gmail.com wrote: For all you know the PRNG could be doing nothing more than doing SHA256 of a fixed value plus a counter Yes, and in an application where even that trivial design would serve to fit some use, testing the apparent randomness.of proposed hash functions against themselves, and proof sampling operational matters, would still be useful to do. To that end, here is one tool that was forwarded off list... http://csrc.nist.gov/groups/ST/toolkit/rng/index.html ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] urandom vs random
On 2013-08-21 7:33 AM, grarpamp wrote: The subject thread is covering a lot about OS implementations and RNG various sources. But what are the short list of open source tools we should be using to actually test and evaluate the resulting number streams? ___ You cannot test and evaluate a supposedly random number stream. True randomness and cryptographically strong pseudo randomness are not directly observable qualities. You have to look at the underlying generation mechanism and deduce randomness, or the lack thereof. If you apply a whitening expander to the source stream 000 the output stream will look convincingly random, but will be completely non random to anyone who knows the whitening expander and knows or suspects that the source stream is completely non random ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] urandom vs random
We all know that randomness is required for good crypto, but what is the a measurable difference in the quality of the crypto if using a Linux PRNG (or in our case the Java SecureRandom PRNG)? How much easier is it to crack an encrypted file done with such weaker PRNGs compared to the hardware RNGs, especially if it's so hard to determine the quality of the randomness. On Tue, Aug 20, 2013 at 4:10 PM, James A. Donald jam...@echeque.com wrote: On 2013-08-21 7:33 AM, grarpamp wrote: The subject thread is covering a lot about OS implementations and RNG various sources. But what are the short list of open source tools we should be using to actually test and evaluate the resulting number streams? __**_ You cannot test and evaluate a supposedly random number stream. True randomness and cryptographically strong pseudo randomness are not directly observable qualities. You have to look at the underlying generation mechanism and deduce randomness, or the lack thereof. If you apply a whitening expander to the source stream 000 the output stream will look convincingly random, but will be completely non random to anyone who knows the whitening expander and knows or suspects that the source stream is completely non random __**_ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/**mailman/listinfo/cryptographyhttp://lists.randombit.net/mailman/listinfo/cryptography ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] urandom vs random
On Sun, Aug 18, 2013 at 05:07:49PM -0700, coderman wrote: i am surprised this has not surfaced more often in this thread: if you need good entropy: use a hardware entropy generator! It's a shame http://entropykey.co.uk is no longer in business. I was able to procure 5 entropy keys just before they folded, and they're awesome. All the hardware specifications were open, as well as the userspace software. I ended up creating an entropy server with these keys, of which I feed all my VM entropy pools with. You can see it at http://hundun.ae.st. I'm currently working on a program to feed the random data found from an RTL-SDR dongle into the entropy pool. Then just tune to an empty frequency, and let atmospheric noise rule. At any event, I'm in agreeance: hardware true random number generators *. -- . o . o . o . . o o . . . o . . . o . o o o . o . o o . . o o o o . o . . o o o o . o o o pgpoaHm7b30_S.pgp Description: PGP signature ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] urandom vs random
On Mon, Aug 19, 2013 at 9:20 AM, Aaron Toponce aaron.topo...@gmail.com wrote: ... It's a shame http://entropykey.co.uk is no longer in business. I was able to procure 5 entropy keys just before they folded, and they're awesome. Yeah, I really liked EntropyKey. I tried to place an order last year (or early this year). It was never fulfilled and no one responded. I knew the were having some troubles, but I could not determine the cause. Why did they fold? Jeff ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] urandom vs random
[Aaron Toponce aaron.topo...@gmail.com (2013-08-19 13:20:45 UTC)] I'm currently working on a program to feed the random data found from an RTL-SDR dongle into the entropy pool. Then just tune to an empty frequency, and let atmospheric noise rule. The raspberry pi supposedly has a hardware RNG built in. Perhaps one could be used as a random data dongle? It's not like they're super expensive. http://scruss.com/blog/2013/06/07/well-that-was-unexpected-the-raspberry-pis-hardware-random-number-generator/ - Harald ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] urandom vs random
They're also not super good. They barely keep up with my ssh traffic and it took ages to create a key for whatever Arch wanted (don't recall what). On Mon, Aug 19, 2013 at 10:21 AM, Harald Hanche-Olsen han...@math.ntnu.nowrote: [Aaron Toponce aaron.topo...@gmail.com (2013-08-19 13:20:45 UTC)] I'm currently working on a program to feed the random data found from an RTL-SDR dongle into the entropy pool. Then just tune to an empty frequency, and let atmospheric noise rule. The raspberry pi supposedly has a hardware RNG built in. Perhaps one could be used as a random data dongle? It's not like they're super expensive. http://scruss.com/blog/2013/06/07/well-that-was-unexpected-the-raspberry-pis-hardware-random-number-generator/ - Harald ___ 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] urandom vs random
On Mon, Aug 19, 2013 at 09:41:20AM -0400, Jeffrey Walton wrote: Yeah, I really liked EntropyKey. I tried to place an order last year (or early this year). It was never fulfilled and no one responded. I knew the were having some troubles, but I could not determine the cause. Why did they fold? I don't know why they folded. I'm guessing lack of demand didn't justify their costs. Possibly understaffed as well. When I placed my order, it took them 8 weeks to ship it, and I was emailing anyone and everyone I could to get a status update or anything. It's too bad. They had the best product. -- . o . o . o . . o o . . . o . . . o . o o o . o . o o . . o o o o . o . . o o o o . o o o pgpzrApNxrOmb.pgp Description: PGP signature ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] urandom vs random
Hi Aaron, Here is the last I saw of them (besides the website being up): http://lists.simtec.co.uk/pipermail/entropykey-users/2013-July/thread.html. They claim to still be around (from the last in the thread): We've gone through a major crisis, but are still here... just. To say any more in public at this stage might be unwise from a legal standpoint. We currently have no manufacturing capability for ekeys but are working towards getting things up and running again. There's no timescale on that yet, I'm afraid. Jeff On Mon, Aug 19, 2013 at 11:21 AM, Aaron Toponce aaron.topo...@gmail.com wrote: On Mon, Aug 19, 2013 at 09:41:20AM -0400, Jeffrey Walton wrote: Yeah, I really liked EntropyKey. I tried to place an order last year (or early this year). It was never fulfilled and no one responded. I knew the were having some troubles, but I could not determine the cause. Why did they fold? I don't know why they folded. I'm guessing lack of demand didn't justify their costs. Possibly understaffed as well. When I placed my order, it took them 8 weeks to ship it, and I was emailing anyone and everyone I could to get a status update or anything. It's too bad. They had the best product. -- . o . o . o . . o o . . . o . . . o . o o o . o . o o . . o o o o . o . . o o o o . o o o ___ 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] urandom vs random
On 19/08/13 18:21 PM, Aaron Toponce wrote: On Mon, Aug 19, 2013 at 09:41:20AM -0400, Jeffrey Walton wrote: Yeah, I really liked EntropyKey. I tried to place an order last year (or early this year). It was never fulfilled and no one responded. I knew the were having some troubles, but I could not determine the cause. Why did they fold? I don't know why they folded. I'm guessing lack of demand didn't justify their costs. Possibly understaffed as well. When I placed my order, it took them 8 weeks to ship it, and I was emailing anyone and everyone I could to get a status update or anything. It's too bad. They had the best product. You mean, they had the best marketing :) if they had a product, you would have had it. It's a recurring theme -- there doesn't seem to be enough market demand for Hardware RNGs. I once toyed with the idea of creating an open source hardware design for a USB interface. Then, seed the market by buying a few thou. And finally, encourage random USB parts manufacturers to just throw it on to their chip. The thing is, the real estate required for a hardware RNG is fairly minimal, and USB devices can be promiscuous, offering multiple interfaces for little effort. So why not come up with a USB memory stick that also advertises a random file as a separate device? Just a pipe dream, needs a hardware geek to push it. iang ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] urandom vs random
On Mon, Aug 19, 2013 at 11:27:37AM -0400, Jeffrey Walton wrote: Here is the last I saw of them (besides the website being up): http://lists.simtec.co.uk/pipermail/entropykey-users/2013-July/thread.html. They claim to still be around (from the last in the thread): We've gone through a major crisis, but are still here... just. To say any more in public at this stage might be unwise from a legal standpoint. We currently have no manufacturing capability for ekeys but are working towards getting things up and running again. There's no timescale on that yet, I'm afraid. That's good. I just noticed that they removed all references to the entropy key from their http://simtec.co.uk website, and http://entropykey.co.uk is down, and I have had frequent emails asking if I would be willing to sell my keys, as others putting in their own orders are not getting resolved. Hopefully they rise like a phoenix, and their product is for sale again. I would like to purchase more. -- . o . o . o . . o o . . . o . . . o . o o o . o . o o . . o o o o . o . . o o o o . o o o pgpa6bK5BpJEg.pgp Description: PGP signature ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] urandom vs random
Aaron Toponce aaron.topo...@gmail.com wrote: On Sun, Aug 18, 2013 at 05:07:49PM -0700, coderman wrote: i am surprised this has not surfaced more often in this thread: if you need good entropy: use a hardware entropy generator! It's a shame http://entropykey.co.uk is no longer in business. ... At any event, I'm in agreeance: hardware true random number generators... Yes, there is software to turn a sound device into one: http://www.av8n.com/turbid/paper/turbid.htm A sound device is available on many server boards and often unused, or you can add one in a slot or USB on others, ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] urandom vs random
On Mon, Aug 19, 2013 at 11:31 AM, Aaron Toponce aaron.topo...@gmail.comwrote: Hopefully they rise like a phoenix, and their product is for sale again. I would like to purchase more. No kidding. I think someone on here told me about them and I tried to get one a bit later and couldn't. I think the company I work for might also get a few as well. It's not like they're the only ones that sell these, but they /were/ the only ones to sell USB PRNG at $800. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] urandom vs random
if they had a product, you would have had it. It's a recurring theme -- there doesn't seem to be enough market demand for Hardware RNGs. I once toyed with the idea of creating an open source hardware design This reminds me, where are the open designs for a strong hwRNG based on the common smoke detector? People say they want a hwRNG, lots of them are free for asking right down the street at the demolition site. But where are the designs? ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] urandom vs random
shawn wilson ag4ve...@gmail.com writes: It's not like they're the only ones that sell these, but they /were/ the only ones to sell USB PRNG at $800. You can get them for as little as $50 in the form of USB-key media players running Android. Or if you really insist on doing the whole thing yourself, get something like an EA-XPR-003 ($29 in single-unit quantities from Digikey, http://www.digikey.com/product-detail/en/EA-XPR-003/EA-XPR-003-ND/2410099) and solder on a zener diode and a few I2C environmental sensors for noise/unpredictability generation. I don't see what the point is though, given that there's more than enough noisy data available on a general-purpose PC. Peter. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] urandom vs random
Sandy Harris sandyinch...@gmail.com writes: A sound device is available on many server boards and often unused, or you can add one in a slot or USB on others, A friend of mine looked at this a while back using the pretty simple technique of drawing a scatter plot from the samples. The output of most disconnected audio inputs is a long, long way from random, and in particular if they mute on lack of input or have at least a modicum of noise filtering, you just get a run of zeroes. Yes, there is software to turn a sound device into one: http://www.av8n.com/turbid/paper/turbid.htm Huge amounts of theory, no actual measurement of what you're getting from the raw data as far as I can see. The very, very brief Actual Measurement Results involved running Maurer's test on the hashed output of the generator. Sound cards are useful as a general mix in it regardless because it can't hurt source, but you'd never want to use them as your single point of failure source. Peter. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] urandom vs random
On Aug 19, 2013, at 7:46 PM, Peter Gutmann pgut...@cs.auckland.ac.nz wrote: You can get them for as little as $50 in the form of USB-key media players running Android. Or if you really insist on doing the whole thing yourself, get something like an EA-XPR-003 ($29 in single-unit quantities from Digikey, http://www.digikey.com/product-detail/en/EA-XPR-003/EA-XPR-003-ND/2410099) and solder on a zener diode and a few I2C environmental sensors for noise/unpredictability generation. Peter. If someone is interested in building something like this, you may want to start with this simple project I posted on Github a while back. https://github.com/wyager/TeensyRNG It's a simple, but (I think) pretty secure hardware PRNG that takes environmental noise and securely mixes it into an internal entropy pool. It does a few nice things like input debiasing, cryptographic mixing, etc. With a few small changes you could slap it on pretty much any microcontroller or SoC and get a pretty decent entropy stick. I used the $19 teensy and it generates about 100 bytes/sec of what is probably pretty good pseudorandom data. No guarantees, of course. I probably made some fatal mistake that would render it useless in certain contexts, but like I said, it's a place to start. Will signature.asc Description: Message signed with OpenPGP using GPGMail ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] urandom vs random
On 8/19/13 1:51 PM, grarpamp wrote: This reminds me, where are the open designs for a strong hwRNG based on the common smoke detector? People say they want a hwRNG, lots of them are free for asking right down the street at the demolition site. But where are the designs? The creator of HotBits provides a fair amount of information about his design: http://www.fourmilab.ch/hotbits/hardware3.html Although he actually recommends against using the Americium from smoke detectors, and says it is safer to purchase a commercial Cesium radiation source, which he provides links to. --Patrick ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] urandom vs random
On 2013-08-18 4:11 PM, Ben Laurie wrote: If I chose to run Linux, I could fix the version I ran. In fact, I choose not to run it, so I don't need to. But if you write software, you don't write it just for your own computer, so if you write software for linux, you have to write it for the linux that everyone else runs. Which you cannot fix. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] urandom vs random
On 18/08/13 09:11 AM, Ben Laurie wrote: If I chose to run Linux, I could fix the version I ran. In fact, I choose not to run it, so I don't need to. Indeed, or: That's terrible advice. Implement your own crypto of any sort widely leads to complete fail, as we see repeatedly. ;) gentle nudge... iang ps; for some reason, I am reminded of Blue Peter -- don't try this at home! for the anglo-challenged, Blue Peter was a children's show that filled a spot like Sesame Street. The phrase entered the language... ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] urandom vs random
On 18 August 2013 02:55, James A. Donald jam...@echeque.com wrote: On 2013-08-18 4:11 PM, Ben Laurie wrote: If I chose to run Linux, I could fix the version I ran. In fact, I choose not to run it, so I don't need to. But if you write software, you don't write it just for your own computer, so if you write software for linux, you have to write it for the linux that everyone else runs. Which you cannot fix. I do not have an obligation to work around all your broken decisions. Currently, my advice is that you probably should not run Linux if you need strong randomness. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] urandom vs random
On Sat, Aug 17, 2013 at 12:48:12PM -0400, Sandy Harris wrote: On Fri, Aug 16, 2013 at 11:07 AM, Aaron Toponce aaron.topo...@gmail.com wrote: The /dev/urandom device in the Linux kernel uses the Yarrow pseudo random number generator when the entropy pool has been exhausted. No, it doesn't, or at least did not last time I looked at the code, a few months ago. There are similaities, but also large differences. Ah, my apologies. The FreeBSD implementation of a PRNG uses Yarrow. It appears that http://lxr.linux.no/linux+v3.10.7/drivers/char/random.c is using SHA to hash the contents of the entropy pool. -- . o . o . o . . o o . . . o . . . o . o o o . o . o o . . o o o o . o . . o o o o . o o o pgpfY0tSRHe_o.pgp Description: PGP signature ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] urandom vs random
On Sat, Aug 17, 2013 at 12:24:45AM -, D. J. Bernstein wrote: I'm not saying that /dev/urandom has a perfect API. It's disappointingly common for vendors to deploy devices where the randomness pool has never been initialized; BSD /dev/urandom catches this configuration bug by blocking, but Linux /dev/urandom (unlike Linux /dev/random) spews predictable data, causing (e.g.) the widespread RSA security failures documented on http://factorable.net. But fixing this configuration bug has nothing to do with the /dev/random superstitions. That paper is actually a real good read, especially those for Fedora, CentOS, RHEL, and other RPM-based systems, where SSH is installed by default, and the boot-time entropy hole is a real concern. But, as the paper mentions, keys generated late after boot weren't affected, and there were vulnerable keys on BSD systems generated with arc4random(3). -- . o . o . o . . o o . . . o . . . o . o o o . o . o o . . o o o o . o . . o o o o . o o o pgpuY7CHHxrRQ.pgp Description: PGP signature ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] urandom vs random
On Sun, Aug 18, 2013 at 10:14 AM, Ben Laurie b...@links.org wrote: ... my advice is that you probably should not run Linux if you need strong randomness. i am surprised this has not surfaced more often in this thread: if you need good entropy: use a hardware entropy generator! also use a userspace entropy collector like dakarand or haveged, use a userspace entropy daemon for seeding system entropy pool (/dev/random) from hardware sources (like /dev/hw[_-]?random, unless you trust RDRAND ;) this is true no matter what operating system you use, where on a clean boot in a headless system you must choose between denial of service or silent insecurity. not to mention being under served in unexpected high usage situations, like initializing full disk crypto volumes with /dev/random or extremely high volume web server endpoints with high entropy utilization requirements. if you are running virtual machines this implies virtio random devices or VM safe instructions (if you trust RDRAND ;) to provide strong entropy within the guest systems as well. not to mention proper administration to ensure you're saving seeds and not sharing pool state between instances, etc. over ten years ago i wrote a threaded entropy daemon for the C5XL XSTORE instruction that provided megabits of entropy from /dev/random after configuring the MSR for XSTORE, sanity checks in the mtrngd, and writing to /dev/random when poll indicated users had consumed entropy from the system, thus ensuring /dev/random never went dry. ten years later and still the state of the consumer, embedded, and enterprise markets is totally inadequate, with the one recent ray of hope (RDRAND) intentionally obfuscated in a way that threatens trust. WTF in short, if you are not doing one or more of the following: - hardware rng with userspace daemon for hw rng - userspace entropy collector (haveged, dakarand, others) - securely seeded and re-seeded CSRNG (for VMs with boot and runtime entropy passing) you are doing it wrong. it is just a matter of risk/cost to exploit your use of randomness! (and the above does not mitigate your risk, it merely makes other risks your new weakest link, of course ;) ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] urandom vs random
On 17/08/13 10:57 AM, Peter Gutmann wrote: Nico Williams n...@cryptonector.com writes: It might be useful to think of what a good API would be. The problem isn't the API, it's the fact that you've got two mutually exclusive requirements, the security geeks want the (P)RNG to block until enough entropy is available, everyone else wants execution to continue without being blocked. In other words a failure of security is preferred to a failure of functionality. Until you resolve that conflict, no API (re)design is going to help you. (not answering the posts sepcifically but) the rule of thumb I've always used is this: If you don't care so much about security then use the tools that are provided, and suffer an occasional glitch. Don't worry too much about the glitches coz your business already told you, you don't care too much about the security / randomness. All those cypherpunkian arguments can go to hell, you've got customers to care for. OTOH, if you care a lot, then you have to write your own. The design is now very well established. Many sources - mixer/pool - deterministic PRNG. It's really not that hard, this is an intern level project, folks. In result, if you care enough to argue about random v. urandom then you already put yourself in the second camp, and your problem is solved. Just use urandom and collect some other sources yourself. You no longer care. iang ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] urandom vs random
On 17 August 2013 06:01, ianG i...@iang.org wrote: On 17/08/13 10:57 AM, Peter Gutmann wrote: Nico Williams n...@cryptonector.com writes: It might be useful to think of what a good API would be. The problem isn't the API, it's the fact that you've got two mutually exclusive requirements, the security geeks want the (P)RNG to block until enough entropy is available, everyone else wants execution to continue without being blocked. In other words a failure of security is preferred to a failure of functionality. Until you resolve that conflict, no API (re)design is going to help you. (not answering the posts sepcifically but) the rule of thumb I've always used is this: If you don't care so much about security then use the tools that are provided, and suffer an occasional glitch. Don't worry too much about the glitches coz your business already told you, you don't care too much about the security / randomness. All those cypherpunkian arguments can go to hell, you've got customers to care for. OTOH, if you care a lot, then you have to write your own. The design is now very well established. Many sources - mixer/pool - deterministic PRNG. It's really not that hard, this is an intern level project, folks. In result, if you care enough to argue about random v. urandom then you already put yourself in the second camp, and your problem is solved. Just use urandom and collect some other sources yourself. You no longer care. That's terrible advice. Implement your own crypto of any sort widely leads to complete fail, as we see repeatedly. Also, if there are other sources, why are they not being fed in to the system PRNG? iang __**_ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/**mailman/listinfo/cryptographyhttp://lists.randombit.net/mailman/listinfo/cryptography ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] urandom vs random
On 17/08/13 14:46 PM, Ben Laurie wrote: On 17 August 2013 06:01, ianG i...@iang.org mailto:i...@iang.org wrote: On 17/08/13 10:57 AM, Peter Gutmann wrote: Nico Williams n...@cryptonector.com mailto:n...@cryptonector.com writes: It might be useful to think of what a good API would be. The problem isn't the API, it's the fact that you've got two mutually exclusive requirements, the security geeks want the (P)RNG to block until enough entropy is available, everyone else wants execution to continue without being blocked. In other words a failure of security is preferred to a failure of functionality. Until you resolve that conflict, no API (re)design is going to help you. (not answering the posts sepcifically but) the rule of thumb I've always used is this: If you don't care so much about security then use the tools that are provided, and suffer an occasional glitch. Don't worry too much about the glitches coz your business already told you, you don't care too much about the security / randomness. All those cypherpunkian arguments can go to hell, you've got customers to care for. OTOH, if you care a lot, then you have to write your own. The design is now very well established. Many sources - mixer/pool - deterministic PRNG. It's really not that hard, this is an intern level project, folks. In result, if you care enough to argue about random v. urandom then you already put yourself in the second camp, and your problem is solved. Just use urandom and collect some other sources yourself. You no longer care. That's terrible advice. Implement your own crypto of any sort widely leads to complete fail, as we see repeatedly. :) Perhaps the distinction is that, if you care, when you repeatedly fail then you can repeatedly fix it. OTOH, if you're using external crypto, you're up the creek without a paddle. Also, if there are other sources, why are they not being fed in to the system PRNG? I agree in principle, but reality slaps us around a bit: Linux and BSD can't agree on the basic definitions of urandom and random. Some don't agree whether Intel's RNG is safe or not for Linux purposes. Zooko Jon don't agree whether open source is a sufficient / necessary proof. And, as you say, FIPS don't agree with anyone: Amusing story: FIPS 140 requires self-tests on the PRNG. There was a bug in FIPS OpenSSL once where the self-test mode got stuck on and so no entropy was fed into the PRNG. Also, back when I was doing FIPS 140 they made me remove some of the entropy feeds into the PRNG - particularly ones that protect against pool duplication over forks. iang ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] urandom vs random
On 17 August 2013 08:05, ianG i...@iang.org wrote: On 17/08/13 14:46 PM, Ben Laurie wrote: On 17 August 2013 06:01, ianG i...@iang.org mailto:i...@iang.org wrote: On 17/08/13 10:57 AM, Peter Gutmann wrote: Nico Williams n...@cryptonector.com mailto:n...@cryptonector.com** writes: It might be useful to think of what a good API would be. The problem isn't the API, it's the fact that you've got two mutually exclusive requirements, the security geeks want the (P)RNG to block until enough entropy is available, everyone else wants execution to continue without being blocked. In other words a failure of security is preferred to a failure of functionality. Until you resolve that conflict, no API (re)design is going to help you. (not answering the posts sepcifically but) the rule of thumb I've always used is this: If you don't care so much about security then use the tools that are provided, and suffer an occasional glitch. Don't worry too much about the glitches coz your business already told you, you don't care too much about the security / randomness. All those cypherpunkian arguments can go to hell, you've got customers to care for. OTOH, if you care a lot, then you have to write your own. The design is now very well established. Many sources - mixer/pool - deterministic PRNG. It's really not that hard, this is an intern level project, folks. In result, if you care enough to argue about random v. urandom then you already put yourself in the second camp, and your problem is solved. Just use urandom and collect some other sources yourself. You no longer care. That's terrible advice. Implement your own crypto of any sort widely leads to complete fail, as we see repeatedly. :) Perhaps the distinction is that, if you care, when you repeatedly fail then you can repeatedly fix it. OTOH, if you're using external crypto, you're up the creek without a paddle. What external crypto can you not fix? Windows? Then don't use Windows. You can fix any crypto in Linux or FreeBSD. Also, if there are other sources, why are they not being fed in to the system PRNG? I agree in principle, but reality slaps us around a bit: Linux and BSD can't agree on the basic definitions of urandom and random. So what? BSD's definition is superior. Linux should fix their RNG. Or these people who you think should implement their own should. Or they could just switch to BSD. Some don't agree whether Intel's RNG is safe or not for Linux purposes. All entropy feeds are safe. Zooko Jon don't agree whether open source is a sufficient / necessary proof. Yet they're both selling it. And, as you say, FIPS don't agree with anyone: Again: so what? Amusing story: FIPS 140 requires self-tests on the PRNG. There was a bug in FIPS OpenSSL once where the self-test mode got stuck on and so no entropy was fed into the PRNG. Also, back when I was doing FIPS 140 they made me remove some of the entropy feeds into the PRNG - particularly ones that protect against pool duplication over forks. iang ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] urandom vs random
On Sat, Aug 17, 2013 at 7:46 AM, Ben Laurie b...@links.org wrote: ... Also, if there are other sources, why are they not being fed in to the system PRNG? Linux 3.x kernels decided to stop using IRQ interrupts (removal of the IRQF_SAMPLE_RANDOM flag, without an alternative to gather entropy). [PATCH 17/17] random: final removal of IRQF_SAMPLE_RANDOM, http://lkml.indiana.edu/hypermail/linux/kernel/1207.2/01043.html. Jeff ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] urandom vs random
On Fri, Aug 16, 2013 at 11:07 AM, Aaron Toponce aaron.topo...@gmail.com wrote: The /dev/urandom device in the Linux kernel uses the Yarrow pseudo random number generator when the entropy pool has been exhausted. No, it doesn't, or at least did not last time I looked at the code, a few months ago. There are similaities, but also large differences. It turns out, getting good, high quality, true random, and chaotic data into your kernel isn't really at all that difficult. All you need to do, is rely in quantum chas, which is really the only true source for random, as much as random can get. Some things people have done: * Tuned their radio to atmospheric noise, and fed it into their kernel through their sound card. * Created reverse PNL junctions, timing electron jumps. * Timing radioactive decay using Americium-241, common in everyday household smoke detectors. * Opening up the CCD on a web camera fully in a completely dark box. * Termal noise from resistors. * Clock drift from quartz-based clocks and power fluctuations. My program to deal with this (which needs more analysis before it should be entirely trusted) and a paper which discusses it and several alternatives are at: ftp://ftp.cs.sjtu.edu.cn:990/sandy/maxwell/ At any event, using /dev/urandom is perfectly secure, as the Yarrow algorithm has proven itself over time to withstand practical attacks. So, let's dispel the myth that using /dev/urandom is insecure. :) Yes. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] urandom vs random
On 17 August 2013 10:09, Jeffrey Walton noloa...@gmail.com wrote: On Sat, Aug 17, 2013 at 7:46 AM, Ben Laurie b...@links.org wrote: ... Also, if there are other sources, why are they not being fed in to the system PRNG? Linux 3.x kernels decided to stop using IRQ interrupts (removal of the IRQF_SAMPLE_RANDOM flag, without an alternative to gather entropy). [PATCH 17/17] random: final removal of IRQF_SAMPLE_RANDOM, http://lkml.indiana.edu/hypermail/linux/kernel/1207.2/01043.html. I haven't studied the Linux PRNG, but my casual understanding is it does not deal well with useless input. This is obviously a defect. Jeff ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] urandom vs random
On Sat, Aug 17, 2013 at 6:39 PM, Sandy Harris sandyinch...@gmail.comwrote: shawn wilson ag4ve...@gmail.com wrote: I thought that decent crypto programs (openssh, openssl, tls suites) should read from random so they stay secure and don't start generating /insecure/ data when entropy runs low. (Talking about Linux, the only system where I know the details) urandom uses cryptographically strong mixing (SHA-1) and has enormous state, so it should be secure barring pathological cases like the router vendors whose version of Linux failed to initialise things properly or an enemy who already has root on your system so he/she can look at kernel internals. (and that enemy has much better targets to go after). IMHO I found related to this discussion this article on LWN ( https://lwn.net/Articles/525459/http://www.linkedin.com/redirect?url=https%3A%2F%2Flwn%2Enet%2FArticles%2F525459%2Furlhash=Pvmd_t=tracking_anet) , which describes the developments in the recent years on the generation of random numbers in the linux kernel. In particular, it discusses the talk Do not Play Dice With Random Numbers by Peter Alvin at LinuxCon Europe 2012 ( https://events.linuxfoundation.org/images/stories/pdf/lceu2012_anvin.pdfhttp://www.linkedin.com/redirect?url=https%3A%2F%2Fevents%2Elinuxfoundation%2Eorg%2Fimages%2Fstories%2Fpdf%2Flceu2012_anvin%2Epdfurlhash=K2Ee_t=tracking_anet ) Randomness is a subtle property. To illustrated this, Peter displayed a photograph of three icosahedral says That He'd thrown at home, saying here, if you need a random number, you can use 846. Why does not this work , he asked. First of all, a random number is only random ounces. Additions in, it is only random until we know what it is. These facts are not the same thing. Peter Noted That It is possible to misuse by a random number reusing it, this can lead to breaches in security protocols. Best Regards ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] urandom vs random
On 2013-08-17 5:57 PM, Peter Gutmann wrote: Nico Williams n...@cryptonector.com writes: It might be useful to think of what a good API would be. The problem isn't the API, it's the fact that you've got two mutually exclusive requirements, the security geeks want the (P)RNG to block until enough entropy is available, everyone else wants execution to continue without being blocked. In other words a failure of security is preferred to a failure of functionality. Until you resolve that conflict, no API (re)design is going to help you. The security geeks are the only people who want to use these. If on some systems urandom is fixed to not block at startup, cannot use it portably. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] urandom vs random
On 2013-08-17 10:12 PM, Ben Laurie wrote: What external crypto can you not fix? Windows? Then don't use Windows. You can fix any crypto in Linux or FreeBSD. No you cannot. So what? BSD's definition is superior. Linux should fix their RNG. Or these people who you think should implement their own should. Or they could just switch to BSD. That it does not, implicitly admits that you, Ben Laurie, cannot fix linux. We want that all implementations of /dev/random and /dev/urandom behave the same, and that they behave correctly on all machines. We don't have that. Hence the need for each implementer to reinvent the wheel. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] urandom vs random
yersinia yersinia.spi...@gmail.com writes: To illustrated this, Peter displayed a photograph of three icosahedral says That He'd thrown at home, saying here, if you need a random number, you can use 846. And there's the problem, he used a D20 so there's a bias in the results. If he'd used a D16 like this one, http://farm5.staticflickr.com/4056/4423369473_45e6fee61f_z.jpg, then there wouldn't be a problem. I keep 8D16 on my desk for just this purpose, two rolls and I've got an AES key. Peter. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] urandom vs random
I think the programs block when reading from random, if the kernel doesnt have enough entropy. When reading from urandom, that is not the case. Basically the internal pool is reused to generate pseudo random bits so that the call doesnt need to block. As far as I know, there is no measure like 50 or so for /dev/random. On 16-Aug-2013, at 6:32 AM, shawn wilson ag4ve...@gmail.com wrote: I thought that decent crypto programs (openssh, openssl, tls suites) should read from random so they stay secure and don't start generating /insecure/ data when entropy runs low. The only way I could see this as being a smart thing to do is if these programs also looked at how much entropy the kernel had and stopped when it got ~50 or so. Is this the way things are done when these programs use urandom or what? ___ 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] urandom vs random
On Fri, Aug 16, 2013 at 10:03 AM, Swair Mehta swairme...@gmail.com wrote: As far as I know, there is no measure like 50 or so for /dev/random. /proc/sys/kernel/random/entropy_avail ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] urandom vs random
On Fri, Aug 16, 2013 at 6:32 AM, shawn wilson ag4ve...@gmail.com wrote: I thought that decent crypto programs (openssh, openssl, tls suites) should read from random so they stay secure and don't start generating /insecure/ data when entropy runs low. This presumes that urandom is somehow more insecure, which is not the case despite the ancient scare-language in the manpage. The security of all stream ciphers rests in secure CSPRNGs. Meanwhile, /dev/random is not robust: https://cs.nyu.edu/~dodis/ps/rng.pdf -- Tony Arcieri ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] urandom vs random
On Fri, Aug 16, 2013 at 11:42 AM, Tony Arcieri basc...@gmail.com wrote: On Fri, Aug 16, 2013 at 6:32 AM, shawn wilson ag4ve...@gmail.com wrote: I thought that decent crypto programs (openssh, openssl, tls suites) should read from random so they stay secure and don't start generating /insecure/ data when entropy runs low. This presumes that urandom is somehow more insecure, which is not the case despite the ancient scare-language in the manpage. The security of all stream ciphers rests in secure CSPRNGs. Meanwhile, /dev/random is not robust: https://cs.nyu.edu/~One of the prdodis/ps/rng.pdfhttps://cs.nyu.edu/~dodis/ps/rng.pdf -- Tony Arcieri Not for nothing, but that refers to both random and urandom, showing one problem with the entropy estimation, and another with the pool mixing function. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] urandom vs random
On Fri, Aug 16, 2013 at 12:03 PM, Tony Arcieri basc...@gmail.com wrote: On Fri, Aug 16, 2013 at 8:47 AM, Patrick Mylund Nielsen cryptogra...@patrickmylund.com wrote: Not for nothing, but that refers to both random and urandom, showing one problem with the entropy estimation, and another with the pool mixing function. Finally, we propose a simple and very eļ¬cient PRNG construction that is provably robust in our new and stronger adversarial model. We therefore recommend to use this construction whenever a PRNG with input is used for cryptography. Yes, but they aren't talking about urandom. Your reply made it sound like random is weak, but the paper points to both (as urandom is seeded by random), and they propose a new AES-based PRNG that accumulates entropy properly. Here's the whole conclusion: We have proposed a new property for PRNG with input, that captures how it should accumulate the entropy of the input data into the internal state. This property actually expresses the real expected behavior of a PRNG after a state compromise, where it is expected that the PRNG quickly recovers enough entropy. We gave a precise assessment of Linux PRNG /dev/random and /dev/urandom security. In particular, we prove that these PRNGs are not robust. These properties are due to the behavior of the entropy estimator and the mixing function used to refresh its internal state. As pointed by Barak and Halevi [BH05], who advise against using run-time entropy estimation, we have shown vulnerabilities on the entropy estimator due to its use when data is transferred between pools in Linux PRNG. We therefore recommend that the functions of a PRNG do not rely on such an estimator. Finally, we proposed a PRNG with input construction that meets our new property in the standard model. We therefore recommend to use this construction whenever a PRNG with input is used for cryptography And from the introduction: On a practical side, we give a precise assessment of the security of the two Linux PRNGs, /dev/random and /dev/urandom. In particular, we prove that these PRNGs are not robust and do not accumulate entropy properly. These properties are due to the behavior of the entropy estimator and the internal mixing function of the Linux PRNGs. We also analyze the PRNG with input proposed by Barak and Halevi. This scheme was proven robust in [BH05] but we prove that it does not generically satisfy our expected property of entropy accumulation. On the positive side, we propose a PRNG construction that is robust in the standard model and in our new stronger adversarial model. There is a much more in-depth comparison starting in section 5.1. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] urandom vs random
On Fri, Aug 16, 2013 at 9:18 AM, Patrick Mylund Nielsen cryptogra...@patrickmylund.com wrote: Yes, but they aren't talking about urandom. Your reply made it sound like random is weak, but the paper points to both (as urandom is seeded by random), and they propose a new AES-based PRNG that accumulates entropy properly. I'm not sure if you feel the same way, but the opinion of many uneducated observers[1] seems to be that using a PRNG at all in these contexts is insecure when that is absolutely not the case, and for the most part there isn't a meaningful difference between the security of random vs urandom except that random will run out of entropy. The urandom is insecure claims are specifically what I was trying to challenge, and I hope this paper helps drive it home. If urandom is insecure it isn't more so than /dev/random [1]: http://arstechnica.com/security/2013/08/google-confirms-critical-android-crypto-flaw-used-in-5700-bitcoin-heist/?comments=1post=25102733#comment-25102733 -- Tony Arcieri ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] urandom vs random
On Fri, Aug 16, 2013 at 3:30 PM, Tony Arcieri basc...@gmail.com wrote: On Fri, Aug 16, 2013 at 9:18 AM, Patrick Mylund Nielsen cryptogra...@patrickmylund.com wrote: Yes, but they aren't talking about urandom. Your reply made it sound like random is weak, but the paper points to both (as urandom is seeded by random), and they propose a new AES-based PRNG that accumulates entropy properly. I'm not sure if you feel the same way, but the opinion of many uneducated observers[1] seems to be that using a PRNG at all in these contexts is insecure when that is absolutely not the case, and for the most part there isn't a meaningful difference between the security of random vs urandom except that random will run out of entropy. Ignoring the veiled insult: I don't, but I still recognize that they're not identical (at least on Linux.) There's no meaningful difference in most cases, i.e. when nobody's observing the output, or if the CSPRNG has no biases. Using /dev/urandom in general is fine. Either way, that's beside the point. The urandom is insecure claims are specifically what I was trying to challenge, and I hope this paper helps drive it home. If urandom is insecure it isn't more so than /dev/random You replied with a link to a paper that states that both /dev/random and /dev/urandom have the same weaknesses, and said that /dev/random isn't robust. Neither of them are, so what the paper drove home is that both have vulnerabilities, not that /dev/random is worse than /dev/urandom (which must clearly be false since /dev/urandom is a PRNG seeded by /dev/random.) That is all I'm pointing out. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] urandom vs random
On Fri, Aug 16, 2013 at 12:49 PM, Patrick Mylund Nielsen cryptogra...@patrickmylund.com wrote: You replied with a link to a paper that states that both /dev/random and /dev/urandom have the same weaknesses, and said that /dev/random isn't robust. I was quoting the title of the paper in the context of a thread in which someone claimed that /dev/random should be used in lieu of /dev/random. That's all I was pointing out. -- Tony Arcieri ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] urandom vs random
On Fri, Aug 16, 2013 at 12:55 PM, Tony Arcieri basc...@gmail.com wrote: I was quoting the title of the paper in the context of a thread in which someone claimed that /dev/random should be used in lieu of /dev/random. That's all I was pointing out. Blah, /dev/urandom... -- Tony Arcieri ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] urandom vs random
Aaron Toponce writes: Cryptographers don't like the idea that it's possible, even if it's excessively remote, and highly unprobable. This is why you see suggestions to use /dev/random for long term SSH, SSL and OpenPGP keys. Cryptographers are certainly not responsible for this superstitious nonsense. Think about this for a moment: whoever wrote the /dev/random manual page seems to simultaneously believe that (1) we can't figure out how to deterministically expand one 256-bit /dev/random output into an endless stream of unpredictable keys (this is what we need from urandom), but (2) we _can_ figure out how to use a single key to safely encrypt many messages (this is what we need from SSL, PGP, etc.). For a cryptographer this doesn't even pass the laugh test. I'm not saying that /dev/urandom has a perfect API. It's disappointingly common for vendors to deploy devices where the randomness pool has never been initialized; BSD /dev/urandom catches this configuration bug by blocking, but Linux /dev/urandom (unlike Linux /dev/random) spews predictable data, causing (e.g.) the widespread RSA security failures documented on http://factorable.net. But fixing this configuration bug has nothing to do with the /dev/random superstitions. ---D. J. Bernstein Research Professor, Computer Science, University of Illinois at Chicago ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] urandom vs random
On Fri, Aug 16, 2013 at 7:24 PM, D. J. Bernstein d...@cr.yp.to wrote: I'm not saying that /dev/urandom has a perfect API. [...] It might be useful to think of what a good API would be. I've thought before that the Unix everything-as-a-file philosophy makes for lame entropy APIs, and yet it's what we have to work with... I'd like something like /dev/urandom128 - min. 128 bits of real entropy in the pool. I'd also wish open(2) of AF_LOCAL socket names were the same as a connect(2) on the same thing, and to block like named pipe opens do (why on Earth is this not so? what could possibly break if it were so? considering that named pipe opens block... one would think nothing could break). Then we could have each open of /dev/prngN result in a PRNG octet stream seeded by N bits of real entropy. (I saw a blog post recently about using AF_LOCAL sockets as PID files. Making open(2) of them == connect(2) to them would make that an awesome idea.) Nico -- ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] urandom vs random
At startup, likely to be short of entropy. Actual behavior, and even existence, of /dev/random and /dev/urandom varies substantially from one implementation to another. If /dev/random blocks when short of entropy, then likely to block at startup, which is good. Services that need entropy do not need to start immediately. If they take a while to come up, no big deal. If /dev/urandom seeded at startup, and then seeded no further, bad, but not very bad. If /dev/urandom seeded at startup from /dev/random, then should block at startup. If /dev/urandom never blocks, bad. Should block at startup waiting to receive 160 bits from /dev/random, and never block again. Ron Peterson reports /dev/random not very random http://bytes.com/topic/c/answers/219952-dev-urandom-vs-dev-random ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] urandom vs random
On Fri, Aug 16, 2013 at 10:01 PM, James A. Donald jam...@echeque.com wrote: If /dev/urandom seeded at startup, and then seeded no further, bad, but not very bad. If /dev/urandom seeded at startup from /dev/random, then should block at startup. If /dev/urandom never blocks, bad. Should block at startup waiting to receive 160 bits from /dev/random, and never block again. On 2013-08-17 12:33 PM, shawn wilson wrote: I don't follow this - I understand why lack of entropy should block urandom but, why shouldn't it block on a running system that low_bound? Once /dev/urandom has 160bits of true randomness, can generate cryptographically strong pseudo randomness for an unenumerably long time. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] urandom vs random
On Fri, Aug 16, 2013 at 10:33:11PM -0400, shawn wilson wrote: On Fri, Aug 16, 2013 at 10:01 PM, James A. Donald jam...@echeque.com wrote: At startup, likely to be short of entropy. If /dev/urandom seeded at startup, and then seeded no further, bad, but not very bad. If /dev/urandom seeded at startup from /dev/random, then should block at startup. If /dev/urandom never blocks, bad. Should block at startup waiting to receive 160 bits from /dev/random, and never block again. I don't follow this - I understand why lack of entropy should block urandom but, why shouldn't it block on a running system that low_bound? Please explain what it means, exactly, to reduce the amount of entropy in the system in question. Emphasis on exactly. Thor ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
