From: Mok-Kong Shen on

[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
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
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