Compression support- zstd, &c

Compression support- zstd, &c

[rektide]

Greetings. Compression would be a great feature for WireGuard & it's roadmap. Perhaps the latest high compression & high throughput, very tuneable Zstd from Cyan4793? I think it'd make a fine complement to the other very nice modern technologies WireGuard has adopted.
http://facebook.github.io/zstd/

IPSec has a decent if not very modern history of compression with deflate, lzs, and lzjh support via IP Compression packets. That shows that there's some precedent for this feature. More recently OpenVPN has added LZ4 support.

Regards. Looking forward to this projects great future,
-rektide

Re: Compression support- zstd, &c

[Jason A. Donenfeld]

Hi Rektide,

On Fri, Dec 30, 2016 at 7:09 AM, rektide <rektide@voodoowarez.com> wrote:
> Greetings. Compression would be a great feature for WireGuard & it's road=
map. Perhaps the latest high compression & high throughput, very tuneable Z=
std from Cyan4793? I think it'd make a fine complement to the other very ni=
ce modern technologies WireGuard has adopted.
> http://facebook.github.io/zstd/
>
> IPSec has a decent if not very modern history of compression with deflate=
, lzs, and lzjh support via IP Compression packets. That shows that there's=
 some precedent for this feature. More recently OpenVPN has added LZ4 suppo=
rt.
>
> I want to throw on a feature request- compression. It'd be great to get f=
ree compression across the tunnel. OpenVPN recently added LZ4 compression. =
I personally would love to see Zstd supported. Seeing compression added to =
your roadmap would be immensely satisfying for me,
> I'd point to the author of both LZ4 and Zstd- Cyan4973-'s post introducin=
g Zstd for more info the tradeoffs between these and others (Snappy, lzo, &=
c), which boil down to CPU usage and compression ratio,
> http://fastcompression.blogspot.com/2015/01/zstd-stronger-compression-alg=
orithm.html

That's an interesting idea. The first concern that immediately comes
to mind is data leakage and CRIME-like compression attacks. We'd have
to tread very carefully in order to do this right. Is there a
particular implementation strategy for this you have in mind?
Historically adding compression to crypto protocols has been quite
risky.

> This would make a huge difference for me while I am tethered to cellular.

Do you have any metrics on what kind of difference? I've never tried
out the effects of compression on cellular links. Is it immediately
noticeable in some obvious way?

Jason

Re: Compression support- zstd, &c

[Jehan Tremback]

What is the advantage of doing this in Wireguard as opposed to doing it
as a separate project?

-- 
  Jehan Tremback
  jehan@altheamesh.com

On Fri, Dec 30, 2016, at 06:34 PM, Jason A. Donenfeld wrote:
> Hi Rektide,
> 
> On Fri, Dec 30, 2016 at 7:09 AM, rektide <rektide@voodoowarez.com> wrote:
> > Greetings. Compression would be a great feature for WireGuard & it's roadmap. Perhaps the latest high compression & high throughput, very tuneable Zstd from Cyan4793? I think it'd make a fine complement to the other very nice modern technologies WireGuard has adopted.
> > http://facebook.github.io/zstd/
> >
> > IPSec has a decent if not very modern history of compression with deflate, lzs, and lzjh support via IP Compression packets. That shows that there's some precedent for this feature. More recently OpenVPN has added LZ4 support.
> >
> > I want to throw on a feature request- compression. It'd be great to get free compression across the tunnel. OpenVPN recently added LZ4 compression. I personally would love to see Zstd supported. Seeing compression added to your roadmap would be immensely satisfying for me,
> > I'd point to the author of both LZ4 and Zstd- Cyan4973-'s post introducing Zstd for more info the tradeoffs between these and others (Snappy, lzo, &c), which boil down to CPU usage and compression ratio,
> > http://fastcompression.blogspot.com/2015/01/zstd-stronger-compression-algorithm.html
> 
> That's an interesting idea. The first concern that immediately comes
> to mind is data leakage and CRIME-like compression attacks. We'd have
> to tread very carefully in order to do this right. Is there a
> particular implementation strategy for this you have in mind?
> Historically adding compression to crypto protocols has been quite
> risky.
> 
> > This would make a huge difference for me while I am tethered to cellular.
> 
> Do you have any metrics on what kind of difference? I've never tried
> out the effects of compression on cellular links. Is it immediately
> noticeable in some obvious way?
> 
> Jason
> _______________________________________________
> WireGuard mailing list
> WireGuard@lists.zx2c4.com
> https://lists.zx2c4.com/mailman/listinfo/wireguard

Re: Compression support- zstd, &c

[Daniel Kahn Gillmor]

[-- Attachment #1: Type: text/plain, Size: 837 bytes --]

On Fri 2016-12-30 21:34:56 -0500, Jason A. Donenfeld wrote:
> That's an interesting idea. The first concern that immediately comes
> to mind is data leakage and CRIME-like compression attacks. We'd have
> to tread very carefully in order to do this right. Is there a
> particular implementation strategy for this you have in mind?
> Historically adding compression to crypto protocols has been quite
> risky.

This is my concern as well.  We've only recently managed to get
compression ripped out of TLS, and i'd really like to avoid it finding
its way back into other network security protocols.  The right place to
do compression is at the application layer, where it's at least possible
to distinguish between attacker-supplied traffic and user-sensitive
secrets.

Please do *not* add compressoin into wireguard itself!

       --dkg

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]