[noise] ECDH Authentication - Signatures vs Authenticated Encryption

[Jason A. Donenfeld]

On Mon, Jul 6, 2015 at 5:37 PM, Trevor Perrin <trevp at trevp.net> wrote:
>>>   <- 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.
>
> That follows because there's no k yet, so the values read / written
> are in the clear.  Does this need to be explicit?

That's a good point. Probably not necessary, but it could be clarifying.

> The exchange of authenticated-encryption ciphertexts is intended to
> naturally provide "key confirmation".  But I need to add some text to
> clarify when this happens, and in general clarify which properties
> apply to which messages.

This would be great - thanks.

>
> I think that makes several assumptions specific to your use case:
>  - there's a limited and known set of clients, so it's feasible for
> servers to track a single record for each of them
>  - clients can't have multiple simultaneous sessions with the server
>  - clients have reliable clocks
>  - servers have durable storage

While you're right about the first two points, the last two aren't
necessarily true. A client needs only to have a monotonically
increasing clock to work always, and a mostly-increasing clock to work
mostly. This is because the server can simply store the most recent
timestamp it's received from a client, removing the need for clock
accuracy. Alternatively if clients as well as the server do have
accurate clocks, then the first point is no longer a problem, as the
server can check against the current time, though I'm not a fan of
this. The server doesn't need durable storage, because the replay
attack is only a problem in so far as it would disconnect an already
connected session. When a server reboots, no clients are already
connected to it, so the most an attacker could do is begin a new,
unreadableunwritable, session, that would then be disconnected as soon
as the real client sends a newer (fresher) handshake.