[noise] NoiseSocket revision 1

Alexey Ermishkin scratch.net at gmail.com
Wed Aug 2 23:30:57 PDT 2017

I talked to guys who use TLS at >10gbps speeds and would like to reduce the amount of memcpy calls per packet which is why they want ~2mb packets. 

So maybe for ones who know what they are doing this may be an option.

-----Original Message-----
From: Trevor Perrin [mailto:trevp at trevp.net] 
Sent: Thursday, August 3, 2017 5:10 AM
To: Alexey Ermishkin <scratch.net at gmail.com>
Cc: noise <noise at moderncrypto.org>
Subject: Re: [noise] NoiseSocket revision 1

On Wed, Aug 2, 2017 at 7:38 PM, Alexey Ermishkin <scratch.net at gmail.com> wrote:
> Couple of thoughts after DEF CON and publishing an article in Russian on habr.ru:
> 1) Those who understand what this is are very excited and welcomed 
> Noise very warm


> 2) People want IoT and, surprisingly, JS demos. IoT is on us, JS.....
> 3) I had one question regarding increasing maximum transport packet size to megabytes instead of 64k.  For datacenter/highload guys. Interesting!

The main reason for limiting packet size is that recipients might have limited buffers, so with huge AEAD packets these recipients would be tempted to decrypt and stream the plaintext before authenticating it (i.e. do AES separately from GCM), which would be a security problem.

The overhead is 0.03% (20 bytes / 65535), so this shouldn't affect performance much.

On the other hand, I was just talking with someone who might have an unusual use case for larger packets.

We could consider making this a recommendation instead of a hard limit.  But I'd like to hear more reasons why people want larger packets.  If we could convince people to stick with 64K that's simpler, and easier for small-buffer implementations.

> 4) We know guys who are going to implement all needed Noise primitives 
> (25519, chacha, blake) in SILICON. Which is a huge step towards making 
> NoiseSocket a standard IoT protocol
> 5) NGINX module running NoiseSocket is also a huge win. It's just a 
> PoC for now, but we see a big future for him. Also was a huge pain in 
> the ass to implement

Yeah that looks cool, good to see Noise-C in use.  It would also be interesting to see if the Rust library could be used here.



More information about the Noise mailing list