[noise] MAC'ing recipient public key

[Stephen Touset]

On Jul 29, 2014, at 4:04 PM, Trevor Perrin <trevp at trevp.net> wrote:

> 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?

Probably. I’d also be happier if the abstraction between boxes and pipes was a little less leaky. For instance, in the pipe spec:

	Client->Server: noise_box((C',c'), (C,c), S', pad_len, app_data, 4, cv_h1)[DH_LEN:]

Implementation details about the boxes (that there’s an ephemeral key in the first DH_LEN bytes of the box) have leaked out to the pipes. Perhaps some of this is unavoidable, but it seems to me that having details like that leak out makes the spec more confusing, more difficult to implement, and more difficult to analyze.

-- 
Stephen Touset
stephen at squareup.com