Does the diffie helman rachet in double ratchet do anything if one side never replies?

Question

I am a little confused on how this functions so apologies in advance if the question is naive.

The way i understand it, the function of the standard sending and receiving ratchets in Double Ratchet is to provide backward secrecy. Since the ratchets continually pass the key through a KDF, the attacker cannot deduce previous keys if he somehow keys a hold of the current one.

The issue is, this does not provide forward secrecy, since the attacker can now tick along with our ratchets. This is where the DH Ratchet comes into place.

I am reading from http://cryptowiki.net/index.php?title=The_Double_Ratchet_Algorithm#Diffie-Hellman_ratchet

Alice and Bob both have a DH keypair generated. This keypair is seperate from the keys used in the sending and receiving ratchets.

When Bob sends a message, he sends his DH public key. When alice receives it, she uses hey private key and forms a new key from those two. Now Alice has new key(lets call it K1) for her ratchets.

Then when Alice sends a message to Bob, she sends her private component and generates a new DH keypair since this one was used on both sides. Bob can now use this to derive the same K1 key. Bob generates a new DH keypair since this one was already used to compute K1 on both sides.

My issue with this understanding is, what if Alice never responds? Bob will keep sending his public key. Since he only ratchets on receiving messages, his DH Rachet will never activate and there is now no forward secrecy for the N messages he sent? Also alice will receive the same public key multiple times. Surely this is an issue. Keys should be changing on sending,no?

I know theres something I'm missing here. Any help is appreciated.

Answer 1

Bob will keep sending his public key. Since he only ratchets on receiving messages, his DH Rachet will never activate and there is now no forward secrecy for the N messages he sent?

If there are indeed no answers over the ratcheted channel, this is correct. However, some implementations send their receive receipts via the ratcheted channel, meaning that the ratchet is only not advanced if the recipient never actually receives the messages or can't send the confirmation.

Also alice will receive the same public key multiple times. Surely this is an issue. Keys should be changing on sending,no?

This is not an issue, the protocol instructs which public key to use, which should be the first new one.

Answer 2

That much risk is acceptable in Signal protocol as it only affects small number of messages of the sending chain. As soon as Alice replies, the ratchet starts new sending chain and the keys in compromised chain can be no longer used to compromise new messages.

Ratchet has the nice property of being “self healing.” If, for whatever reason, any individual ephemeral key is compromised or otherwise found to be weak at any time, the ratchet will heal itself. We call this “future secrecy.”

Besides, forward secrecy is meant to protect the past sessions and not incoming messages. As long as the ratchet is not moving forward, the same session continues. If the keys of existing session are compromised, the session remains compromised.

Also, security of keys is based on an assumption that the device is also secure. If an attacker can compromise live keys in memory, it can compromise incoming and undeleted messages as well.