Hi David,
"Please, lets not conflate /dev/urandom with /dev/random."
Your assumptions about /dev/urandom properties and usage do not match real world. There are lots and lots of security-related SW packages that assume and absolutely *NEED* /dev/urandom to be a CSPRGN. This includes most, if not all, TLS implementations. Take a look of mbedTLS function mbedtls_platform_entropy_poll() for instance (a colleague recently ported mbedTLS to NuttX):
https://github.com/ARMmbed/mbedtls/blob/4e6248fa1515f3af01e7d0754b6690d90c2ea5d8/library/entropy_poll.c#L150<https://github.com/ARMmbed/mbedtls/blob/4e6248fa1515f3af01e7d0754b6690d90c2ea5d8/library/entropy_poll.c>
Worse example comes from LibreSSL's _rs_stir() function:
https://github.com/busterb/libressl/blob/089aaf7ad3c4c4c32d216b05e69a83d0f2f75140/crypto/compat/arc4random.c#L96
that first tries to read from /dev/urandom, and if that fails, falls back to getting somewhat predictable values from gettimeofdate() and getpid()!
Now that Greg has accepted your patch, a developer porting these libs (and many others) to NuttX needs to be extra careful to NOT use the default /dev/urandom
"isnt DES still OK?"
This is 2016. Plain DES should have died long ago. Please lets not add it into any new operating systems. NuttX is currently the best OS for IOT devices, but crypto and security need more work (I hope to contribute something if/when have the time).
Best Regards,
Juha Niskanen
________________________________
From: ***@yahoogroups.com <***@yahoogroups.com> on behalf of 'David S. Alessio' ***@gmail.com [nuttx] <***@yahoogroups.com>
Sent: Sunday, July 17, 2016 3:19:51 AM
To: ***@yahoogroups.com
Subject: Re: [nuttx] /dev/urandom
Hello Sebastien,
(please see comments below)
Best regards,
-david
On Jul 16, 2016, at 2:59 PM, Sebastien Lorquet ***@lorquet.fr<mailto:***@lorquet.fr> [nuttx] <***@yahoogroups.com<mailto:***@yahoogroups.com>> wrote:
Hello
Please forgive my rude choice of words, I probably have a lesser english knowledge than you may think :)
No worries. ;)
Also, your response clarified a lot of things, I dont think that my second email is useful now.
So if I understand correctly, you main idea is : linux urandom is good quality, nuttx is not linux, we dont need quality for nuttx urandom
?
It all depends on the application, but I dont want to allow perfect to become the enemy of good enough for the particular application in hand.
OK... lets forget Linux.
NuttX is not only for low-end microprocessors. On the contrary, it is more a RTOS for mid/high-end mcus. That's why I dont think that the argument about constrained memory holds.
I agree. But then well have to revisit the [my?] assumption that the same algorithm compile/execute on all MCUs.
Also, there comes my remark about IoT security: Accepting that urandom is NOT a CSPRNG clearly makes us go in the bad IoT security route, which I dont like at all.
If we continue this route, if HW AES is not available on all chips, would you recommend DES? (or, xor?)
My view is its all relative to the application and its attraction to hackers. Plenty of papers have been written on the advantages of AES over DES and 3DES, but if my application is measuring temperature in my water heater and sending the sensor data to a website that does nothing more than plot the data, isnt DES still OK?
As for xor, no, I wouldnt use it by itself. It works well when combined 1 or 2 other operations
Perhaps xor | rot13 | rot13 ?
However, I could admit that the range of supported targets is so wide that a correct PRNG is not doable everywhere.
Yes, thats a difficult constraint. I tried to strike a balance
How would you balance the constraints?
I would be okay if:
-we had multiple implementations (say: 2) for fast, non blocking random sources available at /dev/urandom
Im OK with 3, but not 15+ ;)
-the xor128 implementation was clearly marked as NOT CRYPTO SECURE in Config
I could not agree more! If we do this with xorshift128, NOT CRYPTO SECURE warnings should go everywhere.
How about:
1) xorshift128 (uses only uint32_t and would work well on mega128, z80, etc.)
2) xorshift128+ (uses uint64_t, passes BigCrush)
3) ?
Does anyone really want Fortuna? Why would this be a better design choice than an MCU with dedicated HW?
-we also make available a CSPRNG for bigger CPUs. A SHA-256 buffer is 32 bytes, a correct CSPRNG would not be the bigger NuttX subsystem.
Sure, this is acceptable.
Then we have the problem of how to properly seed and condition the PRNGs
What about this?
Sebastien
On 16/07/2016 23:38, David Alessio ***@yahoo.com<mailto:***@yahoo.com> [nuttx] wrote:
Sebastien,
(see comments below)
Regards,
-david
On Jul 16, 2016, at 1:57 AM, Sebastien Lorquet ***@lorquet.fr<mailto:***@lorquet.fr> [nuttx] <***@yahoogroups.com<mailto:***@yahoogroups.com>> wrote:
Hello,
I let everyone remember that security in the IoT is globally crap,
This is true and I feel your frustration, but its an non sequitur.
so please lets not add more crap in that field
Monsieur Sébastien, such statements are easy to misunderstand, but given that your English appears to be slightly better than my French, Ill cut you some slack ;)
On 15/07/2016 15:44, <mailto:***@ziggurat29.com> ***@ziggurat29.com<mailto:***@ziggurat29.com> [nuttx] wrote:
I second that the general assumption for /dev/urandom will be that is a CSPRNG. We do already have /dev/random (well, I guess it is dependent on there being a hardware rng underlying it).
Please, lets not conflate /dev/urandom with /dev/random. Traditionally, /dev/urandom has been as source of uniformly distributed pseudorandom numbers, fast, and non-blocking nothing more, nothing less.
One typical use is to wipe a 1GB drive:
dd if=/dev/urandom of=/dev/sda bs=1000 count=1000000
Create a garbage 1MB file:
dd if=/dev/urandom of=/mnt/usb/garbage.bin bs=1024 count=1024
If either or both of these supported a configurable option of:
* hardware source (requires chip support) (i.e. like as it is now for /dev/random)
* some generally suitable CSPRNG (as I believe Juha is suggesting)
* some non-CS rng (for convenience of those who don't care? as I believe David is suggesting)
* some externally provided implementation (for those who are picky, and particularly want, say Yarrow, as I am suggesting)
* /dev/urandom is simply a symlink to /dev/random (as FreeBSD actually does)
Then that might be ideal. Actually, then you could probably merge all the /dev/(u) random into one thing.
Same here, CSPRNG or nothing.
I would agree with you here, but *only* with respect to /dev/random
/dev/random, if it exists, *must* be cryptographically secure. And it should use a HW RNG.
But let me remind you something. Linux has entropy problems: There are no hardware RNG in normal desktop computers, but there is a need for enough "entropy" (unpredictable random bits) for security reasons (generation of RSA keys, openssl, ssh, etc). - we dont have most of this in NuttX.
Linux has many problems. And thats why I try to refrain from making references to Linux its just examining a pathological case...
(BTW: on my TODO list is to bring good crypto libs into the Nuttx build process)
So, linux gathers entropy from multiple low rate sources (keystrokes, mouse mouvements, disk IO - often, each event generates one good bit, or less), but this random data is very scarce. Because of this, directly reading /dev/ramdom will deplete the entropy too fast, so the /dev/urandom CSPRNG was added to allow generation of enough pseudorandom bits even if the real entropy has a far lower rate.
Here is a doc describing the linux RNGs: https://eprint.iacr.org/2006/086.pdf
Thanks for the link, but again, this is very Linux-specific.
Also, according to wikipedia: "On systems using the Linux kernel, programs needing significant amounts of random data from /dev/urandom<https://en.wikipedia.org/wiki//dev/urandom> cannot co-exist with programs reading little data from /dev/random<https://en.wikipedia.org/wiki//dev/random>, as /dev/urandom depletes /dev/random whenever it is being read.[6]<https://en.wikipedia.org/wiki/Entropy_%28computing%29#cite_note-6>
This, again, is a Linux-specific implementation. /dev/random and /dev/urandom dont need to be related. Its just that typically the implementation of /dev/random builds on top of /dev/urandom and injects entropy...
Entropy manipulation is not trivial, you could introduce biases or discard entropy without paying attention.
Quite right; and I would argue against trying to implement a /dev/random with PRNG and entropy injection. If a project needs this, choose an appropriate MCU one that has a HW RNG (PIC32MZ, STM32F4xx, etc.).
However, on embedded platforms targeted by nuttx, the conditions are different:
-there are no low-rate system entropy sources such as the ones that makes random necessary
There are several use cases were an MCU either doesnt have HW RNG, or its too slow, but a source of fast decent random numbers is desired. Thats where /dev/urandom fits.
-there is often a hardware RNG of sufficient quality that will provide random bits at a high enough rate for key generation or stuff like that, when it's required at all (who really needs RSA key generation on a nuttx embedded platform?)
HW RNG is perfect for key generation, if needed, but it can be slow.
-if even more pseudorandom bits are required (with a hw rng, this is rare), then a proper CSPRNG such as Yarrow or another well designed generator should be used.
No, these are too heavy for a small MCU. Again, I would argue that if one needs that level of quality in a PRNG, choose an MCU with a HW RNG.
On 15/07/2016 19:58, 'Juha Niskanen (Haltian)' <mailto:***@haltian.com> ***@haltian.com<mailto:***@haltian.com> [nuttx] wrote:
"/dev/urandom is simply a symlink to /dev/random"
This is probably not bad, if the original program cannot be changed, which I doubt... the other option is to avoid /dev/urandom entirely, and use /dev/random instead.
I havent explored FreeBSD. But if /dev/random blocks, it may not be wrong, but it breaks the tradition that /dev/urandom doesnt block.
In NetBSD /dev/urandom doesnt block; and /dev/random has some fairly complicated entropy pool management...
I advise against yet another low quality RNG in NuttX.
Im happy to entertain an argument for a higher quality PRNG for /dev/urandom. But it has to:
compile on all supported architectures
be reasonably fast on those architectures
never block
libc random is completely different. It has to be available even without hardware RNG and no one with a sane mind would think it is cryptographically secure. It could be implemented by xorshift128 as a replacement of the current generator if we wanted a "slightly better", but still fast, generator.
And on this we agree.
Sebastien