[Cryptography] Hohha Protocol : 1. Key renewal review

[Ismail Kizir]

On Sun, Nov 25, 2018 at 2:47 PM Jerry Leichter <leichter at lrw.com> wrote:
>
> It provides neither, in the usual use cases for key renewal or forward security.
>
> You have to think about the attack models that both of these are supposed to be protecting against.  The second is easier:  Suppose an attacker gains control of some endpoint and is thus able to extract K1 and K2.  What forward security is supposed to guarantee is that even given this information, the attacker cannot go back and decrypt previously recorded messages.
>

Yes Jerry.
You're right.
If we assume that the raw key material has been compromised, my method
doesn't provide forward secrecy.
But I think, it hides well raw key material.
Even one of temporary keys has been compromised, they can't decrypt
past nor future communications nor raw key material.
And you are also right: I can use day number instead of week number.
But I still don't see a better method better than the one I am
suggesting, for the moment.
It doesn't provide forward secrecy.
If initial key material has been compromised, whole communication can
be decrypted.

>Oh, and another thing to consider:  You have "two shared secrets" K1 and K2.  But how is that different from having a single shared secret
>        (length of K1) || K1 || K2
>where the || is concatenation?  This in and of itself should tell you that you haven't actually changed anything by describing your algorithm in terms of two secrets....

You may also be right. It can also be called doubling the key size and
then reducing it with a KDF to half size again.
But it can also be considered as using 2 different keys in order to
derive temporary keys.
The point here:
I am using two distinct and hidden 256 bits in order to derive temporary keys.

I understand here the concerns about forward secrecy:
In a military grade security, forward secrecy may be vital:
A soldier captured with his phone may be a huge security leak by
letting enemy to decrypt whole communication.

I don't want to create a military grade messenger nor to protect criminals.
If the phone is obtained somehow, all communication can be seen.

My aim is to try to create a messenger for everybody, which is secure
for "mass surveillance".
If security services or legal authorities target someone specifically,
I never want to put obstacles for them.
I am just trying to play on the legal side:
Protecting the communication channel.
Putting as much solid mechanisms as possible for mass surveillance.
Simply, protecting constitutional rights for the privacy of
communication, as described in article 22 our(Turkish) Constitution.

I am also trying to protect curious government agencies from
themselves, as, Turkish Penal Code Article number 132 specifically
describes crime of violation of this right, by a punishment of up to 3
years in jail!

>From this point of view.
Let's think about my project again:

1. Is my method enough to provide my users what I am promising?
2. Do I really need forward secrecy?
3. Can someone here describe me a better method, which is not too much
complicated, to provide  forward secrecy?
    I am open to every suggestion. But I haven't seen here, anyone,
who could explicitly provide us a method, which is not possible to
reveal whole communication when initial keys have been compromised.
Note that, my philosophy is also based on using PSK whenever possible.

Ismail Kizir