[noise] noisecat: the noise swiss army knife

[Gerardo Di Giacomo]

> On Feb 28, 2018, at 11:47 PM, Trevor Perrin <trevp at trevp.net> wrote:
> 
> However, I'd love to see Noise-over-TCP users align on framing and
> negotiation, so projects can share code, tests, and design burden, and
> have more potential for interop.  If that happens, having tools like
> noisecat be able to connect widely with other things would be great
> for testing, debugging, lightweight tunnels, etc.
> 
> In that direction, I think there's a couple interesting levels of compatibility:
> 
> * If we follow the rough plan in [1] we'd combine the low-level
> NoiseSocket framing/encoding with some higher-level negotiation
> language, so we could send (e.g.) protobufs in the handshake to offer
> and choose particular Noise protocols, send certificates, etc.
> "Profiles" could choose some subset of Noise protocols and the
> negotiation language.  Having generic tools that supported all this
> and could work with different profiles would be very useful.
> 
> * We could probably design higher-level negotiation such that empty
> handshake payloads and negotiation_data signal default values.  If so,
> just using the minimal NoiseSocket framing might achieve rudimentary
> interop with other things.

I'm aligned with your thoughts and I agree that formalizing a stack that covers all the three points is the ideal goal for Noise to make it more broadly accessible. I would love to help you with defining the missing elements to allow full interop, although I'm not a protocol designer or a crypto analyst, and I'm unsure how progress is currently being made.

I will surely keep up with whatever will be defined and will update noisecat accordingly. I already have a working "noisesocat" that uses NoiseSocket (I took a look at go-noisesocket yesterday), which I'm deciding whether to have as a separate binary or integrated in noisecat - leaning towards the former.

> I see you've already added -lstatic and more patterns, great!  I
> wonder if "rstatic" could also be applied to check a transmitted
> public key?  Or maybe that could be a separate argument.


I'm not sure what you mean. The rstatic switch is used to verify the public key of the remote end, even when it's transmitted. Do you mean that it should also allow to verify/authenticate a public key, similar to PKI?

Gerardo