[Cryptography] Hohha Protocol : 1. Key renewal review

[Jerry Leichter]

> 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.
> And it also provides forward secrecy.
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.

But the date is public information.  Assuming he wasn't so dumb (or somehow crippled in his attack) that he didn't record the time the messages were sent, he can now go back and apply the same algorithm to compute all the earlier shared secrets - and hence read all the previous messages.

The usual response is to use more bits of the time than just the year and date, but there's no help there:  Even if you assume that somehow the endpoints can synchronize to more bits of the time than the attacker, there can't be enough more accurate to matter.  Let's take and extreme case.  Suppose the endpoints have atomic clocks that can synchronize to the nanosecond *and* they know the distance between themselves to less than a foot (speed of light is on the order of a foot a nanosecond).  And the attacker for some bizarre reason can only record time to the nearest second.  So the maximum error the attacker has to consider is 2 seconds.  That gives him 2 billion guesses for the time field to try - effectively a 31 bit key.  Not useful for serious cryptography in this day and age.

As for key renewal:  Well, there are two reasons to do key renewal.  One is concern that the key was somehow compromised by some completely unknown means.  But if the session key was compromised by completely unknown means ... who's to say that K1 and K2 weren't compromised as well?  In which case, we're back to the forward security case.

The second, more common reason splits into two equivalent ones:  The session key leaks in a way we *assume* doesn't provide any access to K1 and K2; or the encryption algorithm's security depends on not have more than N blocks encrypted with the same key, and we're getting too close to N.  If you use the week number, you're going to recompute the same shared key for up to 7 days.  With modern crypto algorithms and link speeds, that's going to be *way* longer than the time typically assumed to reach the critical N blocks (usually a couple of hours; sometimes less); and if you have some reason to suspect the key leaked on Monday ... are you really going to wait 6 days to rekey?

Again, you can use a more precise notion of time ... which will probably work well for these cases.  But they work just as well with only a single shared secret.

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....
                                                        -- Jerry