On 14/09/15 12:47, Katriel Cohn-Gordon wrote: > - (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") > - (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") > > 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? > > > This is discussed inActor Key Compromise: Consequences and Countermeasures > <http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=6957115&tag=1> [Basin, > Cremers, Horvat; CSF 2014]. As you point out, the idea is known as KCI for > authenticated key exchange protocols, but it's applicable much more widely. >
Nice paper, thanks Katriel! If I understand correctly, the paper includes a
construction on how to make any key agreement protocol AKC-secure (for any
security property derived from the session-key) by adding a round to further
protect the session-key.
It'd be interesting to see how to work this construction into protocols that
*continuously perform key agreement* during communication, as is desirable in
asynchronous messaging - though OTR does it too. (And then you need to consider
compromise of not just the long term key, but of the "current" session-key.)
Also interesting would be if this is easily extensible into group messaging.
That would be a lot of work, though.
Intuitively, I had thought that AKCS for secrecy would be very hard to achieve
for private group messaging. Rough thoughts:
- AKCS for authentication ("KCIR" in the paper) can probably be achieved in a
straightforward way in groups: each sender gets (as the result of the session
establishment protocol) an authentication capability, and the whole group gets
the verification capability, including the sender. If a verifier is
compromised, the attacker doesn't get the authentication capability. This
doesn't seem too hard to arrange.
- AKCS for secrecy however, would need to explicitly exclude the decryption
capability from the sender. This would be very awkward to achieve in a group
scenario - the session establishment scenario would have to somehow generate n
decryption capabilities, and keep each of them secret from {all-but-1} of the
group.
The existence of a construction offers some hope in this area, but I'm not
trained enough in this area to give formal arguments.
However, it's good to mention the security property at least, for completeness
and future reference, even if it's not achieved by the protocol one is
designing.
X
--
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
