[noise] Heresy: PSK-only Noise

[Trevor Perrin]

On Sun, Jun 10, 2018 at 1:11 AM, Rhys Weatherley
<rhys.weatherley at gmail.com> wrote:
>
> Here's an alternative proposal for a custom protocol with a name template of
> "PSK_<Cipher>_<Hash>" - an example instantiation is "PSK_ChaChaPoly_SHA256"
> (I've left off the "Noise_" prefix to avoid giving the appearance of being a
> standard Noise protocol):
>
> PSK():
>     -> psk, nonce
>     <- nonce

Cool, some comments:

A more distinctive framework name than "PSK" would probably be better,
but I think that's a fine placeholder name for the moment.

Would there be a one-way version of this?  Maybe that would justify a
pattern name component, e.g. PSK_1_ vs PSK_2_ or something?

There's nothing here that transmits a psk identifier.  But I guess
we've left that to NoiseLingo/NLS, so you could use that.


> where the "nonce" token is defined as follows (writing side only, reading
> side is similar):
>
>     v = a new random 32-byte value
>     k = the first 32 bytes of HASH(v)
>     Append k to the buffer
>     MixKeyAndHash(k)
>     discard k and v

Maybe overly prescriptive?  The nonce just needs to be unique.  You
could probably allow it to be a variable-length byte-sequence, at
least 16 bytes in length, and then defer example constructions like
this to a Security Considerations or something.


>> Justin and Tony could be right that a lot of use-cases might be better
>> served with public-key crypto, so I'd be a little concerned about
>> steering people towards "premature optimization".  Maybe there's an
>> ultra-low end that could benefit here, but I'd also wonder about what
>> exact protocol they need: something more Kerberos-like?  or more
>> key-tree like, for example?
>
>
> In my inbox at least, peer-to-peer uses cases feature a lot, such as sending
> control commands from a desktop machine to a robot wandering around the
> house.  Clients sending sensor data to a common server also feature (IK /
> Noise Pipes is ideal for this if the device is capable of public-key
> cryptography).
>
> LoRA has popped up a lot lately too, which brings a whole other set of
> problems, being datagram-based with small message payload sizes.  Some data
> rates support only 51 bytes of payload which gets very squeezy once you add
> 16-byte MAC's and 8-byte sequence numbers to a transport packet.  I've
> pondered the use of a 1 or 2 byte sequence number and with a sliding window
> to provide the high bytes.  Even the handshake is a problem with LoRA.
> NNpsk0_Curve25519 might just fit, but XX_Curve25519 and IK_Curve25519 won't
> fit without fragmentation.  Something to consider for datagram-based
> NoiseLink.

Interesting, don't know much about these cases.  I had proposed a
NoiseTinyLink which keeps things a little simpler and smaller than
NoiseLink, but maybe not enough to make a difference in these cases.

https://github.com/noiseprotocol/nls_spec/blob/rev2/output/nls.pdf

Trevor