Hi Thorsten -- Thanks for your positive feedback on Spritz, and your interest in seeing future developments.
There is no "spritz mailing list" or the like (yet); I'll let you know if we create one. We plan to publish an updated paper on Spritz within the next couple of weeks on the IACR eprint site: http://eprint.iacr.org/ Keep an eye for this. The algorithm will be the same, but the analysis and discussion should be improved, over the version that is now posted on my web site... Cheers, Ron On Thu, Sep 25, 2014 at 4:47 PM, Thorsten Glaser <[email protected]> wrote: > 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 > -- Ronald L. Rivest Room 32-G692, Stata Center, MIT, Cambridge MA 02139 Tel 617-253-5880, Email <[email protected]> http://people.csail.mit.edu/rivest
