[Cryptography] Hohha Protocol : 1. Key renewal review

[Peter Fairbrother]

On 23/11/18 22:34, Ismail Kizir wrote:
[...]
> When both parties have K1 and K2, they will not use directly as they are.
> 
> Every time they need common shared secret K:
> 
> They will first calculate which week of year we're in(Greenwich time)
> 
> Then, they append 4 digit year
> For example, we are actually week #47 of 2018
> We will obtain 472018
> And then, we  append K2 at the end of this buffer.
> 
> Then, take SHA512 hash of resulting buffer.
> Then xor first 32 bytes half of resulting sha512 with last 32 bytes.
> as:
> for (unsigned t=0; t<32; t++)
>    sha512res[t] ^=  sha512res[t+32];
> 
> then, they will xor first 32 bytes of sha512res with K1 to obtain
> actual 32 bytes shared key > as:
> 
> for (t=0; t<32; t++)
>    ActualSharedSecret[t] =  sha512res[t] ^ K1[t];
> 
> This method doesn't require key renewal.

Key renewal is often a bad idea.

> And it also provides forward secrecy.

Ah, no, it doesn't.

Forward secrecy (there is a decent case for calling it backwards 
secrecy, but we are stuck with forward secrecy for now) implies that an 
attacker cannot decrypt past traffic after some key secret is deleted.

But you aren't deleting any secrets. If an attacker gets the raw key 
material [1] he can use it to decrypt all past messages.



The best way I can think of offhand to provide PQ forward secrecy is by 
key updating. Assume two keys, kA for Alice to call Bob, kB for Bob to 
call Alice (synchronisation gets very complicated otherwise).

Alice calls Bob, using the key or a derived key - then she updates kA by 
some PQ resistant method, eg she hashes it, deletes the old kA, and 
stores the hash as kA.

When Bob gets the message he uses his copy of kA to decrypt it, then 
hashes his copy of kA, deletes the original kA and stores the hash as kA.

As soon as both copies of kA are deleted, there is no key material which 
an attacker can use to decrypt the message (assuming the hash cannot be 
reversed).

There are some possible tweaks and variations you can add to eg 
compensate for out-of-order delivery - but these are really really 
complicated, and very hard to get right, and it is almost certainly best 
not to bother.



[1] Especially with modern ciphers, key material exposure is far more 
likely than an attacker being able to cryptographically break one 
message and find the key. To (slightly mis)quote Robert Morris, "Rule 1 
of cryptanalysis: check for plaintext and keys".




But, a more fundamental problem: You say to are not a cryptographer, so 
why do you think you are qualified to write cryptographic software?

I do not mean that in any rude way. From a cryptographic point of view a 
lot of your mistakes are fairly elementary ones.

Second, writing secure code is yet another requirement - I haven't 
looked at any of your code, but writing secure code is quite different 
from writing ordinary code. I can't do it, wish I could.

Perhaps some of the secure code chaps could chip in here?

Lastly, writing cryptographic algorithms and apps is hard, very hard. Or 
maybe not - to quote Bruce Schneier (this is sometimes known as 
Schneier's law, and all cryptographers will know of it: it is also why 
you shouldn't use roll-your-own algorithms):


"Anyone, from the most clueless amateur to the best cryptographer, can 
create an algorithm that he himself can't break. It's not even hard. 
What is hard is creating an algorithm that no one else can break, even 
after years of analysis. And the only way to test that is to subject the 
algorithm to years of analysis by the best cryptographers around."




Don't get me wrong, we desperately need good cryptographic programmers. 
But cryptography is not the same as accounting, lives may depend on it, 
and writing cryptographic software is a specialised skill.

If you are also designing cryptographic algorithms, with no experience 
or background in cryptographic algorithm design ...


Peter Fairbrother