Re: randomness (crypto?) code example wanted please?

[Alistair Crooks <agc%pkgsrc.org@localhost>]

I've seen a number of "workarounds" for random(3), including taking
bytes 2 and 3 "as they provide more randomness", taking bottom 16
bits, taking those values and using as seeds for something else, and
seeding by microseconds; hopefully we've grown out of the "seeding by
process ID" that we had quite some years ago.

In kernel, the Mersenne twister is used for IP ID numbers, and that
can be suitably seeded from the more crypto-minded side of the stable,
but still only produces 19K 32bit values before cycling, so useful for
maybe 14 or 15 bits, no more; seeding using it would be a better idea.

I implemented a form of integer Blum Blum Shub, it's in
othersrc/external/bsd/ibbs, but as dsl@ pointed out, it doesn't
produce enough numbers before cycling itself; although, when it
notices a cycle, it reseeds itself, so better than nothing. I thought
it would be an interesting discussion point as a whole; no-one wanted
to discuss :(

I think Martin's idea of sampling /dev/urandom is probably best, since
the crypto-based stuff will not be reproducible with a given seed.

Best,
Alistair

On 25 June 2017 at 09:10, Robert Elz <kre%munnari.oz.au@localhost> wrote:
>     Date:        Sun, 25 Jun 2017 15:22:07 +0100
>     From:        Roy Marples <roy%marples.name@localhost>
>     Message-ID:  <ee3739d2-462f-2fbb-1515-db4bc24d0fc8%marples.name@localhost>
>
>   | Don't count on that happening soon.
>   | http://austingroupbugs.net/view.php?id=859
>
> That one has been withdrawn, it is going nowhere at all.
>
> The current related issue is
>         http://austingroupbugs.net/view.php?id=1134
>
> which is being discussed "now" (that is, for the past couple of months
> at least) - and like everything security related, seems to be being side
> tracked by people who always want something better... but by blocking
> any request which improves things, but doesn't achieve perfection, manage
> to cause no improvement at all.
>
> I think I have heard it said (somewhere) that the biggest threat to
> good security is perfect security.
>
> At least that is what it looks like to me looking in from the outside.
> I generally avoid all security/crypto discussions, as I know nothing
> worth knowing about the field.
>
>   | All modern BSD's have arc4random (and most have arc4random_uniform) -
>   | some use something more modern like ChaCha, so it's just an interface
>   | really.
>
> Yes, I see, it just does not seem to meet the requirements (as you
> said in your second message.)
>
>   | Just like sh, dhcpcd can start very early .... sometimwes before enough
>   | entropy has been generated just to pull blindly from /dev/urandom
>   | because it can block - or did in the past; it might be fixed now.
>
> I am not too worried about that - sh will only fetch values from there
> if someone is actually referring to $RANDOM, none of the startup scripts
> do that, and I can't think of any reason they would - I mean who would
> want a system which randomly decided whether to mount the filesystems or
> not?
>
> If someone does want random numbers, and is not setting the seed themselves,
> then one might assume that they actually want numbers that are reasonably
> random, and so should be prepared to wait if required (if that is what
> happens.)
>
> kre
>
>