[Cryptography] Hohha Protocol : 1. Key renewal review

[Peter Fairbrother]

On 25/11/18 15:08, Ismail Kizir wrote:
> On Sun, Nov 25, 2018 at 5:05 PM Peter Fairbrother <peter at tsto.co.uk> wrote:
>>
>>
>> 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).
> 
> If an attacker obtains somehow you initial raw key material and if it
> records whole communication, it can also decrypt all of your messages.

Yes. But that's not the attack forward secrecy defends against.

In the system I described the initial key material only exists for a 
short time; as soon as it is updated it is no longer there for an 
attacker to find. In your case, it persists unchanged.


Put it this way: Suppose after the system has been in use for a year or 
so, someone gets hold of your device and extracts the key material in it.

Under my system the key material he gets *cannot* be used to decrypt 
past messages.

Under your system, even after a year, he gets key material which *can* 
be used to decrypt all past messages.

As I have said before, perhaps it should be called backward secrecy.



Key replacement can defeat the "initial key onward" attack you 
mentioned, but that's a whole 'nother story entirely.

The key renewal system in the paper won't do that however, as if the 
attacker knows the old key and can see the traffic he can calculate the 
new key just as easily as Alice or Bob can, in just the same way.

The system you just outlined has a similar flaw - if the attacker knows 
K1 and K2, he can calculate the session keys just as easily as Alice and 
Bob can.

You might think that an attacker would only get a session key, and in 
some rare circumstances that might just be possible - but it is far less 
likely than him getting K1 and K2 as well.



> What you are suggesting is just a more complicated and less secure
> method of what I am suggesting.


It's actually very different, less complicated, and probably more secure.

All this faffing about with two keys - why? Can you explain each 
operation, and why you chose it. What does it gain you? What attacks 
does each operation defeat?



In general we do nothing at all without very specific reason. Why? A 
more complicated system is harder to analyse and thus get right, and it 
has more places to attack.

The acronym is Keep It Simple Stupid - because adding inessential 
complexity is stupid.

It's also closely related to why a hogde-podge (which means a lot of 
unrelated stuff roughly stuck together in a bit of a mess) is bad - it 
is hard to analyse and thus to get right, and it offers more places for 
an attacker to attack.


> Am I wrong?
> Or am I missing something?

You have to get into the mindset - people who you don't suspect, who 
know more cryptography than you do, who know more tricks than you do, 
who are sneakier than you are, who have no morals at all, and who have 
more determination and more resources than you think they do, are after 
your data.

That applies to everybody by the way. Even me. :)

It's rule 2. Even when it isn't true, you should treat it as being true.