[noise] MAC'ing recipient public key

[Stephen Touset]

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

> On Tue, Jul 29, 2014 at 5:34 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 pub key.
>> 
>> Do you mean for this to be protection against an active attacker (who can simply ignore the authentication tag), or only to indicate an accidental attempt to decrypt a box you don’t have access to?
> 
> I garbled my explanation.
> 
> It's a property of some elliptic curve systems that your public key
> might be representable as a few different values (this has to do with
> "cofactors"...).   So I could encrypt something that you can decrypt
> even if some weirdo in the middle changed your public key to a
> different representation that you didn't immediately recognize as your
> public key.
> 
> That's often ignored and doesn't really amount to an attack, but it's
> annoying so it's good to "bind" all the public keys some way, such as
> including them in the MAC or encryption.

Ah, thanks. That makes sense. It *looks* like I may have been wrong about the asymmetry between client/server communications. Am I correct in my reading of the spec now that *both* times you include the recipient’s ephemeral public key in the AAD (and not their long-term key)?

-- 
Stephen Touset
stephen at squareup.com