[noise] What needs forward secrecy? (for Disco)

[Trevor Perrin]

On Sat, Dec 2, 2017 at 2:02 PM, David Wong <davidwong.crypto at gmail.com> wrote:
>
> I really fail to see the point of forward-secrecy for a few milli
> seconds or a few handshake messages.
> Haven't we reached a point where we're over-using forward secrecy?
[...]
> * I do not understand the point of intra-handshake forward-secrecy, or
> rather I see it as just "too much"

Here's an example where intra-handshake forward secrecy matters:

 * Client device sends an initial 0-RTT encrypted message (e.g. NKpsk0
with a single-use PSK).
 * Client device "goes to sleep" before receiving a response,
persisting its current memory state in some way.
 * Client device's memory state is compromised before waking up.

If you have "intra-handshake forward secrecy" and the client deletes
the PSK after sending the initial message but before persisting its
state, then the initial message would remain secure.

This is probably an uncommon case:  Mostly the handshake will complete
quickly, and/or there won't be any key that can be deleted during the
handshake for forward secrecy.

Nonetheless, I don't think new crypto should have worse security for
*any* cases.  I also don't think it's worth the complexity to try to
distinguish these cases and perform different MixKey() operations for
them.


>> The KDF has to be secure when given a single good input, even if
> all other inputs are malicious.  For example, maybe you're given a
> malicious PSK, or maybe someone sends you a malicious ephemeral public
> key, to try somehow "cancel out" the "es" or "se" DH that performs
> authentication.
>
> you won't be able to cancel out anything by absorbing malicious inputs

I was discussing the possibility that the "hash has weaknesses".  In
that case, the "extra" sponge operations might preserve security.
We've taken a similarly conservative approach with HKDF (which could
also be argued to be overkill).


>> Also, I think things are easier to analyze if they are consistent. In
> this case, if we always RATCHET in MixKey, then every new KDF input
> gets processed in the same way, using the same part of the permutation
> (I think).
>
> I see what you're saying but I still don't think it is important that
> everything is alligned.
> There are no "confusion" attacks here as the padding of Strobe makes
> sure that every operation is absorbed verbosely. There is no
> ambiguity.

There are no "confusion" attacks because of the Noise design.  We
don't need the Strobe padding and type fields.  If you wanted to
remove unnecessary features to simplify, you could remove that.


>> While I thought Mike was right, it also seems more conservative and
> simpler to analyze if we use the function in such a way that the key
> material is always at the same location.
>
> Isn't the problem with Gimli that it was not hermetic? (as opposed to keccak-f?)

I think that's the right term, but I'm no expert here.


> I don't see these reasons as strong enough since we're using keccak-f,
> but I've honestly not spent enough time there to know if we're right
> or wrong.

I assume Strobe and Disco should be generic enough to work with other
permutations? (e.g. Xoodoo, maybe Gimli)?

If your function always absorbs the key material in the same way it's
easier to analyze, including in cases where the sponge is not hermetic
(by design *or* cryptanalytic weakness).


Trevor