[Cryptography] "Perpetual Encryption" - Coda Encore

[Dennis E. Hamilton]

> -----Original Message-----
> From: cryptography [mailto:cryptography-
> bounces+dennis.hamilton=acm.org at metzdowd.com] On Behalf Of Dennis E.
> Hamilton
> Sent: Friday, April 7, 2017 12:57
> To: 'Crypto' <cryptography at metzdowd.com>
> Subject: Re: [Cryptography] "Perpetual Encryption" - Coda
> 
> Wherein perpetual-motion remains unachievable ...
> 
> > -----Original Message-----
> > From: cryptography [mailto:cryptography-
> > bounces+dennis.hamilton=acm.org at metzdowd.com] On Behalf Of Dennis E.
> > Hamilton
> > Sent: Thursday, April 6, 2017 08:48
> > To: 'Crypto' <cryptography at metzdowd.com>
> > Subject: Re: [Cryptography] "Perpetual Encryption"
> >
> >
> >
> [ ... ]
> >
> > With respect to the security model, RNG2 is essentially a means for
> > stretching the (K1, X1, ...) stream for some operationally-valuable
> > purpose (including hiding of that stream) in producing (XK1, XK2, ...)
> > and the associated parameters.
> >
> [ ... ]
> [orcmid]
> 
> Having provided a Conceptual Pilot, CP, that demonstrates the procedure
> can be implemented, we can now argue that, despite all of that, the
> entropy-based argument must fail.
> 
> STRETCHING OF AN OTP STREAM IS MAYBE NOT AN OTP STREAM?
> 
> The perpetual equivocation argument presumes a sequence
> 
>   K1 || X1 || X2 || ... || Xn
> 
>  derived from "truly random" sources.  If this stream be exchanged
> entirely and independently in secret, it would serve as an OTP.
> 
> The proposed methodology depends on *deterministic* derivation of a
> definite stream
> 
>   XK1 || XK2 || ... || XKn || XK[n+1]
> 
>  claimed to be a cryptographically-sufficient OTP stream cipher.  This
> is the cipher stream applied to a same-sized plaintext stream that
> conveys chunks of a message M *and* the X1, ..., Xn.
> 
> In theory, the XK1 ... XK[n+1] stream must be compressible to at least
> the K1 || X1 ... || Xn stream for a message longer than K1.  Whatever
> the feasibility of breaking that, it points out that there cannot be any
> more entropy in the key stream than that of the K1 || ... || Xn stream.
[orcmid] 

I have fallen into the bad habit of using entropy improperly, something I believe also infects the Perpetual Encryption White Paper.  

Also, arguments around compressibility are applicable in all manner of pseudo-random situations.  I want to explain better why I believe that is appropriate here.  

Consider this in terms of unpredictability/indistinguishability (what equivocation seems related to) as well.  

For me, the key point is that if the stream K1 || X1 || X2 || ... || Xn is from a "truly random" source then it is not compressible and X[n+1] is not predictable.  I.e., it qualifies as a One-Time Pad.  

The greater the length increase for XK1 || XK2 || ... || XK[n+1] the more it becomes pseudo-random and suspect as cryptographically-distinguishable from an OTP.  That's concerning because part of the expansion is for encrypting the Xi as well as Mi message chunks in producing the XKi-corresponding Ci.  I see two kinds of difficulties here:

 a. Corruptions of single frames (e.g., single octets) have very serious consequences when they apply to octets that are encryptions of Xi frames embedded in the plaintext stream, ruining the decryption of C[i+1}, et.seq. 

 b. The assurance that the result of encryption of a message portion is as indistinguishable as the corresponding cipher portion may be inadequate with respect to equivocation.  

> 
> In fact, the theoretical compressibility is to merely K1.  That's
> because the Xi are conveyed in the plaintext.
> 
>   XK1 depends on K1 only,
>   XK2 depends on K1 || X1 (as *given*),
>    ..., and
>   XK[n+1] depends on K1 || X1 (as *given*) ... || Xn (as *given*)
> 
> Since the Xi are conveyed in the plaintexts of earlier blocks, they are
> effectively unsurprising and it all depends on K1, the only secret not
> carried in the ciphertext.
[orcmid] 

Put another way, knowing K1 is sufficient to decrypt the ciphertext no matter what the Xi are.  K1 is sufficient to produce the XKi.  It is difficult to see how this approaches anything like a cryptographically-indistinguishable OTP.  

Any cleverness of variable chunking and chunk rearrangements strikes me as not measuring up to what is achieved far better with a highly-trusted block cipher in most applications.

> 
> 
> RACING TO THE FINISH
> 
> Accepting that an argument from compressibility is not the same as a
> break, it should be worrisome with respect to claims of increasing
> entropy beyond whatever that means for K1.
[orcmid] 

Better to say increasing unpredictability, essentially by perturbing RNG2.

> 
> There is another problem.  The preamble to the Perpetual Encryption
> White Paper states that ideal secrecy is achieved if entropy is added to
> the cryptosystem at a faster rate than it is consumed.
> 
> It seems clear that if the message, M, is longer than the initial key,
> K1, it is not possible to catch up before the last bit of M is
> transmitted.  It's not even possible to break even.  (Sound familiar?)
> And that's assuming introduction of the Xi in earlier parts of the
> plaintext amounts to something, cryptographically.
> 
> Whether the scheme has practical value despite its questionable
> characteristics, it would seem that there are better-understood systems,
> with hardware-assisted implementations, that also have better general-
> purpose application.
> 
>  - end -
> 
> 
> 
> 
> _______________________________________________
> The cryptography mailing list
> cryptography at metzdowd.com
> http://www.metzdowd.com/mailman/listinfo/cryptography