On 09/21/2014 10:02 PM, Thorsten Glaser wrote:
Lorenzo dixit:
Wait, wait - 1. MirBSD?
Of course.
tldr: this + the mention of slow computers made me misunderstand your
previous message.
2. what did you measure exactly?
Nothing, I just saw the comparative measurements in the paper.
Are you considering RS14 for /dev/random?
Of course not. Just for both /dev/arandom and userspace arc4random().
Making a portable arc4random()
No, I don’t do that because other operating systems don’t provide
sensible enough kernel interfaces. The closest one is OpenBSD,
but even theirs suck.
based on RS14 should be more than good enough for the portable
version of mksh, even in terms of speed - or did you stop using
arc4random() for $RANDOM because of this slow machines?
No, mksh’s $RANDOM does not need arc4random() and does not promise
it – I just use it when it’s convenient. I don’t use it on most OSes
because almost all OSes don’t provide good and easy to use kernel
interfaces to gather entropy, and I’d rather not have several fall‐
back mechanisms.
Oh, ok!
When I read about slow machines I misunderstood and thought you
considered using rs14 to make a portable arc4random() for use with
$RANDOM and rejected the idea because it was too slow; I went "wtf?" and
- well, if you reread my mail knowing what I had in mind it should make
sense now :)
Ie slowing down rndget() by a factor X has an impact which is much smaller than
X due to the shell having to parse over and over, not to mention that in real
usage you'd actually be doing something other than generating random numbers...
We need to separate several concerns here:
• do we use arc4random() for mksh, or rather, when
• what provides arc4random()
• arc4random() on MirBSD may or may not be using Spritz,
it currently uses aRC4
• arc4random() on OpenBSD used aRC4 and uses ChaCha20 now,
but lacks an interface to push back entropy to the kernel
• arc4random() is not native to any other OS, and all portable
implementations suck, both in themselves and because of their
underlying operating systems (e.g. Linux deprecating sysctl(),
and their new proposed getentropy syscall (incompatible to
OpenBSD’s new one) sucks)
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=c6e9d6f38894798696f23c8084ca7edbf16ee895
The real problem is that you can't count on getrandom() being there - eg
it's too new for my machine running debian sid... why they removed the
sysctl() without providing an alternative is beyond me instead.
Oh, btw - I can't find the link right now, but someone took the pain to
look at (and compare) many broken versions of portable functions,
including arc4random.
It was just plain horrible.
• what do we do in mksh if an OS absolutely cannot support
arc4random() (e.g. lack of /dev/urandom and similar)
The last point is actually why I’d say, we only use arc4random()
if “it’s there anyway”, which is basically OpenBSD and MirBSD
“period”. Everything else gets an LCG, and I’m seriously considering
removing all overhead and just using dumb mode there (that can also
easily be tested for). (And OpenBSD just doesn’t get the kernel
feedback, period. They asked for them to not get it, even.)
bye,
//mirabilos
