[noise] noisecat: the noise swiss army knife

[Gerardo Di Giacomo]

Hi Trevor,

Thanks a lot for the feedback and thank you the amazing work you're doing with Noise.

I started writing this tool as I needed to connect to some Noise endpoints and didn't know how to do it. Then I decided to generalize it and release it so others that are in my situation can benefit from it as well. I'm a security guy so the use cases I'm aiming at, other than regular client->server connections, are around creating encrypted tunnels for proxying, bind/reverse shells, network pivoting/exploration, etc.

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.

> 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. If you notice I excluded all K* handshakes as with the current design the end that runs the server cannot know what the public key of the client/initiator is.

> 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. But as I said it's all still work in progress :)

Again, thanks a lot for the feedback, I really appreciate it!

Gerardo
 

On 2/28/18, 1:46 AM, "Trevor Perrin" <trevp at trevp.net> wrote:

    On Wed, Feb 28, 2018 at 9:23 AM, Trevor Perrin <trevp at trevp.net> wrote:
    > On Tue, Feb 27, 2018 at 4:40 PM, Gerardo Di Giacomo <gdg at fb.com> wrote:
    >> Hello everyone,
    >>
    >> I wrote a netcat-like tool for noise protocol: noisecat - https://github.com/gedigi/noisecat
    >
    > Hi Gerardo,
    >
    > Nice!  I was going to steer you towards NoiseSocket, but looks like
    > you don't need any length/framing bytes, since both sides are
    > configured with knowledge of the handshake and then just forward
    > streams.  So this ends up really simple...
    
    Sorry, my comment above was nonsense, looks like you have a 2-byte
    framing layer.  Of course some framing is necessary if you have
    variable-length transport messages...
    
    I guess I'd still point you towards NoiseSocket or even one of the
    constructions we've considered on top of it, like [1].
    
    These are works-in-progress but I'd like to get people experimenting
    and trying to interop / standardize on these higher-level conventions.
    
    The benefits for your case perhaps aren't much, since you may not care
    about any sort of negotiation.  But using NoiseSocket framing wouldn't
    cost much either, just an extra 2 bytes for handshake messages.
    
    Trevor
    
    [1] https://urldefense.proofpoint.com/v2/url?u=https-3A__moderncrypto.org_mail-2Darchive_noise_2018_001473.html&d=DwIBaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=GIepR9z8-ZaJVGguJ5xifg&m=gFbdESCVQjOaulO7g8Mjqd2yfMqPmC61EfzgcvneoDQ&s=5hvtoVpIk8pd3x9TPddI7zLZ6Tgb48TvdDuZCiG3tR4&e=