<div dir="ltr"><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Mar 29, 2017 at 10:41 AM, Bill Cox <span dir="ltr"><<a href="mailto:waywardgeek@gmail.com" target="_blank">waywardgeek@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">This scheme scores highly, except that it has no web site:<div><br></div><div>I invented an amazing truly unhackable super-encryption algorithm.  It is also super-simple:</div><div><br></div><div>1) Generate n bits of true random data that have no bias or any detectable non-randomness</div><div>2) Manually deliver this OTP random bits to the recipient, then go home.</div></div></blockquote><div><br></div><div><div class="gmail_default" style="font-size:small">​There are two tests that are critical. Attackers being unable to break the system and users being able to use it in practice.</div><br></div><div><div class="gmail_default" style="font-size:small">​Any system that claims to have a one time pad is either utterly impractical or not a one time pad. Thus the claim is a near infallible indicator of bogosity.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">The one class of system involving an OTP that could arguably be harder to break (but not impossible) ​is to mix a random stream of bits into the stream in a fashion that effectively increases the key length.</div><br></div><div><div class="gmail_default" style="font-size:small">​So lets say your initial key is k.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">We encrypt the first AES block as follows.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Generate a random value the same size as the block. R</div><div class="gmail_default" style="font-size:small">Let RH, DH be the high bytes of the random and data blocks respectively and RL, DL be the low.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Output = AES (DH+RH, k) + AES (DL+RL, k)​</div><div class="gmail_default" style="font-size:small">​k' = AES (R, k)​</div><br></div><div><br></div><div><div class="gmail_default" style="font-size:small">​What this achieves is it doubles the size of the cipherstream and stalls the AES encryption every two blocks.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">What it might achieve is some degree of additional work factor ​but I doubt it.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">A more difficult to break arrangement might be </div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Output = AES (R, k) + AES (D^R, k')</div><div class="gmail_default" style="font-size:small">​k' = AES (R, k)​<br></div></div><div><br></div><div><br></div><div><div class="gmail_default" style="font-size:small">​It is of course total bollocks though.​ It is not making the cipher unbreakable and the work factor is actually unchanged.</div><br></div><div><div class="gmail_default" style="font-size:small">​There are infinitely many similar schemes. And they all fall short because the width of the key isn't increased.​</div><br></div></div></div></div>