<div dir="ltr"><div dir="ltr">On Mon, Jun 21, 2021 at 6:23 PM John Denker via cryptography <<a href="mailto:cryptography@metzdowd.com">cryptography@metzdowd.com</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 6/21/21 11:15 AM, Caleb Cannon wrote:<br>
<br>
> I wrote a PRNGG. That is, a pseudo random number generator generator.<br>
<br>
Ruh roh.<br>
<br>
> the part that I had the most trouble with was testing the quality of<br>
> the random number generation.<br>
<br></blockquote><div>..... </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
−− For some low-risk non-adversarial purposes, almost any RNG will<br>
suffice. An encrypted counter will look random to any tester who<br>
doesn't know the encryption key.<br>
<br>
  Specifically: Practical application #1: An encrypted counter <br>
  works fine for Monte Carlo molecular dynamics, even if the<br>
  encryption key is published, because the molecules don't read<br>
  the literature. This has the advantage that the pseudo-random<br>
  sequence can be replicated exactly, if desired.<br></blockquote><div> <a href="https://www.metzdowd.com/mailman/listinfo/cryptography" rel="noreferrer" target="_blank"></a><br>
</div><div>In many cases the RNG should be a plugin.  <br>PRN with known seed.<br>PRN with system random seed.<br>TRN with hardware support<br><br>For data science the plugin set should result in effectively equal results to validate the tool.<br>Iterate through each and evaluare the code results.</div><div><br></div><div>For gaming involving money tested true random numbers please.</div><div><br></div><div>For messages and security it gets more complicated. </div><div><br></div><div>And, I am a fan of 128 bit address spaces. <br>Increasing physical address from 40 bits to 64 would be a start. <br><div class="gmail-wDYxhc" lang="en-US" style="clear:none;padding-top:0px;border-radius:8px;padding-left:0px;padding-right:0px;font-family:Roboto,arial,sans-serif"><div class="gmail-LGOjhe" role="heading" style="overflow:hidden;padding-bottom:20px"><span class="gmail-ILfuVd" style="line-height:24px"><span class="gmail-hgKElc" style="padding:0px 8px 0px 0px;background-color:rgb(255,255,255)"><font color="#000000">Today they commonly implement from 40 to 52 <b style="">physical address</b> bits <br></font></span></span><span style="color:rgb(0,0,0)">(supporting from 1 TB to 4 PB of RAM).  Older batch systems would spool a job <br>in and out of memory so protection models were simplified. With a GIANT TLB and sufficient RAM <br>spooling one out then another into a giant TLB entry long running code that might generate TLB hits  <br>can be improved.  Putting the OS on a "co-processor" or IO channel processor is also not silly.<br><br>It is hard to go fast and also be secure. </span></div></div><div class="gmail-g" style="font-family:Roboto,arial,sans-serif;font-size:14px;line-height:1.2;width:600px;margin:0px;clear:both;padding-bottom:0px;padding-left:0px;padding-right:0px;color:rgb(189,193,198)"><div style=""><div class="gmail-tF2Cxc" style="clear:both;padding-bottom:0px"><br class="gmail-Apple-interchange-newline"></div></div></div></div></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div dir="ltr"><div dir="ltr"><br></div><div dir="ltr">          T o m    M i t c h e l l  ( o n   N i f t y E g g )<br></div></div></div></div></div></div></div></div></div>