[messaging] Naming and classifying a security property

[Ximin Luo]

While I was doing an exercise on classifying and enumerating security properties, I came up with the following one:

- (in: w encrypts m to r) if attacker "a" passively compromises w, they are able/unable to decrypt current (in-transit) and/or future ciphertext (i.e. "act as r")

This is the encryption analog of KCI ("key compromise impersonation") which applies to authentication, and I derived it by swapping around some components of the latter's definition.

- (in: w authenticates m to r) if attacker "a" passively compromises r, they are able/unable to authenticate messages to r (i.e. "act as w")

Note that the former is not exactly the same as forward secrecy, which is modelled as a passive compromise on the *decryptor's* side, and is only about security for past *and not in-transit* messages.

I'm sure *someone* has considered it before, but I can't remember any literature that explicitly names this property - as opposed to say, "forward secrecy" or "key compromise impersonation". Does anyone who's more widely-read than I, know more about this?

"Why is this important"? Well, imagine you have an anonymous messaging system, where you don't necessarily know who the recipient is. Instead, you can watch the sender, intercept the ciphertext, then black-bag *the sender* to decrypt the ciphertext, which might reveal the recipient. This is a bit more convenient than black-bagging the recipient.

Now, this property might seem obvious to have, but it's actually a bit fiddly to achieve, and not all protocols have it. For example:

- naive symmetric encryption doesn't have this property, if w uses the same encryption key for multiple messages, because it's also a decryption key
- public key encryption has this property, if you don't also encrypt-to-yourself (which is a common default for GPG encryption :()
- chain-based ratcheting has this property - as the sender, you encrypt m[i] using k, then hash it and delete the original for m[i+1]. the recipient will need to keep extra state around if they want to handle out-of-order messages.
- OTR [1] doesn't have this property, but arguably the "black bag" attack is harder because of the shorter lifetime. other physical attacks might be able to exploit this, though.

The motivation for my original exercise (still incomplete) was to have a quick "smoke test" checklist of security properties to check, to benefit and educate wannabe protocol designers (like myself :p), along with some good arguments on why "it's a complete list of all possible security properties". I'd be happy to talk further about this, too, or be pointed to more papers on this topic by others.

X

[1] https://otr.cypherpunks.ca/Protocol-v3-4.0.0.html

-- 
GPG: 4096R/1318EFAC5FBBDBCE
git://github.com/infinity0/pubkeys.git

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://moderncrypto.org/mail-archive/messaging/attachments/20150913/cf080d10/attachment.sig>