<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Sat, Jun 9, 2018 at 2:52 PM, Trevor Perrin <span dir="ltr"><<a href="mailto:trevp@trevp.net" target="_blank">trevp@trevp.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">So one possibility is that what you're thinking wouldn't quite be<br>
Noise but could be a sibling protocol or framework, sharing a lot of<br>
components and able to coexist within NLS?<br></blockquote><div><br></div><div>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.<br></div><div><br></div><div>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):</div><div><br></div><div>PSK():</div><div>    -> psk, nonce</div><div>    <- nonce<br></div><div><br></div><div>where the "nonce" token is defined as follows (writing side only, reading side is similar):</div><div><br></div><div>    v = a new random 32-byte value<br>    k = the first 32 bytes of HASH(v)<br>    Append k to the buffer<br>    MixKeyAndHash(k)<br>    discard k and v<br></div><div><br></div><div>Everything else is the same in the handling of SymmetricState, Split(), transport keys and re-keying, NoiseLink negotiation, etc.</div><div><br></div><div>It's possible that the "nonce" token may be useful in other protocols.  Or not.</div><br><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">

Justin and Tony could be right that a lot of use-cases might be better<br>
served with public-key crypto, so I'd be a little concerned about<br>
steering people towards "premature optimization".  Maybe there's an<br>
ultra-low end that could benefit here, but I'd also wonder about what<br>
exact protocol they need: something more Kerberos-like?  or more<br>
key-tree like, for example?<br></blockquote><div><br></div><div>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).<br></div><div><br></div><div>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.<br></div><br></div>Cheers,</div><div class="gmail_extra"><br></div><div class="gmail_extra">Rhys.<br></div></div>