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
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Messaging mailing list [email protected] https://moderncrypto.org/mailman/listinfo/messaging
