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

Rhys Weatherley rhys.weatherley at gmail.com
Wed Jul 12 00:30:05 PDT 2017

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

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:

      -> 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.


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

More information about the Noise mailing list