RFC: Noise Crypto Upgrayedd

[sempervictus]

Noise is "all the rage" these days, and the folks at Virgil Security are pushing the Noise socket spec as a standard implementation for stateful transports without ASN.1 requirements. This mechanism might be a great underpinning for C2 and/or enhancement for the TLVCrypt (12055fc) functionality. There's multi-target sending, strict standardization of cryptographic implementations, light weight, etc etc benefit in the session layer. It's going into OSSEC already, and we should probably be at least as cool as blue team. The skeletal muscle of that effort is libnoisesocket, which is a lot of (really well commented C) providing a bunch of building blocks and organizational structure for "safe-ish implementation."
The most interesting piece i see is the 0RTT implementation, as it should permit us to send TLVs async across whatever abstracted channels we want and maintain session state, so to speak. If we are clever, we could also "pregame" the state negotiation into stage1, and use that functionality to establish an encrypted session without wire-visible negotiation (DH has a foreseeable lifespan).
The whole thing is sort of designed to be picked apart to build efficient implementations, so i think we can get away with cannibalizing and cleverly hacking together the pieces they have in C into Ruby, Python, maybe PHP, and our own C code - its BSD licensed and we've a green light to slice it up as we will if we choose to use it.
I'm not going to do that writeup the injustice of trying to qualify the functional benefits as pertaining to each tier of our functionality, but i imagine @busterb and his team, as well as @OJ, @zeroSteiner, @tarcieri, and @ddain might do a better job in their domains of expertise if they take an interest in this issue. Also, thanks @bcoles for kicking me in the posterior to start organizing this stuff in the GH issue tracker.

[wvu]

Upgrayedd

I see what you did there.