[noise] Session identifiers

[Trevor Perrin]

On Mon, Apr 18, 2016 at 9:37 PM, Rhys Weatherley
<rhys.weatherley at gmail.com> wrote:
> On Tue, Apr 19, 2016 at 1:46 PM, Trevor Perrin <trevp at trevp.net> wrote:
>>
>> So I believe the important property is uniqueness, not secrecy.  The
>> higher-level signatures that are calculated over the channel binding
>> are sent inside the SSH transport encryption, so secrecy is already
>> provided.
>
>
> The signature is secret.  What is being signed (the session identifier) is
> not.  Paranoia again.  Knowing what is signed, combined with timing
> information, might pry open the signing key.

You've got a major problem with your signing code (or DH code) if it's
leaking private-key info through timing!


> It's not a big deal though - "h" can be combined with a secret nonce value
> to produce a value to be signed instead.  The signature scheme should
> probably be using nonce anyway.

It's pretty well-understood that crypto software needs to be hardened
against leaking private keys through "software side-channels" (like
timing, memory accesses, or branching), and serious crypto software
will already have countermeasures like constant-time code, or
blinding, without needing protocol support.

(Also, the signature will typically be sent from one party to another
so making the session ID  - known to both parties - secret from 3rd
parties wouldn't stop the two counterparties from extracting each
other's private key!)

>
> I'm good with "h" being the Noise version of session identifiers for now
> until such time that some academic crypto nerd objects with an interesting
> paper as how to abuse the public session identifier to wriggle into a user's
> session.
>
> Like Alex, I'll add a function / extra result from Split().

Cool me too - to Alex's earlier point about API standardization, we
could call this the "handshake hash", unless there's a better idea.

Trevor