Development discussion of WireGuard
 help / color / mirror / Atom feed
From: Jehan Tremback <jehan@altheamesh.com>
To: wireguard@lists.zx2c4.com
Subject: Re: Compression support- zstd, &c
Date: Sat, 31 Dec 2016 15:40:02 -0800	[thread overview]
Message-ID: <1483227602.2820173.833990769.0EDBBF7D@webmail.messagingengine.com> (raw)
In-Reply-To: <CAHmME9ps=8bc74tnmKMnitH_wRBLXoioQc+XC_qvqk8Pv6WgBA@mail.gmail.com>

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

  reply	other threads:[~2016-12-31 23:31 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-12-30  6:09 rektide
2016-12-31  2:34 ` Jason A. Donenfeld
2016-12-31 23:40   ` Jehan Tremback [this message]
2017-01-03  9:11   ` Daniel Kahn Gillmor

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1483227602.2820173.833990769.0EDBBF7D@webmail.messagingengine.com \
    --to=jehan@altheamesh.com \
    --cc=wireguard@lists.zx2c4.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).