From: Mok-Kong Shen on 21 Mar 2010 06:08 [Addendum] It may be mentioned that the motivation of using a pool of constituent PRNGs that are pseudo-randomly activated is in some sense akin to that of using a block cipher to generate different keys to encrpt different blocks of plaintext with another block cipher, namely to introduce "dynamics"/"variability" in order to foil some of analyst's well established and advanced techniques (see the thread "Introducing dynamics into block encrpytions"). For a concrete implementation, it may be desirable to provide possibility of "feedback" from encryption processing computations external to the compound PRNG. Useful could be: (1) activating the compound PRNG a number of times without generating external output (e.g. as sort of initialization), (2) modifying p, the index of the currently next PRNG of the pool to be activated, via adding or xoring a value, (3) activating all PRNGs of the pool once, without generating external output, (4) letting the master-PRNG re-seed all PRNGs of the pool, (5) letting the master-PRNG to completely re-generate the pool. As to the magnitudes of the coefficients of the permutation polynomials, it may be desirable to avoid using values in the outer 5% zones of [0, 2^32-1]. (A literature says that that's an advice of Knuth for polynomial PRNGs in general, though I haven't yet found that in his book where PRNGs are treated.) M. K. Shen
From: unruh on 21 Mar 2010 10:16 On 2010-03-21, Mok-Kong Shen <mok-kong.shen(a)t-online.de> wrote: > unruh wrote: > >> The purpose of all this is what? It is certainly not a fast prng. What >> do you want to use it for? > > It is certainly unfavourable in computing efficiency (especially > when compared to such PRNGs as RC4). The purpose is show that, if > one needs for whatever reasons a fairly secure (hard to predict) > PRNG of very long period and has to implement one oneself from scratch > (without having/consulting and/or relying on expert's opinions), that > seems to be one (there certainly might be several others) of the > 'practical' ways to go. (This is what I personally term the poorman's > situation.) No. The poor man's solution is just to use rc4. Easy to encode, reasonably secure, fast. It is like directing poor people to slog through the mud to get to the next village when there is a perfectly good road they can use. > > M. K. Shen >
From: Mok-Kong Shen on 21 Mar 2010 10:53 unruh wrote: > No. The poor man's solution is just to use rc4. Easy to encode, > reasonably secure, fast. It is like directing poor people to slog > through the mud to get to the next village when there is a perfectly > good road they can use. What if the poorman is "idiosyncratic" and doesn't trust the fame of products of crypto authorities? (Such psychology could be understandable, if one remembers the old "rumor" decades ago of a world-famous crypto firm that had a backdoor in cipherdevices delivered to a certain country.) I hope that he could also be satisfied with a scheme like the present one. M. K. Shen
First
|
Prev
|
Pages: 1 2 Prev: Test vectors for Diffie Hellman Next: On the classification of ciphers |