[noise] noisecat: the noise swiss army knife

[Trevor Perrin]

On Fri, Mar 2, 2018 at 5:42 PM, Gerardo Di Giacomo <gdg at fb.com> wrote:
>
>> On Mar 2, 2018, at 1:58 AM, Trevor Perrin <trevp at trevp.net> wrote:
>>
>> Anyways, I'll try to kick off a couple spec drafts on some of these
>> higher layers this weekend, hopefully this will make things clearer.
>
> That's great! Looking forward to them! Is your ultimate goal for Noise to propose it as RFC?

I think we're better off handling specs and processes ourselves,
rather than transferring control to a different organization.

So I've got an "NLS" draft up [1].  I'm thinking about how it would
fit with your tool:

I think you could generate NLS handshakes where the initial_protocol
is populated (the minimum required), and other fields can be specified
on the command-line (server_name, psk/psk_id, evidence blobs,
transport_options).  I wouldn't expect the tool to handle switching or
retrying protocols, but if you specified the right options it would be
able to interop with NLS profiles (like NoiseLink, NoiseZeroLink,
etc).

Key verification is more complicated...


> Yes, currently rstatic is to provide the public key of the other end for K patterns. A key verifier is missing and if you read at the bottom fo the README it's something I want to add. But I'm still not 100% sure how to do it; noisecat is a tool and not a library, so the verifier needs to be an external binary or some other mechanism that doesn't involve touching code.

The simplest verifier could just compare the remote party's static
public key to -rstatic (or a different argument, if you don't want to
overload -rstatic).

For something more sophisticated, you'd have to send the static key
and NLS evidence blobs to some other command, I guess?  Not sure what
that would look like...

Trevor

[1] https://github.com/noiseprotocol/nls_spec/blob/master/output/nls.pdf