tl;dr: We probably should simplify the code (no promises
about $RANDOM other than its value area) and not export
$RANDOM any more, and only use arc4random-related functions
where really convenient, “lesser” OSes are SOL. We move
the task to get better random numbers on the script writers
(and provide a sample implementation already), except on
MirBSD, where it is convenient ☺ (but also probably only
useful to replace dice rolls to decide on what to have
for lunch that day).
Lorenzo dixit:
> I was wondering if there would be any trouble replacing the lcg with a
> generator whose state is __made__ of n>1 words - something like, off the top
> of
> my head, xor128, JKISS, you name it.
Something I really want is a sponge construct, like Keccak, but
one where you can constantly write to and read from.
Since this is out of the scope of mksh, I’m somewhat tempted to
remove the export and bring back the state we once had:
• if arc4random() exists on the system, always use that
• if arc4random() does not exist, just use an LCG with few
extra seeding (stack address, etc.) or none at all (since
the OSes without it likely also don’t have ASLR and so)
This has several downsides:
• we used to have set ±o arc4random
‣ one variant: constant, to see which one is in use
⇒ led to the LCG codepath being untested/buggy
‣ other variant: can enable/disable arc4random
⇒ code bloat, not much benefit
• if using arc4random(), we use arc4random_addrandom() to
feed assignments to $RANDOM back, but OpenBSD removed
the interface…
• we used to ship one, which wrote to /dev/urandom to feed
back to the kernel, but the Gentoo Linux people didn’t
like that
• using arc4random() on systems where it’s not in libc will
make it the packager’s choice, which we don’t like much
But we can just bite the bullet here and say “we use arc4random
if you have it, and otherwise you get something that always
produces the same output sequence for the same assignment to
RANDOM, and it’s your fault”. This a̲l̲s̲o̲ has a downside, namely
people expecting deterministic output again, if they program
and test on a “lesser” OS (one without arc4random), and we just
use arc4random_pushb_fast() macro on MirBSD for pushback, and
if it doesn’t exist (OpenBSD, Linux – also sorta lesser OSes)
there is no pushback…
As for “better” LCG-ish things: nah, it’s either cryptographically
sound (aRC4) or speed/convenience.
I think we’d be best off with an mksh not promising anything
about the quality of its $RANDOM, and using arc4random() only
where it is really convenient (e.g. on OpenBSD and MirBSD, the
libc malloc() uses it already anyway). We kinda don’t promise
anything in the manpage already… and it would shrink the code.
> Btw, agreed, arc4random should be everywhere.
Right. But I have a pure shell implementation for when people
really want it… example use:
https://www.teckids.org/gitweb/?p=verein.git;a=blob;f=util/projrand;h=80f3210cf77314c630086def1062958a528414ab;hb=HEAD
(Watch that space. I also already have the idea to add the
timing of the “Glücksfee” (person doing the lottery drawing
by hitting Return occasionally) to the arcfour state…)
> I didn't know urandom in linux had these kind of problems, but
It does…
> modern arc4random uses chacha20, which only requires 16/32 bytes for
> its keys.
N̲O̲T̲ “modern” but “OpenBSD’s latest”. This is not “modern”,
it just follows a worrisome trend – not only is DJB’s code
basically illegible (coding style) and incomprehensible to
non-mathematicians, but also unlicenced software and thus
violating http://www.openbsd.org/policy.html (especially
the last two paragraphs), as it both is not ultimately clear
whether DJB’s code is really in PD in the USA, and it most
certainly is not in PD in most other countries.
(DJB could fix that easily – others do – but refuses to
even acknowledge the problem we non-US-Americans have.
But then, his track record wrt. software licencing is
pretty… dirty.)
>> Anyway, I do not discuss upstream things like this in the
>> Debian bugtracker, as this is most definitely not a bug
>> in the package.
> You're totally right, sending emails is too easy - sorry :)
Thanks for agreeing, and sorry for taking a bit to respond.
bye,
//mirabilos
--
Yay for having to rewrite other people's Bash scripts because bash
suddenly stopped supporting the bash extensions they make use of
-- Tonnerre Lombard in #nosec
