[OTR-dev] Forward secrecy/deniability for long messages with low overhead

[Sergio Lerner]

Very nice to hear your interesting observations Ileana..

> Can you prove this mathmatically? 

My modes cannot be worse in security than the counter mode CTR providing
the plaintext cycle is long enough and the hash function used does not
share any strange algebraic properties with the encryption function such
as they cancel themselves (which is generally assumed).
So it's secure because my modes ARE counter modes, by some definitions
of CTR. Even if the one-wayness is completely broken, the result would
be completely secure. Only forward secrecy would be lost.

>
> I don't see how rehashing previous cipher blocks preserves the entropy
> of your IV/SS. Rehashing blocks of the same size results in a poorer
> hash security.  A pattern is estimated in 2^(n/2) iterations...which
> granted is a big loop but that is 2^80 compared to what you want with
> aes which is 2^128 and with recent research, 
That's why I suggested using a full 512 bit SHA-512 digest for BUFFER[i]
and then TRUNCATING the output to fit in the AES block. The cycle would
be around 256 bits.
But also one can construct BUFFER[i] taking 256-bits from
hash(BUFFER[i-1]) and appending 128 bits of a sequential counter.
Problem solved.


> but down to 2^51 and in
> even 2^38 with some preimages you describe...in some cases...possible
> with a super computer now-a-days.
What do you mean by 2^38 ? 2^38 elements in the cycle? Could you point
me to the paper where a 2^38 cycle in a 512-bit hash function is found?

>
> Although I believe this will weaken the resulting encryption by not
> having true random input data, I don't have reference to a specific
> attack...although it seems it would limit the domain of the function,
> as you have limited the range and effect random bits.
As I said, I don't need truly random input data as the counter. The AES
output will be, of course, as random as the CTR mode can have,

>
> At the least, you could no longer say its AES-128 (or whatever) as this
> doesn't seem recommended.
As I said, not a problem, providing the cycle is long enough.

Best regards, Sergio.