On Tue, Sep 15, 2015 at 6:44 AM, Ximin Luo <[email protected]> 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 _______________________________________________ Messaging mailing list [email protected] https://moderncrypto.org/mailman/listinfo/messaging
