[noise] MAC'ing recipient public key

[Trevor Perrin]

On Tue, Jul 29, 2014 at 3:07 PM, Stephen Touset <stephen at squareup.com> wrote:
>
> On Jul 13, 2014, at 10:08 PM, Trevor Perrin <trevp at trevp.net> wrote:
>
>> Another change:
>>
>> The recipient pubkey is included in the additional authenticated data
>> for both box MACs.  This ensures that if the sender can decrypt a box,
>> it must have been encrypted to the sender's pubkey.  While this can
>> also be accomplished by taking care with the ECDH, I think it's
>> simpler to just include the recipient's key into the mac.
>
> Perhaps I’m overlooking something, but this seems impossible to reconcile with pipes.
>
> When a server first sees a client, the only thing they receive is the client’s ephemeral key. They have no forehand knowledge of the client’s long-term public key, and thus cannot properly compute the MAC.

Right, but from the perspective of the server's noise_box(), the
recvr_public_key which is being MAC'd is the client's ephemeral key.

The fact that standalone Noise boxes are targeted to long-term keys
and Client/Server boxes are targeted to ephemeral keys is indeed
confusing.  Maybe the recvr_pubkey should be renamed to target_pubkey,
and we should have a clearer treatment of standalone boxes vs
client/server boxes?

Trevor