[noise] ECDH Authentication - Signatures vs Authenticated Encryption

[Jason A. Donenfeld]

On Sun, Jul 5, 2015 at 8:30 AM, Trevor Perrin <trevp at trevp.net> wrote:
> key.  So you could modify above to authenticate the first message
> using static-static DH: does this work?
>
>   <- s
>   ******
>   -> e, dhes, s, dhss
>   <- e, dhee, dhes

Yes, this works I think. So the first step is a BoxX.

One immediate concern, however, is that it destroys PFS of the
anonymity. If the responder's private s is ever compromised, an
attacker who has been recording network traffic can then learn all the
public keys who have communicated. This might be an acceptable and
unavoidable tradeoff, though, in which case, I guess I'm fine with it.

Question: is KCI a problem with this handshake?


>   <- s
>   ******
"s: The creator performs an encrypted write of her static public key. "
"Pre-messages are not part of the protocol proper, but the parties
should create and consume them as if they were."

It might be worth noting that these pre-messages don't involve
changing the nonce, though.


>
> This doesn't have a name yet, but it's perhaps another class of
> protocols we could add.

That would be great. A lingering concern is something I read in the
KEA+ paper -- that it's been *proved* that a two step handshake will
never be able to have certain robust security properties, leading the
authors to propose KEA+C, which includes an additional confirmation
back-and-forth. I'm not sure how relevant this is to noise though.
What's up here?

> Replay of the first message is a real problem.  No great solution I
> know short of timestamps or blacklists.

Well in that case, can I propose we add djb's TAIA to the noise
standard? QuickTun uses it in a clever way -- here's how they
implement it -- https://gist.github.com/anonymous/1af32dd7103295aba4e5
. The upside is that you can compare timestamps with the return value
(-1, 0, 1) of a simple memcmp. I'd propose adding something to the
descriptor entities like:

τ: Perform an encrypted write of the packed TAIA timestamp.

Then the above handshake you proposed could be augmented as:

<- s
******
-> e, dhes, s, dhss, τ
<- e, dhee, dhes

For a server, it's simple enough to keep track of the latest τ
received from a given client, to avoid a replay DoS that causes the
currently communicating client to have his key invalidated. If a
server restarts, and the stored latest τ value is lost, a replay
attack isn't really a problem since there's no session to interrupt
anyway, and subsequent client connections will have a greater τ
anyway. After a restart an attacker will still be able to rouse a
response message out of a server, but at this point the "stealthiness"
concern is no longer an issue since an attacker in a position to
launch a replay attack is already aware there's a service behind that
port. And the allocation DoS previously described still isn't a
problem because the attacker is still limited to a fixed amount of
preallocated resources. I think this is therefore a satisfactory
solution.