On 16/09/15 08:36, Jeff Burdges wrote: > I think typical capability terminology breaks down once you start > talking about the internals of a protocol and memory compromises as > opposed to the full protocol. > > There are folks miss-reading Dominic Tarr's paper on wildcard attacks in > handshakes as presenting a flaw in TripleDH, for example. It's not > though, only Bob's ephemeral key is a wildcard to authenticate as anyone > to Bob.
This would be KCI, but applied to long-term *and* session secrets. The attack exists, but as Trevor said it's a different argument on whether it's serious. > [..] It's simply that possessing both ephemeral key's lets you do > TripleDH without possessing either long-term key. In that setting, if > you consider how Bob's ephemeral key could be compromised, then you > realize that Bob seems pretty doomed regardless, but actually evaluating > that goes way outside the "capability model". > Not sure what you mean here. If everyone's session secrets are compromised, then sure we're in more of a hole. But it doesn't mean we have to accept that we're equally screwed when only one person's session secrets are compromised. > In your case, all encryption protocol use symmetric cyphers for the > actual message data, so they all have an AKC capability ephemerally, > including GPG. > The encryptor doesn't have to *hold onto* the symmetric key, for it to be compromised later. For example in ElGamal, the symmetric key is effectively embedded in the message, and the encryptor doesn't hold onto it. Suppose, instead of agreeing on a shared session key, we agreed on ephemeral public encryption keys. Then Alice can use Bob's ephemeral public key to encrypt to him, without needing the ephemeral decryption capability. This is not hard to arrange - e.g. in a group key agreement, one might agree on ephemeral signing keys. So even if her local state is compromised, she can still *encrypt* (but not authenticate) to Bob. I'm not saying that this is the best way to do things, but just that the capability terminology does not "break down" as you say, and could be explored further. A symmetric secret is effectively many capabilities; this fits fine into the surrounding discussion. (Alice's lack of authentication may admit an argument here that the encryption is breakable indirectly, even without the explicit decryption capability, but it's not obvious - the model is not exactly CCA2 and I'd have to read through the eCK paper that Trevor mentioned. The attacker could also try to trick Bob into replying with the contents of previous messages, by sending messages of their own authenticated as Alice.) > There is probably yet another case for the "key erasure" terminology > here. There are going to be ephemeral keys that do all sorts of bad > things if erasure fails. It's simply important to ask if your > ephemerality / erasure boundary is what you think it is.* If your > implementation get that boundary correct, then all long term bits makes > sense as capabilities. > > [..] Erasure and this issue are independent; this issue is about not having those extra capabilities in the first place, to need to delete them later. One can always generate "best" erasure rules based on receiving acknowledgements that obsolete older keys, and have a timeout separate from this rule to guard against "delay-ciphertext-then-black-bag" attacks. The former corresponds to (2), the latter to (1), from my last post to the libforwardsec thread. > Anyways, there are bad design decisions, like adding a signature to > TripleDH, that result from blindly treating ephemeral capabilities as > real capabilities. Blind treatment of anything is bad. :) A more precise treatment of ephemeral keys as capabilities isn't complete yet, and we won't know how that goes until we've done it. Even forward secrecy can be treated as a case of minimising the scope of each capability. 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
