[messaging] Naming and classifying a security property
burdges at gnunet.org
Tue Sep 15 23:36:39 PDT 2015
On Tue, 2015-09-15 at 15:44 +0200, Ximin Luo wrote:
> I was not talking directly about forward secrecy, but about sender future secrecy, though they are all related in different ways. Here is some high-level motivation for this:
> 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. This principle ("least authority") can also been used to derive motivations for KCI, forward secrecy, or various other security properties related to compromises.
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. 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".
In your case, all encryption protocol use symmetric cyphers for the
actual message data, so they all have an AKC capability ephemerally,
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.
As for ratchets, I think your trying to say that Axolotl has an erasure
boundary that depends heavily upon doing the KDF for the chain key and
next root key correctly. Axolotl implementations that mess this up
create keep some obnoxious temporary-but-not-actually-ephemeral
Anyways, there are bad design decisions, like adding a signature to
TripleDH, that result from blindly treating ephemeral capabilities as
* There are weird low entropy settings like smart cards where
apparently ephemeral keys can be compromised much more easily.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 819 bytes
Desc: This is a digitally signed message part
More information about the Messaging