[noise] Heresy: PSK-only Noise

[Rhys Weatherley]

On Sat, Jun 9, 2018 at 2:52 PM, Trevor Perrin <trevp at trevp.net> wrote:

> So one possibility is that what you're thinking wouldn't quite be
> Noise but could be a sibling protocol or framework, sharing a lot of
> components and able to coexist within NLS?
>

That's basically what I'm thinking.  There's a lot of infrastructure in
packet formats, network stack, protocol negotiation, transport keys,
re-keying, storage of key values in a local key ring, and so on that are
virtually identical.  The PSK-only use case still needs all of that to be
defined.  Better to have one set of infrastructure classes in my library
than two.

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

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

Everything else is the same in the handling of SymmetricState, Split(),
transport keys and re-keying, NoiseLink negotiation, etc.

It's possible that the "nonce" token may be useful in other protocols.  Or
not.

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.

Cheers,

Rhys.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://moderncrypto.org/mail-archive/noise/attachments/20180610/6a396207/attachment.html>