[noise] Replacing TLS with noise

Scratch scratch.net at gmail.com
Thu Dec 29 07:55:50 PST 2016

Thanks, Trevor, I'm very glad to meet you. Kinda your fan )
Right now I'm looking at TLS and Wireguard specs and your suggestion
is what I think is the minimal required useful packet structure. Maybe
it's worth playing with frame type (handshake/data, etc), dynamic
frame size\etc, but it's not critical. Right now I want a plug-n-play
replacement for TLS in Golang and already working on a proof of
concept. I've already done some speed tests with tcp/udp/utp with and
without TLS/Noise and TCP+Noise is my choice so far. Let's see what
we'll come to.

Thanks for your support,

2016-12-29 20:37 GMT+05:00 Trevor Perrin <trevp at trevp.net>:
> On Wed, Dec 28, 2016 at 11:08 PM, Scratch <scratch.net at gmail.com> wrote:
>> I'm looking into implementing a secure transport layer for communication
>> between micro services. I don't want TLS because I don't need x.509 and all
>> that stuff. I know that there's a proposal for TLS 1.3 to have a"keys only"
>> mode, but it's still not accepted and i'm not sure it will get into
>> standard. Keys are perfectly enough for me. But I also don't want to invent
>> a bicycle here and use as much already invented things as possible.
> The spec mentions a "length field" and a "type field" which you could
> use for some minimal framing.  Basically, before each handshake
> message, you could include:
>  - 1-byte type (zero by default)
>  - 2-byte length
> The type byte can be changed for new versions of your protocol, or if
> your handshake has alternative messages (like Noise Pipes).
> After the handshake, you no longer need the type byte, so you can just
> include the 2-byte length before each transport message.
> You can make different decisions if your application has a different
> approach to framing.  For example, WhatsApp embeds Noise fields within
> XML, but it's not publicly documented.  WireGuard is adding extra
> padding for alignment reasons.
> You'll also need to make choices about handshake pattern, and crypto functions.
> Definitely feel free to discuss these on list, it's been awhile since
> we worked through a new application of Noise. It's always useful to
> get another perspective, see what the confusing points are, etc..
> Trevor

More information about the Noise mailing list