[noise] Heresy: PSK-only Noise

[Trevor Perrin]

On Fri, Jun 8, 2018 at 7:09 AM, Rhys Weatherley
<rhys.weatherley at gmail.com> wrote:
> Just to add a little more.  I realise that PSK-only encryption is heresy,
> but what I'm looking for is a good way to say:
>
> 1. If you really must do shared key encryption, then here is how to do it
> well, and ...
> 2. There is a simple migration path to "Real Noise" should one obtain
> hardware with better capabilities.  Change the selected Noise protocol.
> Recompile.
>
> Justin mentioned ESP32 and the changing landscape.  The ESP32 chipset has
> convinced me that mid-range Arduinos are now in a position to run "Real
> Noise" well, which is why I'm now looking to add it to my library.  But I
> still have a hole at the low end for "here's how not to do shared key
> encryption wrong".


Hey Rhys,

One question is whether Noise provides useful features for pure-PSK
protocols, and if so what?

The contortions needed to adapt Noise's DH patterns to a pure-PSK
protocol seem awkward.  It might be easier to just specify your
protocol from scratch with some symmetric keys and nonces, instead of
trying to shoehorn this into a pseudo-DH thing.

But aside from the patterns, maybe there's other parts of Noise that
would be useful?

 * The SymmetricState layer and other symmetric-key stuff: MixHash()
and MixKey(), rekey(), maybe the new additional-key notions could be
useful; and we'll probably continue to upgrade all this to support new
types of crypto (on the lines of Disco).

 * The NoiseSocket and NoiseLingo layers are loosely coupled to the
Noise core.  I've thought of them as like sandwich bread or a
clamshell with the "Noise core" in the middle, with the idea that the
core was the constant part of Noise, and we could replace these
framing / negotiation layers.  But you could also think of NLS as a
constant framing/negotiation structure that you could fit different,
even non-Noise protocols into, provided they met some minimal
requirements (could be named with a string, could handle a prologue
input).

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?

It's interesting to think about because it puts pressure on our
abstractions and APIs from a different direction, and maybe it would
point out ways we should refactor our terminology or extension docs 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?

I also wonder whether anyone else was interested in pure-PSK protocols
reusing any of the Noise machinery, not sure if this dovetails with
some of Tony's plans, or anyone else's?

Trevor