[noise] noisecat: the noise swiss army knife

[Trevor Perrin]

On Wed, Feb 28, 2018 at 7:14 PM, Gerardo Di Giacomo <gdg at fb.com> wrote:
>
> The tool is still extremely work in progress and I'm actively developing it, so I will surely take a look at NoiseSocket and to the other constructs you mentioned. Probably NoiseSocket makes even more sense for some of the scenarios I have in mind.

Yeah, I guess it depends on your goals.  If noisecat only needs to
talk to itself then more complex framing and negotiation isn't really
needed.

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 not sure how the local party's static key pair is set?
> For now, the keys are generated at runtime and exposed to the user (with -v) in case the handshake requires it. I'm planning to add a key generator switch that writes the keys to a file, so they can be loaded instead of being generated each time.

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 also wonder if the use of patterns could be simplified?  E.g. based on the keys the user specifies, could you just automatically choose a pattern from (NN, NK, KN, KK)?
> Yes, I could do that, but I wanted to provide better precision in the setup phase. If a user specifically needs a handshake type, I'd rather let them choose it and then check at runtime if all the required parameters are set. The other issue is that if I infer the handshake type based on parameters, then I'll have to add more flags to choose the DH, cipher, and hash functions, so I preferred to have a single "-proto" switch and use a full protocol name.

Cool, that all makes sense.

Trevor

[1] https://moderncrypto.org/mail-archive/noise/2018/001473.html