[noise] SAS (was: Explicit nonces (for lossy transports)

[Rhys Weatherley]

On Wed, Jul 12, 2017 at 11:13 AM, Trevor Perrin <trevp at trevp.net> wrote:

> Thinking about this more:
>
> Short Auth Strings are useful for things like "pairing" two devices by
> checking that they display the same short code, or maybe even for
> voice authentication between two parties, where their phones display a
> short string which they verbally compare.
>

Bluetooth Secure Simple Pairing (SSP) is another example of such a pairing
protocol which is used in devices everywhere.  You can find the Core spec
online for the gory details, but summarising: the two devices perform a
crypto dance with ECDH and a bit commitment scheme to agree upon a shared
secret and a 6-digit number to display on the screens for cross-checking.

In Noise terms, the shared secret is a PSK generated from the pairing
session which is then used to set up subsequent sessions between those two
devices.

SSP also has support for incorporating the hash of a password/pin into the
crypto dance.  Useful if the headset or whatever comes with a pin printed
on it.

A rough analogue in Noise for SSP would be "Noise_NNpsk0+sas" where
Hash(pin) is the input PSK.  Then generate a PSK from that session for use
in setting up subsequent Noise_XXpsk0 or whatever sessions.

As an aside, maybe generated PSK's can be incorporated as a "genpsk"
modifier and token:

    Noise_NNgenpsk+psk0+sas:
      -> psk, e, commit
      <- e, ee
      -> reveal, genpsk

Where the "genpsk" token is defined as:

    ck, generated_psk = HKDF(ck, zeroes, 2)

I know we've discussed before how to generate PSK's from the Split() cipher
states, but I do sort of see PSK generation as a handshake function rather
than a transport function.  A token fits better.  IMHO.

Cheers,

Rhys.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://moderncrypto.org/mail-archive/noise/attachments/20170712/3532782f/attachment.html>