[noise] post-handshake authentication

[Trevor Perrin]

On Thu, Jun 21, 2018 at 8:52 AM, David Wong <davidwong.crypto at gmail.com> wrote:
>> I don't quite follow the protocol.  But what you're asking for seems
>> similar to the ASK / Additional Symmetric Keys mechanism that we're
>> discussing in the "Resumption PSKs" thread?
>
> It's like Signal's TOFU + fingerprint authentication except that here
> you just can't go on with the session if you don't verify
> fingerprints.

This isn't all that similar to Signal - Signal's safety number is a
concatenation of fingerprints for long-term public keys, but here
there are no static public keys.


> I didn't want peers to cheat their way and activate the session when
> they haven't retrieved the fingerprint out of band. With the current
> ASK mechanism a peer could generate the fingerprint and pass it back
> to the implementation and it would work. Note that this doesn't have
> to be a problem solved by the protocol, the implementation could add
> an initiator/responder byte to the ASK. I'll give an example since
> it's always more easy to follow:
>
> * initiator does NN() with responder
> * at the end of the handshake the CipherStates are locked
> * initiator generates an "authentication string" or "fingerprint" with
> exportSessionAuthenticationString()
> * it returns a byte string [1 | ...] (where ... represents a 32-byte secret)


You're trying to enforce some authentication check, but it's not clear
whether this is just a calling sequence you want the library to
enforce on it's user, or whether this needs to affect the underlying
crypto.

Since the 2 parties have the same symmetric keys and hash values, I'm
not sure it makes sense to modify the underlying crypto to require one
party to provide a symmetric crypto-based value to the other, since
both parties can compute the same things with their symmetric keys?

If you just want 2 different representations of the handshake hash,
you could hash it with "1" or "0" prepended, something like that.

But it's a little unclear to me whether you want a secret value (like
from ASK) or just a public authentication value like a public-key
fingerprint, which could be derived from the handshake hash without
using ASK at all.


Trevor