Some tests performed on throughput and overhead gave the below results:
AES-256-GCM:
Overhead: 10 - 12% (relative to the total traffic on eth0)
Iperf within tunnel: 265 Mbps
AES-128-GCM:
Overhead: 7 - 8 %
Iperf: 283 Mbps
AES-128-CBC:
Overhead: 10 - 13 %
Iperf: 281 Mbps
The VPN tunnel used is a UDP tunnel with fragment 1360, tun-mtu 1500. The
ethernet network used was 100Mbps.
For the bandwidth tests the average result from the below was used:
server: iperf -s
client: for i in {1..4};do iperf -c 169.251.0.1 -t 30;sleep 60;done
For the overhead measurement the below payload was used:
dd if=/dev/urandom of=/tmp/urandom.dat bs=10K count=1000
iperf -c iperf-server -F /tmp/urandom.dat
Seems that I can use AES-256-GCM since it gives same encapsulation overhead
with slight decease of bandwidth compared to AES-128-CBC I was using and
it will provide some extra security to avoid any surprises from the quantum
computers :)
Thanx,
Alex
On Sun, Jun 17, 2018 at 8:23 AM, Alex K <rightkickt...@gmail.com> wrote:
> Thank you David for the thorough answer. I will try and perform some
> tests and will post results here when done.
>
> Thanx,
> Alex
>
> On Sun, Jun 17, 2018, 02:18 David Sommerseth <openvpn@sf.lists.
> topphemmelig.net> wrote:
>
>> On 17/06/18 00:07, Alex K wrote:
>> >
>> >
>> > On Sat, Jun 16, 2018 at 12:58 PM, Gert Doering <g...@greenie.muc.de
>> > <mailto:g...@greenie.muc.de>> wrote:
>> >
>> > Hi,
>> >
>> > On Sat, Jun 16, 2018 at 12:29:27AM +0300, Alex K wrote:
>> > > Hi all,
>> > >
>> > > I have a server/client setup where I have set the following
>> directive at
>> > > server and client:
>> > >
>> > > cipher AES-128-CBC
>> > >
>> > > When establishing VPN at client logs I see:
>> > >
>> > > Fri Jun 15 17:25:22 2018 Data Channel Encrypt: *Cipher
>> 'AES-256-GCM'
>> > > *initialized
>> > > with 256 bit key
>> > [..]
>> > > The log indicates that Cipher AES-256-GCM is used. Am i missing
>> sth? Is
>> > > this expected?
>> >
>> > cipher-negotiation decided that something "better" is available :-)
>> >
>> >
>> > Is it AES-128-CBC insecure? I was thinking to use it to reduce the
>> > encapsulation overhead and perhaps the CPU utilization that AES-256-GCM
>> might
>> > incur.
>> > I am running VPN clients on small devices.
>>
>> No, AES-128-CBC is still reasonable. AES-256 is a bit better if
>> considering a
>> post-quantum scenario (the crypto geeks can provide better details here).
>>
>> The advantage GCM has over CBC is that authentication happens in the same
>> crypto operation as the decryption. While CBC needs to have decryption
>> and
>> authentication as two separate steps, which is more costly CPU wise. The
>> network packet payload is also a bit smaller per packet with GCM.
>> Compared to
>> --auth SHA1, I believe the packet size is 8 bytes smaller, and even more
>> if
>> using --auth SHA256.
>>
>> Small devices might not be too bad at AES-GCM ciphers as it used to be
>> though;
>> it depends on what kind hardware generation it is and if the SSL library
>> can
>> utilize the hardware acceleration. I've heard that more and more mobile
>> phones these days do have AES hardware support (often as an additional
>> "support CPU"), but even some ARM Cortex (ARMv8) has the possibility for
>> AES
>> built into the CPU as well.
>>
>> But generally, I would advice you to run some thorough performance tests
>> before deciding if CBC or GCM is better for you.
>>
>>
>> --
>> kind regards,
>>
>> David Sommerseth
>> OpenVPN Inc
>>
>>
>>
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users
