[noise] MAC'ing recipient public key
trevp at trevp.net
Tue Jul 29 16:04:21 PDT 2014
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
More information about the Noise