<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Jan 17, 2020, at 6:25 AM, Michel Arboi <<a href="mailto:michel.arboi@gmail.com" class="">michel.arboi@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="">Le jeu. 16 janv. 2020 à 23:37, james hughes <<a href="mailto:hughejp@me.com" class="">hughejp@me.com</a>> a écrit :<br class=""><blockquote type="cite" class="">OFB with a plaintext of 0s is a permutation, not a random permutation.<br class=""></blockquote><br class="">I'm not sure I understand the role of the plaintext, considering that<br class="">it is just XOR-ed with the cipher stream. Did I miss something?<br class=""></div></div></blockquote><div><br class=""></div><div>OFB does feed back. OFB mode also takes in the plaintext. If the plaintext is any constant, then the system will eventually cycle. </div><br class=""><blockquote type="cite" class=""><div class=""><div class="">What do you mean by "not random"? That it will cycle eventually?<br class=""></div></div></blockquote><div><br class=""></div><div>Yes</div><br class=""><blockquote type="cite" class=""><div class=""><div class=""><blockquote type="cite" class="">It will cycle, usually around 2^{n-1} where the n is the block size. The cycle could (improbably) be as short as 1 block.<br class="">So OFB is not usable as an RNG.<br class=""></blockquote><br class="">2^127 is safe in practice for any PRNG (if I am lucky). We'd need an<br class="">impractical amount of resources to detect the cycle.<br class="">What is the probability of getting a short cycle?<br class=""></div></div></blockquote><div><br class=""></div><div>Roughly, It is a 50/50 chance if it is shorter by at least 1 bit. 25/75 by 2 bits, down to 2^{-128} that it is only 1 cycle. Sure if you use a this PRNG once, it is “good enough”, but if you deploy this in a system that has billions of PRNGs running independently, the probability of at least one of them getting a short cycle is real. </div><br class=""><blockquote type="cite" class=""><div class=""><div class=""><blockquote type="cite" class="">CTR mode is better, (but still not random since values do not repeat)<br class="">Hash is better.<br class=""></blockquote><br class="">Is there a real difference between hashing a counter (concatenated to<br class="">a nounce) and encrypting it as in CTR mode?<br class=""></div></div></blockquote></div><br class=""><div class="">Yes, counter mode repeats at the block size 2^128 and never before. Again, if there are billions of people using your PRNG independently, the possibility that two are using the same seed (you call a nonce) is real (which is similar to repeated hash). The cycling with the hash function is also possible but the block sizes are larger. </div><div class=""><br class=""></div><div class="">Bringing this back to your question… OCB showed as Weak random. I am suggesting the cycle you were in may have had some bias. Change the key and you will be in a different cycle. (You are in a cycle even if you never get all the way through.) This is why the Hash works and OCB does not.</div><div class=""><br class=""></div><div class="">Read the <a href="https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-90Ar1.pdf" class="">NIST recommendations</a>. For instance, Hash, HMAC and CTR are recommended, OFB and CBC are not. It also suggests reseeding the CTR_PRNG and HASH_PRNG after 2^{48} reads. </div><div class=""><br class=""></div><div class="">Maybe the best recommendation is to use the OS supplied recommendations for cryptographically secure random numbers. </div></body></html>