[Cryptography] "Perpetual Encryption"

Dennis E. Hamilton dennis.hamilton at acm.org
Wed Mar 29 18:15:36 EDT 2017


> -----Original Message-----
> From: cryptography [mailto:cryptography-
> bounces+dennis.hamilton=acm.org at metzdowd.com] On Behalf Of Allen
> Sent: Wednesday, March 29, 2017 08:27
> To: Dave Howe <davehowe.pentesting at gmail.com>
> Cc: Crypto <cryptography at metzdowd.com>
> Subject: Spam (7.183):Re: [Cryptography] "Perpetual Encryption"
> 
> > if you have (Mi XOR Ri) and (Pi XOR Ri) the logical next step is
> > (Mi XOR Ri) XOR (Pi XOR Ri) leaving you with Mi^Pi
> 
> I simplified some--the scheme may use something more complicated than
> an XOR, something like reversibly mixing bits in blocks (as in a block
> cipher)--it's not at all clear though from the whitepaper.
> Fundamentally, this scheme may be equivalent to a block or stream
> cipher with a random IV that is the same length as the message.

Alan, I tend to agree.

On first impression, the scheme struck me as reducible to something like this:

     Ci = E(Ki, Mi || Ri)

Where E is a block cipher and length(Mi || Ri) is the block size.  The 100% expansion case is where Mi and Ri are each half the block size.  There are arguments in the paper about how one can adjust the length of the R blocks to safely decrease the size expansion, and the M can also be compressed to gain further leverage (with care about compression failures, including information disclosure, that are not mentioned).

The trick seems to be simply that given Ki, you need to decrypt Ci to know not only Mi but the Ri so you can derive K[i+1] = f(Ki, Ri).  

What E(k, b) and f(k, r) can be that safely minimize re-keying per block and also keep R simple enough to satisfy the constraint conditions is not something I looked at.  I also did not break down the proposed scheme to confirm how it satisfies the above pattern and be OTP-congruent.  This is what I made out of the prose description.

It seems to me that the paper explicitly states that authentication is not handled (yet), and I didn't see anything about padding.  



 - Dennis

 -- Dennis E. Hamilton
    orcmid at apache.org
    dennis.hamilton at acm.org    +1-206-779-9430
    https://keybase.io/orcmid  PGP F96E 89FF D456 628A
    X.509 certs used and requested for signed e-mail




More information about the cryptography mailing list