[Cryptography] "Practical Construction and Analysis of Pseudo-Randomness Primitives"

[Tom Mitchell]

On Mon, Jun 21, 2021 at 6:23 PM John Denker via cryptography <
cryptography at metzdowd.com> wrote:

> On 6/21/21 11:15 AM, Caleb Cannon wrote:
>
> > I wrote a PRNGG. That is, a pseudo random number generator generator.
>
> Ruh roh.
>
> > the part that I had the most trouble with was testing the quality of
> > the random number generation.
>
> .....

> −− For some low-risk non-adversarial purposes, almost any RNG will
> suffice. An encrypted counter will look random to any tester who
> doesn't know the encryption key.
>
>   Specifically: Practical application #1: An encrypted counter
>   works fine for Monte Carlo molecular dynamics, even if the
>   encryption key is published, because the molecules don't read
>   the literature. This has the advantage that the pseudo-random
>   sequence can be replicated exactly, if desired.
>
  <https://www.metzdowd.com/mailman/listinfo/cryptography>
In many cases the RNG should be a plugin.
PRN with known seed.
PRN with system random seed.
TRN with hardware support

For data science the plugin set should result in effectively equal results
to validate the tool.
Iterate through each and evaluare the code results.

For gaming involving money tested true random numbers please.

For messages and security it gets more complicated.

And, I am a fan of 128 bit address spaces.
Increasing physical address from 40 bits to 64 would be a start.
Today they commonly implement from 40 to 52 *physical address* bits
(supporting from 1 TB to 4 PB of RAM).  Older batch systems would spool a
job
in and out of memory so protection models were simplified. With a GIANT TLB
and sufficient RAM
spooling one out then another into a giant TLB entry long running code that
might generate TLB hits
can be improved.  Putting the OS on a "co-processor" or IO channel
processor is also not silly.

It is hard to go fast and also be secure.



-- 

          T o m    M i t c h e l l  ( o n   N i f t y E g g )
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.metzdowd.com/pipermail/cryptography/attachments/20210621/a8ae00ad/attachment.htm>