[noise] Heresy: PSK-only Noise

[Luke Mather]

Hi Rhys, all,

I'd like to chime in on this one --- we're using Noise on some 
relatively low-end platforms and work on the security of embedded 
systems in general.

A point I'd like to make is that often when you're talking about going 
so low-end that you can't afford DH there always tends to be at least 
one additional frustration that makes deploying even symmetric-only key 
exchange non-trivial --- RNG quality, bandwidth limitations, code size, 
implications of power loss and so on --- and whilst there are bound to 
be some deployment environments that would benefit from a basic Noise 
analogue for e.g. a TLS 1.3 PSK handshake that uses the exchange of two 
randoms to derive a session key, I'm not convinced the overloading of 
terminology and structure you'd have to do inside the Noise API to get 
that to work is worth it.  One of the major selling points of Noise that 
I can use is how clean the state machine and API is.

I do think there's an incredible amount of value in speccing out how to 
do authenticated key exchange when you can't afford DH, and Noise has 
some lovely prescriptiveness about usage of handshake transcripts that 
is reusable, but I think such a spec should ideally look like a list of 
"if you're in situation X then you should do Y" scenarios rather than a 
single protocol definition.

The point about the benefits of having a migration path back up to DH 
that doesn't require you to swap in a completely new library is a good one!

Cheers,

Luke

On 09/06/18 05:52, Trevor Perrin wrote:
> 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
> _______________________________________________
> Noise mailing list
> Noise at moderncrypto.org
> https://moderncrypto.org/mailman/listinfo/noise
> 

-- 
Luke Mather
----------------------------------------------
Cerberus Security Laboratories Ltd.
Office:  +44 (0)117 214 1366 (Direct)
Web:     www.cerberus-laboratories.com
Twitter: @cerberuslabs

Cerberus Security Laboratories is a company registered in England & 
Wales, Registered number: 10444272.
Registered Office: Woodlands Grange, Woodlands Lane, Bradley Stoke, 
Bristol BS32 4JY. United Kingdom