[Cryptography] "Perpetual Encryption"

[Bill Cox]

On Wed, Mar 29, 2017 at 8:48 AM, Bill Cox <waywardgeek at gmail.com> wrote:

> The following scheme scores highly, except that it has no web site:
>
> I invented an amazing truly unhackable super-encryption algorithm:
>
> 1) Generate n bits of true random data that have no bias or any detectable
> non-randomness
> 2) Manually deliver this OTP random bits to the recipient, then go home.
> 3) XOR OTP data with an n-bit secret message to generate ciphertext.
> 4) Use HMAC-SHA512(ciphertext) to generate tag
> 6) Transmit ciphertext | tag over any unsecured channel to the recipient.
>
> 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 :)
>

Duh.  This scheme needs a MAC for auth.  So, generate replace
HMAC-SHA512(ciphertext) with HMAC-SHA512(OTP data | ciphertext).

Anyway, to pick on Patrick's scheme a bit more, it looks like this:

\T1=(xor K1 M1)
\T2=(xor K1 K2)

Those two bits T1 and T2 are transmitted in the clear.

For the next transmission, we have:

\T3=(xor K2 M2)
\T4=(xor K2 K3)

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".

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.

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.

Bill
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20170329/c41da880/attachment.html>