[noise] SAS (was: Explicit nonces (for lossy transports)
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
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...
More information about the Noise