post-compromise security

[mallory]

From Paul (14 June 2022) "I think the "Post-compromise security" is confusing. I think it should
more clearly say the compromise was found and countered.
I am also confused how adding new ephemeral keys would help if the
user's long term identity private key was compromised. And further,
how does the remote particiant know there might be compromised messages
in transit? I think I agree with the description of the term, but the
sentence that starts with "It is usually" is not enough of a description
of a "fix" for compromised situations."

[mallory]

@claucece ideas here?

[mallory]

You got into the core of the debate here ;) The idea on post-compromise systems is indeed that new randomness (ephemeral) material is added every 'x' ammount of time. But, if the long-term identity keys are compromised, it is true that post-compromise is broken with an active attacker. Contrary to TLS though (where PCS is not achieved), the threat model of messaging systems for post-compromise security is different: it defines that if there is compromise of a message key and the long-term secret identities, then a passive attacker (or semi-active) will not be able to read future messages because new randomness is added. If this is active attacker, then yes, post-compromise is broken if identity keys are compromised and the attaker actively compromises one end-point. I can add this as a note that to the definition of PCS.

It is worth listing still, but perhaps with a note stating that true PCS adds significant complexity to the E2EE protocol used.

Do we need to tell implementers that in a definitional document?

[claucece]

I'm not sure I agree with the significant complexity part, it is usually just adding more randomness at some points. Perhaps just add that 'addition of randomness is needed to achieve it'.

[claucece]

This should be resolved now ;)