<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Mar 29, 2017 at 8:48 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"><div class="gmail_extra"><div class="gmail_quote"><span style="font-size:12.8px">The following scheme scores highly, except that it has no web site:</span><br></div></div><div class="gmail_extra"><div style="font-size:12.8px"><br></div><div style="font-size:12.8px">I invented an amazing truly unhackable super-encryption algorithm:</div><span class="gmail-"><div style="font-size:12.8px"><br></div><div style="font-size:12.8px">1) Generate n bits of true random data that have no bias or any detectable non-randomness</div><div style="font-size:12.8px">2) Manually deliver this OTP random bits to the recipient, then go home.</div><div style="font-size:12.8px">3) XOR OTP data with an n-bit secret message to generate ciphertext.</div><div style="font-size:12.8px">4) Use HMAC-SHA512(ciphertext) to generate tag</div><div style="font-size:12.8px">6) Transmit ciphertext | tag over any unsecured channel to the recipient.</div><div style="font-size:12.8px"><br></div></span><div style="font-size:12.8px">I claim this OTP scheme has "perfect security", is authenticated, has information theoretic security, is trivially provable as CCA2 secure, is simpler than all popular AEAD schemes, and yet is completely useless :)</div></div></div>
</blockquote></div><br></div><div class="gmail_extra">Duh.  This scheme needs a MAC for auth.  So, generate replace HMAC-SHA512(ciphertext) with HMAC-SHA512(OTP data | ciphertext).</div><div class="gmail_extra"><br></div><div class="gmail_extra">Anyway, to pick on Patrick's scheme a bit more, it looks like this:</div><div class="gmail_extra"><br></div><div class="gmail_extra"><div class="gmail_extra">\T1=(xor K1 M1)</div><div class="gmail_extra">\T2=(xor K1 K2)</div><div class="gmail_extra"><br></div><div class="gmail_extra">Those two bits T1 and T2 are transmitted in the clear.</div><div class="gmail_extra"><br></div><div class="gmail_extra">For the next transmission, we have:</div><div class="gmail_extra"><br></div><div class="gmail_extra">\T3=(xor K2 M2)</div><div class="gmail_extra">\T4=(xor K2 K3)</div><div class="gmail_extra"><br></div><div class="gmail_extra">Suppose M1 is known to the attacker.  Then M2 = T1 XOR T2 XOR T3 XOR M1.  Obviously, no scheme that transmits m bits of secret message protected by only k bits of secret key can have "perfect security".</div><div class="gmail_extra"><br></div><div class="gmail_extra">This brings me to a practice I see used commonly which drives me nuts.  In the cloud, vendors like to share TRNG data from one hardware TRNG with many virtual machines that need entropy.  Worried that an eavesdropper might be listening to the channel between the TRNG and virtual machines, they encrypt the TRNG data stream.</div><div class="gmail_extra"><br></div><div class="gmail_extra">It is not possible to increase the entropy of a remote machine when an eavesdropper is listening.  The remote machine requires its own TRNG, or some ability to collect unpredictable events not seen by the eavesdropper.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Bill</div></div></div>