[messaging] Naming and classifying a security property

[Trevor Perrin]

On Tue, Sep 15, 2015 at 6:44 AM, Ximin Luo <infinity0 at pwned.gg> wrote:
>
> Yes, there's several more cases; someone who gets Alice's long-term keys (or this + current session keys), might be able/unable to:
>
> - decrypt/verify old ciphertexts from self/others in the same/older sessions
> - encrypt/authenticate new ciphertexts to self/others in the same/newer sessions
> - decrypt/verify new ciphertexts from self/others in the same/newer sessions
>
> Some of these are unavoidable of course, but it's good to enumerate them.
[...]
> In a protocol with "ideal security", roughly speaking, Alice should not be able to decrypt ciphertext that she sends to Bob - or in other words, Alice should not carry a decryption capability that only Bob needs. More generally, "ideal security" protocols should give parties the least capabilities they need.
>
> While this may seem "too strict", this should (intuitively) automatically give maximum protection against *any* pattern of passive memory compromise and active communication attacks.


You'd probably enjoy the "eCK" paper (and related work, both earlier
and later, but eCK is a good starting point):

http://research.microsoft.com/en-us/um/people/klauter/strongakemay06.pdf

It has a formal security model enumerating key-compromise conditions
under which an authenticated-key-agreement session should remain
secure.

It also strives towards a "maximum protection" ideal of resisting
every key-compromise that can be resisted.  Whether this realistically
models practical attacks and is a good guide to protocol design is a
separate question (I'd argue no, in some ways!).

But it's a good example of how to be formal about these things.


Trevor