Dixi quod…
Its 1732 bit state beats the about 1700 bit of aRC4, too ;)
although that is due to the increase in registers.
And some of it is lost due to the CRUSH function, at least
OK. I slept over it, and I think that a Spritz-based
stretching RNG, to replace aRC4 in arc4random(), has
a bit more than 1476 bit and no more than 1604 bit of
entropy in its state, due to use of CRUSH.
This could probably be improved by changing SHUFFLE to:
⒈ local tmp1 = DRIP()
⒉ local tmp2 = DRIP()
⒊ local tmp3 = DRIP()
⒋ WHIP(2*N + tmp1)
⒌ tmp2 += DRIP()
⒍ tmp3 += DRIP()
⒎ CRUSH()
⒏ WHIP(2*N + tmp2)
⒐ tmp3 += DRIP()
⒑ CRUSH()
⒒ WHIP(2*N + tmp3)
⒓ a = 0
This is similar to the arc4random modifications we
have in MirBSD, which not only skips 12*256 bytes of
output after reseeding but also a somewhat random
amount, and skips randomly 1‥2 bytes for every call
to arc4random() and 1‥4 bytes for every 256 output
bytes in a call to arc4random_buf(), just to further
randomise (just like multiple readers of one pool,
such as the kernel /dev/arandom, improve the “pool
size” for every reader separately).
Since this is deterministic, it could probably be
also used in Spritz as stream cipher and hash ☺
@Ronald, Jacob: where can I keep informed about the
state of Spritz, e.g. review/cryptanalysis (just the
human-readable results please, not the academic details)?
I see it has potential to simplify our RNG setup,
especially due to the sponge construction, the ability
to mix reading and writing (which Keccak does not
really provide), and the AbsorbStop() function (nice!).
This way, I can get rid of the temporary 128-bit
“round hash” to spool incoming data, and just
feed data straight into Spritz.
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
