# [Cryptography] Hohha Protocol : 1. Key renewal review

Peter Fairbrother peter at tsto.co.uk
Sun Nov 25 09:05:11 EST 2018

```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
```