<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div apple-content-edited="true"><div style="color: rgb(0, 0, 0); font-family: Helvetica; font-size: medium; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br></div></div><div><div>Am 06.12.2014 um 04:48 schrieb Tom Mitchell <<a href="mailto:mitch@niftyegg.com">mitch@niftyegg.com</a>>:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Dec 5, 2014 at 11:30 AM, Ray Dillinger <span dir="ltr"><<a href="mailto:bear@sonic.net" target="_blank">bear@sonic.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
<br>
On 12/04/2014 11:30 PM, Andreas Briese wrote:<br>
> i would like to put in my words, would you please indicate, if i am on the right track:<br>
><br>
</span></blockquote><div> ....</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
This is a degenerate "generator" because we lose<br></blockquote><div><br></div><div>Any generator needs to be very cautious with impossible</div><div>state and results.</div></div></div></div></blockquote><div><br></div><div>Regarding distribution patterns I did test all breeze variants (beside excessive NIST runs) </div><div>on 256 bucket distribution of output and visual patterns (rgba from output) but found no flaws. </div><div><br></div><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br></div><div>Consider a RNG (true or pseudo) if an analysis discovers that</div><div>a set of results is never generated than this can become a </div><div>problem.</div><div><br></div><div>Consider a lottery where a consortium can identify a block of</div><div>picks that automated quick picks never generate. By playing</div><div>in that space alone the odds of sharing a result are vastly reduced</div><div>and thus increasing the return on investment.</div><div><br></div></div></div></div></blockquote><div><br></div><div><br></div><br><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>Same for key generation. If key generation fails to apply with </div><div>an even hand to all possibilities in key space then the key space exploration</div><div>to crack open the data is reduced a little or a lot. Agencies might</div><div>try and use alternative generators to make their key space less</div><div>vulnerable than a common public keyspace.</div><div><br></div><div>Rounding has the potential of introducing inequities in the computation.</div><div><br></div><div>Theft and other abuses are possible. Decades ago I was playing with</div><div>calculating PI with a RNG based on some log and floating point mumble</div><div>foo. Code from the book compiled and ran... Then to make the exercise </div><div>visible I began to plot the hits inside and outside the unit circle.<br>The pixels that turned on filled the screen except for arks of omission.</div><div>These systematic omissions might be the locus of winning tickets</div><div>in an illegal game and the rest of the space could be "sold" with</div><div>no payout risk. I was living in Reno and working with folk that at</div><div>one time did work to validate electronic games. Interesting discussions</div><div>followed... </div><div><br></div><div>The problem of RNGs is difficult.</div><div>Consider how difficult it would be to demonstrate that all possible</div><div>outcomes are possible and that impossible outcomes are a do</div><div>not care. </div></div></div></div></blockquote><div><br></div><div>As far as i can tell, distribution is not the problem of this generator. You might argue, that if </div><div>something is flawed - distribution will be flawed too, but i have no indicator that this is in</div><div>fact the case here. That should have shown up in testing but didn't. I tested salsa20/8 in </div><div>parallel with NIST-suite and beside always passing the test-suite with the breeze code that </div><div>is published at github, i got even less p<0.05 than salsa did.</div><div><br></div><div>Period length might be a problem (see Persohn & Povinelli (2012) <a href="http://povinelli.eece.mu.edu/publications/papers/chaos2012.pdf">http://povinelli.eece.mu.edu/publications/papers/chaos2012.pdf</a> about float 32bit). </div><div>I think i have handled this (see my comments at the github site), but i need to prove that, which becomes hard.</div><div> </div><div>I had most of my companies equipment (3 i7 / 2 i5 / 2 XEON / 4 dualcore imacs ) running for 10 consecutive days to test up to 10GB output with NIST, and beside testing for innerState repetitions and found no flaws. </div><div><br></div><div>Nonetheless i can not test the generator (not even the small breeze128) as a whole for all possible outputs. </div><div>Therefore i will step back and try to assess, if and in case how often a single logistic map </div><div><br></div><div>while(x>0 && x<1){</div><div>nx = x-1</div><div>nx = nx * 3.9 * nx</div><div>x = 1-nx</div><div>}</div><div><br></div><div>produces the same state twice. I did this when i started this project, but hadn't recorded it for statistical analysis. </div><div>I'll keep you updated.</div><div><br></div><div>Andreas</div></div></body></html>