Hi Rob, 2016-07-05 4:23 GMT+02:00 Rob Landley <r...@landley.net>: > On 07/04/2016 11:08 AM, Etienne Champetier wrote: >> 2016-07-04 17:02 GMT+02:00 Denys Vlasenko <vda.li...@googlemail.com>: >>> On Mon, Jul 4, 2016 at 11:00 AM, Etienne Champetier >>> <champetier.etie...@gmail.com> wrote: >>>>> BTW, I know that security people would scream bloody murder, >>>>> but wouldn't >>>>> >>>>> cd /proc && cat cpuinfo meminfo stat interrupts diskstats slabinfo >>>>> schedstat buddyinfo >/dev/random >>>>> >>>>> in practice work quite satisfactorily for adding some entropy at boot >>>>> time? >>>> >>>> Your cat /proc/* will be almost identical each boot, >>> >>> Yes, at boot it is somewhat likely, although I'd like someone >>> to experiment on a real system. >> >> I will repeat myself, > > Yes, you have been. > >> in crypto you prove that it's safe, not the other way around > > This is not the main objection. > > Linux has provided /dev/random and /dev/urandom for a couple decades > now. One blocks when its internal accounting believes it hasn't got > sufficient entropy to be NSA-proof unpredictable, the other provides > pseudo-rng output that's continually reseeded from /dev/random when > there's entropy there.
The problem is at the start of the device, you read from a partially seeded /dev/urandom, which lead to Bastien problem, duplicate ssh keys. > > Now there's a new API that's a system call rather than reading from the > /proc file. It is drawing from the same pool, and using the same > block/nonblock logic for entropy accounting. not exactly, as i said in my mail of 29 june 2016 at 17:04: you have - /dev/urandom, which never block - getrandom(), which block until /dev/urandom is properly initialized (system wide), then never block again and read from /dev/urandom - /dev/random, which only start it initialization after getrandom() unblock, and block when it estimates entropy is low > > You've implied that this new API can block until it's initialized, which > reading from /dev/random can already do, and presumably > select/poll/inotify could do on /dev/random without consuming entropy. As shown in my mail from 29 june 2016 at 15:54 [ 14.321536] ### getrandom ### [ 42.603677] ### dd ### getrandom() wait until /dev/urandom is initialized, which can be way before /dev/random is initialized > I gave a trivial command line example allowing an init script to block > waiting for the entropy pool to be initialized, with a timeout that > continues on after a reasonable time period if it isn't. I don't want to timeout, I want to wait until /dev/urandom is initialized to be "crypto safe" > Yes it read one > byte from the entropy pool because it was off the top of my head and I > didn't want to look at the inotifyd --help output and experiment to make > sure that's wired up You don't want inotify but select() or poll(), is there such utility in busybox? (real question, haven't found) > because in the past 15 years it's never been a > _problem_ for me. See Bastian mail again, this can be a problem for other > You've _also_ implied that this new API can provide "good enough" random > information before the random pool is initialized, To be sure we are on the same page here, getrandom() provides cryptographically secure random numbers from fully initialized /dev/urandom pool, before /dev/random pool is initialized, but they are still cryptographically secure. If you think /dev/random is more secure than getrandom() (ie /dev/urandom properly initialized), here is my mail from 30 june 2016 at 10:12: a good read http://www.2uo.de/myths-about-urandom/ Also https://en.wikipedia.org/wiki//dev/random Is there any serious argument that adding new entropy all the time is a good thing? The Linux /dev/urandom manual page claims that without new entropy the user is "theoretically vulnerable to a cryptographic attack",[16] but (as I've mentioned in various venues) this is a ludicrous argument—how can anyone simultaneously believe that we can't figure out how to deterministically expand one 256-bit secret into an endless stream of unpredictable keys (this is what we need from urandom), but we can figure out how to use a single key to safely encrypt many messages (this is what we need from SSL, PGP, etc.)? > which is what > /dev/urandom is for. You've implied that your new function call is > somehow superior to /dev/urandom because you're magically generating > entropy when the entropy pool is empty, in userspace, somehow. no no and no, this syscall block until /dev/urandom is initialized with 128bits of entropy good luck bruteforcing 2^128. Please read my 2 previous links again, and google for "myth about /dev/random". > (This is > probably what set people going "you can cat /proc/stuff to /dev/random > to feed crap into it and make it think it's got entropy which is at > least machine-local". Ways of dealing with an empty entropy pool.) cat into /dev/random mix what you give it but doesn't change the entropy estimation > > You have NOT explained what the point of your new interface is, what it > does that the existing one CAN'T do, get random bytes from /dev/urandom once it's properly seeded, and don't wait another 30s for /dev/random to unblock > or why it demands a new command line utility. getrandom() is a syscall and not a /proc file because they (kernel maintainers) wanted to fix another problem, file descriptor exhaustion. They didn't change /dev/urandom to block because this would have break userspace Please read https://lwn.net/Articles/605828/ This can be an applet or a new var in busybox shell ($GETRANDOM ?), but i can't right now from the shell access getrandom() or a similar behaviour > You haven't even justified the lower bar of modifying > existing C users (such as the shell's $RANDOM) to use the new API > instead. mail from 28 june 2016 at 23:56: getrandom() is blocking until properly initialized, i don't think we want such API change for $RANDOM > What is the POINT of your requested change? be able to read from /dev/urandom as soon as it is safe, not 30sec later (waiting for /dev/random) > > Your objection here seems to be that the unix "everything is a file" > interface is inefficient. That Plan 9 had the wrong idea and we should > all be using ioclts the way windows intended. no, not at all, kernel dev made it a syscall to prevent file descriptor exhaustion, i would have prefer to also have a /proc/getrandom file > > A similar move over in the ps space is https://lwn.net/Articles/633622/ > but they aren't proposing providing a "newps" command with a different > command line interface because API. They aren't expecting _users_ (such > as $RANDOM in the shell) to make this difference visible to end users. > > Why are you doing so? You may _have_ a reason, but you have yet to > communicate it. My goal is to read from /dev/urandom once it's properly seeded, if someone find me a solution in less than 207K i will take it, but I myself haven't found one (not a joke, i'm really open and ready to recognize a better solution) We can't make $RANDOM block else it will break many system Also we don't expect $RANDOM to be cryptographically secure, so no need to slow it down > >> Maybe kernel maintainers have good reasons to not mix them ... > > This is called an "appeal to authority", and you're doing it really > badly. You haven't got an argument so you say 4 out of 5 doctors prefer > your brand of gum, or it was endorsed by a celebrity spokesmodel. That > is not a REASON. If you have some time, there is a 2 months discussion on LKML to rework /dev/random, /dev/urandom, with 3 differents code proposals (and multiple versions) I can't sum it up (and i can't find the third one right now) https://lwn.net/Articles/684568/ https://lwn.net/Articles/686398/ > > The kernel maintainers added a vdso page with nonblocking userspace > gettimeofday() because it was lower latency than the system call. They > did not change the libc API for it, nor did anyone change the userspace > utilities because of this. Maybe they cared about latency here, I don't > know. That would be an example reason for them to merge it which would > NOT be a reason to create a new command line utility to use it. totally agree, but in getrandom() case it's a new behaviour, blocking, before we modify anything we have to ensure we will not break anything, that is why i'm introducing a new applet, not modifying existing code > > It is not OUR job to figure out this "maybe". You are arguing for a > change. If the kernel maintainers had good reasons, link us to their > explanation here. Also agree that it's my job to explain why busybox need it Link to the introduction to getrandom() https://lwn.net/Articles/605828/ getrandom is a new behaviour between /dev/urandom and /dev/random, so we can't transparently introduce it whitout breaking stuff. busybox target the embeded where /dev/urandom take a long time to be properly seeded > >>> BTW, add to that /proc/net/*. I mean, literally every file (unlike /proc/*, >>> where you don't want to read everything, "kcore" for one may be "a bit" >>> big). >>> There are ~50 files in /proc/net/. >>> Just one example. /proc/net/unix has Inode column for unix sockets. >>> Those depend on the order how processes have started at boot. >>> If there is at least some concurrency, inodes will contain some randomness. >> >> Network and radio can add some entropy, > > Externally visible entropy, if you're up against our out-of-control spy > agencies it doesn't necessarily help. (Although if they can park a block > away and point a yagi antenna at your router there's all sorts of fun > info they can get out of it if you haven't put the sucker in a farraday > cage.) You say it will contain some randomness, but how much? Why try to reinvent the wheel and risk being unsafe when we have an API that does exactly what we need > > Sigh, my grandfather worked for the NSA for 40 years (not _entirely_ > voluntarily, he did crypto during world war II and then they threatened > to draft him and put him on the ground in Korea if he didn't voluntarily > re-enlist for this new agency they were starting) and although he still > won't talk about most of what he did the one takeaway I did get is > nobody is really properly paranoid and I will never take any job that > requires any sort of security clearance because I refuse to get it on me. > > But sure, tell me about crypto. Go for it. Ok you know about crypto. I agree that cat /proc/* > /dev/urandom (or only a few /proc files) will add some entropy, but how much? am i crypto safe after? getrandom() API ensure that, do you? > >> everything else is pretty non random. >> You are reading the same flash, executing the same code, with the same >> 1 core cpu, and without a high precision timer. > > CPU cycle counter is a HPET. It's not a _good_ hpet, but the skew > between different timers in the system can provide jitter that can be > visible in the cycle counter. (It's not necessarily protected from other > users on the box, but if you've got other users on the box executing > arbitrary code on a _router_, you're doing it wrong.) And it's already what is used for the entropy collections > >> Crypto 101 is "don't roll your own crypto", the code you are >> suggesting will make you feel safe when in reality it will change >> almost nothing > > Yes, and that attitude is why heartbleed happened. Because > non-cryptographers never reviewed that code for over a decade and it > filled up with badly implemented crap. > > We are not proposing rolling our own crypto algorithms, we are proposing > staying with the tried and tested APIs to the existing kernel crypto > algorithms until such a time as someone convincingly argues that a new > way of doing things is a significant improvement. Which you have not yet > done. Using an unseeded CSPRNG is bad, and can leed to duplicate ssh key getrandom allow to wait until it's properly seeded without loosing time waiting for /dev/random getrandom is just standard /dev/urandom + waiting for it to be properly seeded You are proposing with Denys to cat /proc/<some files> > /dev/urandom that is what i call "rolling your own crypto", you are not sure it's safe but let's do it > >> Please also reread Bastian Bittorf, in his experience on 100 identical >> routers you have at least 2 identical ssh-key ! > > Which is why you mix in the mac address even though it's externally > visible. (The point of the hashing step is that mixing in known data > doesn't give you a known result as long as there's _some_ unknown data > in there. That at least makes the result unique and avoids collisions.) between 2 identical routers the mac might only have 1 bits of difference, i want 128, non externally visible, i want to be crypto safe, without loosing 30sec waiting for /dev/random > > Although on _top_ of that you really want to see a unique random block > on each machine (which is a manufacturing issue), and if you can't do > that then you can't give the machine a unique ssh host key either (yes > I've dealt with this manufacturing issue at more than one company). I can now patch the bin generating the ssh keys to use getrandom, or just call getrandom 1 > /dev/null before I call it and i'm safe > > AND if you have _any_ persistent storage you can save previous entropy > and feed it back in on next boot (keeping in mind that routers are > _never_ shut down properly and you don't want them to be brickable, but > you can reserve a small SD card partition or similar to update once the > entropy pool reports full and then daily after that. _IF_ this issue is > considered important enough, which depends on how much input engineers > have into the design vs management and marketing and legal.) I just pushed that into LEDE (OpenWrt) save a seed on startup once /dev/urandom is properly initialized (using getrandom()) not on shutdown because it's unreliable, not every day because it's useless > > That said, the fundamental problem of routers having limited entropy > sources is not going to be solved by ANY software. Your function call > api and /dev/random have the exact same problem there so it's a red > herring. Initializing the pool from locally unique sources and > preserving accumulated entropy across reboots are mitigation strategies, > not solutions to the fundamental problem. Your point is that /dev/random is broken? please report your findings upstream. Entropy collection is slower on embeded devices, so you have to wait for it, and getrandom() claim to do exactly that > > This is why so many web servers had sound cards in a PCI slot a decade > ago, not hooked up to anything but just feeding the low bits into the > entropy pool constantly. (Of course others argued that what they were > picking up was noise from inside the case and thus predictable if you > have the right machine specs, mathematicians, physicisits, and > supercomputers. Which the NSA probably does, but it would be way easier > for them to just go in and badusb the crash cart at the hosting facility.) > > People add hardware random generators to all sorts of processors these > days, but of course who trusts Intel's RNG not to be backdoored by the NSA? > >> You haven't answered my question, should i change the applet name to >> bbgetrandom ? > > You haven't answered OUR question: what is the point of your new applet? > > $RANDOM is built into the shell that's calling your applet. If your > applet is not called from the shell, it's probably called from a C > program, meaning you can call this new function yourself and shelling > out to a busybox applet to produce a random number from that context is > INSANE. I can't make $RANDOM block, it's a breaking API change I could introduce a new $GETRANDOM var if you think it's better? > > What is your use case? Why are you bothering to do this? > > It's entirely possible your new approach is superior, but you have not > successfully articulated _why_ yet. Would you like to try again? Of course :) After heartbleed openbsd people forked openssl in libressl, and started to clean things up, they saw that there was no good way to get entropy in the linux world (file descriptor exhaution), so they asked to something similar than the getentropy() bsd syscall, and getrandom() was born. Theodore Ts'o while at it added the possibility to block until /dev/urandom as been seeded with 128bits of entropy, specifically targetting embeded systems https://lwn.net/Articles/605828/ This is a new and pretty intrusive behavior, hence a new applet (or var) Don't hesitate if it still not clear enough Regards Etienne > > Rob _______________________________________________ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
