[noise] Omitting client's ephemeral pubkey from client's box

Trevor Perrin trevp at trevp.net
Tue Jul 29 16:42:52 PDT 2014

On Tue, Jul 29, 2014 at 3:17 PM, Stephen Touset <stephen at squareup.com> wrote:
> On Jul 13, 2014, at 10:47 PM, Trevor Perrin <trevp at trevp.net> wrote:
>> Another change:
>> In the pipe handshake, the ephemeral public key that begins the
>> client's box was redundant, since it was already sent in the client's
>> first message.
>> I was leaving it in to make the protocol description simpler.  But I
>> think there are better arguments to remove it:
>> * The server might forget to check that the client's ephemeral public
>> key matches in the first and second messages.  I _think_ that's still
>> OK, but it would be simpler if we didn't have to worry about that.
>> * If Noise pipes are used with a padding scheme that tries to hide
>> whether resumption was performed (like [1]), then we'd probably want
>> the value omitted.  So that argues for just doing it now.
>> * It saves DH_LEN bytes to omit it.
>> https://github.com/trevp/noise/wiki/Pipes/_compare/74788e04ea370f5a5364599fefb316111a5e31fe...b70208389b33d56a71c50e4e34a22785e6cc7eea
> For the sake of conceptual simplicity, it may be worth redefining the NoiseBox to not actually include the ephemeral key. Then the pipe protocol is:
>         Client->Server: C'
>         Client<-Server: S' || noise_box((S',s'), (S,s), C', pad_len, app_data, 2)
>         # outputs cv_h1
>         Client->Server: noise_box((C',c'), (C,c), S', pad_len, app_data, 4, cv_h1)
>         # outputs cv_h2

Your probably right about that.  If no-one disagrees I'll try to
change the presentation tomorrow, and we can see how it looks.


More information about the Noise mailing list