Re: Is fork() hook ever possible?

On Mon, Nov 14, 2011, Andrey Chernov wrote:
> 1) We should use 
> 	mib[0] = CTL_KERN;
> 	mib[1] = KERN_ARND;
> 
> 	len = sizeof(rnd);
> 	sysctl(mib, 2, rnd, &len, NULL, 0);
> here instead of /dev/random, like OpenBSD did. It helps jails, and 
> re-stearing not happens too often in anycase. Obviously it minimizes 
> OpenBSD diffs too.

Yes, that was in my list of suggested follow-on work, but I don't
have time for it right now.

> > the IV.  In arc4_stir(), I also fixed the bug where the wrong
> > buffer size was being passed to arc4_addrandom(), resulting in
> > entropy loss.  That change should be committed separately.
> 
> 2) I already explain this moment before. There is no bug here but 
> intentional hack using time and pid entropy for stearing when read is 
> fail: time/pid are at the beginning of the struct, successful read happens 
> at the beginning of the struct too and beginning of the struct is passed 
> as the key too. Key is always fixed KEYSIZE bytes.
> 
> In your new patch you pass unneded stack garbadge at the beginning of the 
> struct (often 0-s) in case good entropy is successfully readed into 
> rdat.rnd, moreover, you pass more then KEYSIZE bytes - sizeof(rdat).

No, the "unneeded stack garbage" was passed in before.  The
difference is that previously you were calling arc4_addrandom()
with a 148-byte struct rdat and a length parameter of 128 bytes.
The result was that the last 20 bytes of the key obtained from
/dev/random were unused.

It's actually worrisome that you've got the predictable part of
the key (pid and timestamp) first.  The known-key attacks on RC4
that were used to break WEP rely on exactly this type of key.
Specifically, because of the way the key scheduling algorithm
works, the first few bytes of the state are strongly correlated
with the first few bytes of the key.

> 3) (optional) I think we can lover initial permutations from our 1024 to 
> at least OpenBSD's 256 here:
> 	for (i = 0; i < 1024; i++)
> 		(void)arc4_getbyte();
> In my initial commit attemps I post several references to publicly 
> available mathematical researches calculating estimated initial 
> permutation count, some paper allows even 128. They can be found in the 
> commit log.

The revision history shows that you changed that parameter from
256 to 1024 to 512 to 768 to 1024 again.  I'm not inclined to
change it yet again unless an actual cryptographer weighs in and
proscribes an appropriate level of paranoia.

For what it's worth, I believe the attack you cited in the
comments is unlikely to matter, assuming the initialization issue
I mentioned above is fixed.  arc4random() uses a larger-than-usual
key size (1024 bits instead of the 64-128 used in most RC4
implementations).  Thus, an attacker who can correlate the
keystream with the first few bytes of the key gains negligible
advantage, assuming that the key itself is random.  But I'm not
sufficiently well versed in the RC4 key schedule to preach that as
the gospel truth.