[noise] MAC'ing recipient public key

[Trevor Perrin]

On Wed, Jul 30, 2014 at 10:56 AM, Stephen Touset <stephen at squareup.com> wrote:
>
> 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)?

Yes, in both the client and server boxes, the recvr_pubkey is actually
the ephemeral pubkey, which I'll try to make clearer by renaming it
target_pubkey later.

The box sender's long-term public key is bound by being explicitly
encrypted, so doesn't need to be included in the AAD.

Trevor


>
> --
> Stephen Touset
> stephen at squareup.com
>