[noise] [NoiseSocket] First handshake message parsing questions

[Alexey Ermishkin]

Another question that I'd like to discuss once again is sub-messages naming.

Do we really need to switch from Noise_XX_blablabla to NoiseSocket_blablabla? The pattern logic is the same and we have our mandatory prologue if we want to differ (why?) from other implementations
I really want to add IK support to the first version and it will look ugly to use NoiseSocket for XX and Noise_IK for IK

-----Original Message-----
From: Trevor Perrin [mailto:trevp at trevp.net] 
Sent: Monday, February 27, 2017 3:58 AM
To: Rhys Weatherley <rhys.weatherley at gmail.com>
Cc: Alexey Ermishkin <scratch.net at gmail.com>; noise <noise at moderncrypto.org>
Subject: Re: [noise] [NoiseSocket] First handshake message parsing questions

On Sun, Feb 26, 2017 at 2:19 PM, Rhys Weatherley <rhys.weatherley at gmail.com> wrote:
> On Mon, Feb 27, 2017 at 6:24 AM, Trevor Perrin <trevp at trevp.net> wrote:
>>
>> I was thinking the client would send:
>>
>> version with explicit 25519 ephemeral version with implicit 25519 
>> ephemeral version with implicit 25519 ephemeral ...
>>
>> version with explicit 448 ephemeral
>> version with implicit 448 ephemeral
>> version with implicit 448 ephemeral
>> ...
>>
>> That would save bytes in case you're offering, say, a 25519 public 
>> key with several different ciphers.
>>
>> But Rhys is probably right that for simplicity we should just have 
>> all initial messages be explicit.
>
>
> Here's an alternative I thought of after sending my previous message:
>
> 0: XX_25519...AESGCM with explicit 25519 ephemeral
> 1: XX_25519...ChaChaPoly, duplicate 0
> ...
> 8: XX_448...AESGCM with explicit 448 ephemeral
> 9: XX_448...ChaChaPoly, duplicate 8
>
> For implicit sub-messages, the number of the previous sub-message "e" 
> that is being duplicated is given.  Then the responder doesn't have to 
> "just know" which of the previous messages is being implicitly duplicated.

Is that actually easier to parse than just having zero-length implicit messages use the previous non-zero-length explicit message?

I would think looking up an explicit message by number is more complicated than just always using the previous one?

> Duplicating the entire packet makes the scheme easier to extend to 
> HFS: it's not just the "e" that is elided, but "e, f".

That makes sense.

(I'm still fine with leaving out implicit message support, or including it, I think.)

Trevor