search

angt / glorytun

Multipath UDP tunnel
BSD 2-Clause "Simplified" License
683 stars 105 forks source link

Disable encryption #25

Closed lars18th closed 6 years ago

lars18th commented 6 years ago

Hi,

Why this request #14 is discarded?

In several scenarios the use of encryption limits the performance. So, have the option for disable it has sense.

Is there any possibility to consider implementing this option?

angt commented 6 years ago

Hi @lars18th, @jedisct1 works very hard to make libsodium as fast as possible. Can you post the output of the command glorytun bench and your arch ? Thanks

lars18th commented 6 years ago

Hi @angt ,

Thank you for your response!

First of all: I like to use Glorytun over "own tunnels". So, over these tunnels I don't need encryption at all. I know that "libsodium" is very fast. However, this library doesn't support a simple XOR chiper. I really need the best performance. And for this reason I ask to include it in Glorytun (for both versions, MUD and plain TCP).

I feel, you only need to do simple changes. In the Glorytun standard version (aka TCP), all the encryption work is done in functions gt_encrypt()and gt_decrypt(). If you consider a third state for chacha context, then you can do a simple XOR of the buffer with the key. And for the Glorytun-MUD version, you can consider to do similar in the MUD project (see https://github.com/angt/mud/issues/4).

I hope you consider this "simple" enhancement. Regards.

angt commented 6 years ago

Hi, why do you need glorytun with your other tunnels ? As sodium is really fast, maybe you should disable encryption on your other tunnels ?

lars18th commented 6 years ago

Hi @angt ,

Thank you for your answer!

Hi, why do you need glorytun with your other tunnels ? As sodium is really fast, maybe you should disable encryption on your other tunnels ?

Because the encryption goes best in the lower layer. Then, the traffic is externaly just only one stream. And when the Glorytun runs over the tunnel, plus other traffic, no one can intercept or show on it. Futhermore, these tunnels have hardware acceleration and integrity checking, plus timestamps.

So, from my point of view, having the option for running without encryption is a very useful functionality.

I hope you like to consider it. Regards.

angt commented 6 years ago

Hi, still not convinced :) We also have hardware accelerated encryption (aesni, pclmul, ...), authentication (integrity), timestamp checking, perfect forward secrecy (1h by default) and other stuff. Also, on my laptop I can encrypt at 16Gbps, fast enough :)

lars18th commented 6 years ago

Also, on my laptop I can encrypt at 16Gbps, fast enough :)

Yes on your highend laptop... Consider this scenerio:

In this case, the encryption in the Glorytun layer is useless and it limits the bandwith.

Why not leave the user to decide wich level of privacy s/he needs to use?

izomiac commented 6 years ago

Hello, I thought I'd chime in on this with my usage case. I tunnel all my traffic through wireguard to an external VPN service. I also am deploying this to a router, which is rather limited in resources. There are two ways to combine this with glorytun:

The first solution is going to take a performance hit from encrypting everything twice on embedded hardware. That's a steep cost for zero benefit. The second solution decrypts all traffic at the VPS which I control, but do not have physical access to. If the VPS is compromised (e.g. by someone infiltrating the host, which does happen on occasion) then all traffic is subject to being intercepted. Plus there's an unnecessary decryption/reencryption that's likely to cause a performance hit on the el cheapo VPS I use. (Using a dedicated VPN service plus a cheap VPS for other tasks is cheaper per Mbs than running a higher performance VPS in my experience.)

angt commented 6 years ago

Hi all, I'm closing this as i can't help. Mixing VPN is a bad idea so if you're looking for a multipath VPN with "zero-down" failover, just use glorytun (or mlvpn). Regards.