IPSec performance @ x86

newer
Cisco: OSPF default-information...

older
Использование BNG (CISCO) и выдача...

Volodymyr Litovka

30 Jan 2017 30 Jan '17

11:14 p.m.

Привет, есть задача - запустить сеть с шифрованием трафика на основе механизма GRE over IPSec/IKEv2 (GRE нужен для dynamic routing, IPSec - для совместимости с решениями других производителей - таковы требования).Если у кого есть опыт использования open source / x86 для подобных задач, поделитесь им, пожалуйста: * на каких программно-аппаратных конфигурациях какую предельную производительность удалось получить (до начала потерь пакетов)? o CPU/MB/RAM (тип, частота) o NIC (производитель, модель) o операционная система o софт / библиотеки o алгоритм и длина ключа для симметричного шифрования (в реальности - интересует, конечно же, AES-256) Спасибо! -- Volodymyr Litovka "Vision without Execution is Hallucination." -- Thomas Edison

Attachments:

attachment.html (text/html — 1.8 KB)

Show replies by date

Andriy Berestovskyy

31 Jan 31 Jan

8:24 a.m.

Привет! По цифрам для x86 у меня ничего нет, но мы недавно написали Crypto PMD для Кавиума и на примере ipsec получили до 1 MPPS/ядро в AES-128 + SHA-1, без акселераторов, просто на SIMD инструкциях ARMv8: http://dpdk.org/ml/archives/dev/2016-December/051315.html Пример IPSec - это принять пакет, приготовить, зашифровать/подписать и выслать. Т.е. цифры не сферические в вакууме, а более-менее реальные. Если нужна производительность, можно посмотреть в сторону Intel QAT или продуктов Cavium с блоком CPT, типа Nitrox. Цифр под рукой нет, но могу поспрашивать ребят из Интела/Кавиума. Андрей

...

On 31 Jan 2017, at 00:14, Volodymyr Litovka wrote:

Привет,

есть задача - запустить сеть с шифрованием трафика на основе механизма GRE over IPSec/IKEv2 (GRE нужен для dynamic routing, IPSec - для совместимости с решениями других производителей - таковы требования). Если у кого есть опыт использования open source / x86 для подобных задач, поделитесь им, пожалуйста: на каких программно-аппаратных конфигурациях какую предельную производительность удалось получить (до начала потерь пакетов)? CPU/MB/RAM (тип, частота) NIC (производитель, модель) операционная система софт / библиотеки алгоритм и длина ключа для симметричного шифрования (в реальности - интересует, конечно же, AES-256) Спасибо!

-- Volodymyr Litovka "Vision without Execution is Hallucination." -- Thomas Edison _______________________________________________ uanog mailing list uanog@uanog.kiev.ua http://mailman.uanog.kiev.ua/mailman/listinfo/uanog

Max Tulyev

12:07 p.m.

Добрый день! Пользуясь случаем, спрошу ;) В Intel NIC гигабитках и старше есть аппаратная поддержка IPSec/AES, которая типа дает wire speed шифрование. Но вот беда: под Linux/BSD на момент когда я последний раз это смотрел - не написали драйвера под это дело. Может, ситуация уже поменялась в лучшую сторону? On 31.01.17 01:14, Volodymyr Litovka wrote:

...

Привет,

есть задача - запустить сеть с шифрованием трафика на основе механизма GRE over IPSec/IKEv2 (GRE нужен для dynamic routing, IPSec - для совместимости с решениями других производителей - таковы требования).Если у кого есть опыт использования open source / x86 для подобных задач, поделитесь им, пожалуйста:

* на каких программно-аппаратных конфигурациях какую предельную производительность удалось получить (до начала потерь пакетов)? o CPU/MB/RAM (тип, частота) o NIC (производитель, модель) o операционная система o софт / библиотеки o алгоритм и длина ключа для симметричного шифрования (в реальности - интересует, конечно же, AES-256)

Спасибо!

-- Volodymyr Litovka "Vision without Execution is Hallucination." -- Thomas Edison

_______________________________________________ uanog mailing list uanog@uanog.kiev.ua http://mailman.uanog.kiev.ua/mailman/listinfo/uanog

Volodymyr Litovka

12:10 p.m.

А про какие именно модели ты говоришь? Я не припоминаю такой функциональности в NIC. On 1/31/17 2:07 PM, Max Tulyev wrote:

...

Добрый день!

Пользуясь случаем, спрошу ;)

В Intel NIC гигабитках и старше есть аппаратная поддержка IPSec/AES, которая типа дает wire speed шифрование.

Но вот беда: под Linux/BSD на момент когда я последний раз это смотрел - не написали драйвера под это дело.

Может, ситуация уже поменялась в лучшую сторону?

On 31.01.17 01:14, Volodymyr Litovka wrote:

...
Привет,

есть задача - запустить сеть с шифрованием трафика на основе механизма GRE over IPSec/IKEv2 (GRE нужен для dynamic routing, IPSec - для совместимости с решениями других производителей - таковы требования).Если у кого есть опыт использования open source / x86 для подобных задач, поделитесь им, пожалуйста:

* на каких программно-аппаратных конфигурациях какую предельную производительность удалось получить (до начала потерь пакетов)? o CPU/MB/RAM (тип, частота) o NIC (производитель, модель) o операционная система o софт / библиотеки o алгоритм и длина ключа для симметричного шифрования (в реальности - интересует, конечно же, AES-256)

Спасибо!

-- Volodymyr Litovka "Vision without Execution is Hallucination." -- Thomas Edison

_______________________________________________ uanog mailing list uanog@uanog.kiev.ua http://mailman.uanog.kiev.ua/mailman/listinfo/uanog

_______________________________________________ uanog mailing list uanog@uanog.kiev.ua http://mailman.uanog.kiev.ua/mailman/listinfo/uanog

-- Volodymyr Litovka "Vision without Execution is Hallucination." -- Thomas Edison

Max Tulyev

1:24 p.m.

Ну вот что под рукой, например: http://www.intel.ru/content/www/ru/ru/embedded/products/networking/82599-10-... Страница 476 и дальше. On 31.01.17 14:10, Volodymyr Litovka wrote:

...

А про какие именно модели ты говоришь? Я не припоминаю такой функциональности в NIC.

On 1/31/17 2:07 PM, Max Tulyev wrote:

...
Добрый день!

Пользуясь случаем, спрошу ;)

В Intel NIC гигабитках и старше есть аппаратная поддержка IPSec/AES, которая типа дает wire speed шифрование.

Но вот беда: под Linux/BSD на момент когда я последний раз это смотрел - не написали драйвера под это дело.

Может, ситуация уже поменялась в лучшую сторону?

On 31.01.17 01:14, Volodymyr Litovka wrote:

...
Привет,

есть задача - запустить сеть с шифрованием трафика на основе механизма GRE over IPSec/IKEv2 (GRE нужен для dynamic routing, IPSec - для совместимости с решениями других производителей - таковы требования).Если у кого есть опыт использования open source / x86 для подобных задач, поделитесь им, пожалуйста:

* на каких программно-аппаратных конфигурациях какую предельную производительность удалось получить (до начала потерь пакетов)? o CPU/MB/RAM (тип, частота) o NIC (производитель, модель) o операционная система o софт / библиотеки o алгоритм и длина ключа для симметричного шифрования (в реальности - интересует, конечно же, AES-256)

Спасибо!

-- Volodymyr Litovka "Vision without Execution is Hallucination." -- Thomas Edison

_______________________________________________ uanog mailing list uanog@uanog.kiev.ua http://mailman.uanog.kiev.ua/mailman/listinfo/uanog

_______________________________________________ uanog mailing list uanog@uanog.kiev.ua http://mailman.uanog.kiev.ua/mailman/listinfo/uanog

-- Volodymyr Litovka "Vision without Execution is Hallucination." -- Thomas Edison

Volodymyr Litovka

1:49 p.m.

Ну как-то многовато ограничений в 7.12.3, например The followings items are not supported by hardware: * Both AH and ESP protocols on the same SA or packet * AES-256 * Tx IPsec packets encapsulated in tunnel mode * IPv4 packets that include IP option * IPv6 packets that include extension headers other than the AH/ESP extension headers * Anti-replay check and discard of incoming replayed packets * Discard of incoming dummy ESP packets (packets with protocol value 59) * IPsec packets that are IP fragments то есть вроде как и поддерживается IPSec, но использовать можно только в каких-то лабораторных целях :) Гораздо интереснее использовать AES NI - аппаратное шифрование с control plane в приложении. On 1/31/17 3:24 PM, Max Tulyev wrote:

...

Ну вот что под рукой, например: http://www.intel.ru/content/www/ru/ru/embedded/products/networking/82599-10-...

Страница 476 и дальше.

On 31.01.17 14:10, Volodymyr Litovka wrote:

...
А про какие именно модели ты говоришь? Я не припоминаю такой функциональности в NIC.

On 1/31/17 2:07 PM, Max Tulyev wrote:

...
Добрый день!

Пользуясь случаем, спрошу ;)

В Intel NIC гигабитках и старше есть аппаратная поддержка IPSec/AES, которая типа дает wire speed шифрование.

Но вот беда: под Linux/BSD на момент когда я последний раз это смотрел - не написали драйвера под это дело.

Может, ситуация уже поменялась в лучшую сторону?

On 31.01.17 01:14, Volodymyr Litovka wrote:

...
Привет,

есть задача - запустить сеть с шифрованием трафика на основе механизма GRE over IPSec/IKEv2 (GRE нужен для dynamic routing, IPSec - для совместимости с решениями других производителей - таковы требования).Если у кого есть опыт использования open source / x86 для подобных задач, поделитесь им, пожалуйста:

* на каких программно-аппаратных конфигурациях какую предельную производительность удалось получить (до начала потерь пакетов)? o CPU/MB/RAM (тип, частота) o NIC (производитель, модель) o операционная система o софт / библиотеки o алгоритм и длина ключа для симметричного шифрования (в реальности - интересует, конечно же, AES-256)

Спасибо!

-- Volodymyr Litovka "Vision without Execution is Hallucination." -- Thomas Edison

-- Volodymyr Litovka "Vision without Execution is Hallucination." -- Thomas Edison

Sergey Smitienko

14 Feb 14 Feb

1:37 p.m.

Была возможность - сделал тест. 3.16.0-4-amd64 #1 SMP Debian Intel(R) Xeon(R) CPU E3-1225 v5 @ 3.30GHz Ethernet controller: Intel Corporation 82599ES 10-Gigabit SFI/SFP+ Network Connection (rev 01) add x y esp 12044 -m tunnel -E aes-cbc "0123456789abcdef01234567" -A hmac-sha256 "0123456789abcdef0123456789abcdef"; add y x esp 12045 -m tunnel -E aes-cbc "0123456789abcdef01234567" -A hmac-sha256 "0123456789abcdef0123456789abcdef"; spdadd x y any -P in ipsec esp/tunnel/x-y/require; spdadd y x any -P out ipsec esp/tunnel/y-x/require; Машины включены в один ethernet без ipsec качают 10G (iperf3). aes128-md5 - cpu load около 20%. aes128-sha256 - cpu load около 20%. aes256-sha256 - cpu load около 20% Во всех случаях iperf3 разгонялся до примерно 1 - 1.2 гигабита в секунду и больше скорость не росла. Запускал и в один и в несколько потоков. Судя по [49374.856185] sha256_ssse3: Using AVX2 optimized SHA-256 implementation [49374.900019] sha512_ssse3: Using AVX2 optimized SHA-512 implementation [49375.146132] alg: No test for authenc(hmac(md5),cbc(aes)) (authenc(hmac(md5-generic),cbc-aes-aesni)), ядро выбрало aes-ni драйвер шифрования для md5 и aes-ni/avx2 для sha256. Выводы - где-то в ядре Linux есть блокировки и проблемы с оптимизацией, которые не позволяют качать быстрее, чем гигабит в секунду и загрузить cpu на максимум. Для сравнения, http://www.6wind.com/products/6windgate/ пишут про 12.5 Gbps per core на x86, но у них свой userspace IP стек. -- Sergey

Volodymyr Litovka

3:28 p.m.

On 2/14/17 3:37 PM, Sergey Smitienko wrote:

...

Для сравнения, http://www.6wind.com/products/6windgate/ пишут про 12.5 Gbps per core на x86, но у них свой userspace IP стек. Я думаю, что как минимум они используют DPDK. Ну и да, не исключены другие оптимизации.

-- Volodymyr Litovka "Vision without Execution is Hallucination." -- Thomas Edison

Andriy Berestovskyy

4:38 p.m.

Привет!

...

On 14 Feb 2017, at 16:28, Volodymyr Litovka wrote:

On 2/14/17 3:37 PM, Sergey Smitienko wrote:

...
Для сравнения, http://www.6wind.com/products/6windgate/ пишут про 12.5 Gbps per core на x86, но у них свой userspace IP стек. Я думаю, что как минимум они используют DPDK. Ну и да, не исключены другие оптимизации.

В DPDK есть пример шлюза IPSec: http://dpdk.org/doc/guides/sample_app_ug/ipsec_secgw.html Вполне рабочий, мы пользуемся для тестов, но без IKE. Если нужна производительность - можно начать с этого и допиливать. Генератор тоже может быть узким местом. Из open source и бесплатных рекомендую посмотреть TRex от Cisco. Мы им тестировали дешифрование: генерировали лайнрейт (на 82599 это ок. 9 MPPS) пакетами ESP минимальной длины (106 байт для AES128 + SHA256). Андрей

Victor Cheburkin

4:41 p.m.

Hi!

...

14 февр. 2017 г., в 15:37, Sergey Smitienko написал(а):

Была возможность - сделал тест.

3.16.0-4-amd64 #1 SMP Debian

Intel(R) Xeon(R) CPU E3-1225 v5 @ 3.30GHz

Ethernet controller: Intel Corporation 82599ES 10-Gigabit SFI/SFP+ Network Connection (rev 01)

add x y esp 12044 -m tunnel -E aes-cbc "0123456789abcdef01234567" -A hmac-sha256 "0123456789abcdef0123456789abcdef"; add y x esp 12045 -m tunnel -E aes-cbc "0123456789abcdef01234567" -A hmac-sha256 "0123456789abcdef0123456789abcdef"; spdadd x y any -P in ipsec esp/tunnel/x-y/require; spdadd y x any -P out ipsec esp/tunnel/y-x/require;

Машины включены в один ethernet без ipsec качают 10G (iperf3).

aes128-md5 - cpu load около 20%. aes128-sha256 - cpu load около 20%. aes256-sha256 - cpu load около 20%

Во всех случаях iperf3 разгонялся до примерно 1 - 1.2 гигабита в секунду и больше скорость не росла. Запускал и в один и в несколько потоков.

Судя по [49374.856185] sha256_ssse3: Using AVX2 optimized SHA-256 implementation [49374.900019] sha512_ssse3: Using AVX2 optimized SHA-512 implementation [49375.146132] alg: No test for authenc(hmac(md5),cbc(aes)) (authenc(hmac(md5-generic),cbc-aes-aesni)), ядро выбрало aes-ni драйвер шифрования для md5 и aes-ni/avx2 для sha256.

Выводы - где-то в ядре Linux есть блокировки и проблемы с оптимизацией, которые не позволяют качать быстрее, чем гигабит в секунду и загрузить cpu на максимум.

Такое впечатление, что работало в один поток. Загруска cpu -- это 20% от всего, или 20% одного ядра? Впрочем тут еще зависит от того как (чем) смотреть загрузку... -- Victor Cheburkin VC319-RIPE, VC1-UANIC

Paul Arakelyan

15 Feb 15 Feb

10:46 a.m.

On Tue, Feb 14, 2017 at 03:37:57PM +0200, Sergey Smitienko wrote:

...

Была возможность - сделал тест.

Выводы - где-то в ядре Linux есть блокировки и проблемы с оптимизацией, которые не позволяют качать быстрее, чем гигабит в секунду и загрузить cpu на максимум.

Может ограничения hardware AES в проце? -- Best regards, Paul Arakelyan.

Andriy Berestovskyy

16 Feb 16 Feb

10:02 a.m.

Привет!

...

On 15 Feb 2017, at 11:46, Paul Arakelyan wrote: Может ограничения hardware AES в проце?

В среднестатистическом Xeon времён Sandy Bridge у каждого ядра есть AES порт, который на некоторых алгоритмах мелит одновременно до восьми 16-байтных блоков/8 циклов. В худшем случае он мелит один блок/8 циклов. Другими словами, вряд ли проц будет узким местом. Андрей

Sergey Smitienko

1 Feb 1 Feb

1:42 p.m.

IPSec offload есть в Intel ethernet 82576EB. Но что-то я не могу найти детального описания. Но думаю будет медленнее, чем в aes-ni на хорошем cpu.

...

А про какие именно модели ты говоришь? Я не припоминаю такой функциональности в NIC.

On 1/31/17 2:07 PM, Max Tulyev wrote:

...
Добрый день!

Пользуясь случаем, спрошу ;)

В Intel NIC гигабитках и старше есть аппаратная поддержка IPSec/AES, которая типа дает wire speed шифрование.

Но вот беда: под Linux/BSD на момент когда я последний раз это смотрел - не написали драйвера под это дело.

Может, ситуация уже поменялась в лучшую сторону?

On 31.01.17 01:14, Volodymyr Litovka wrote:

...
Привет,

есть задача - запустить сеть с шифрованием трафика на основе механизма GRE over IPSec/IKEv2 (GRE нужен для dynamic routing, IPSec - для совместимости с решениями других производителей - таковы требования).Если у кого есть опыт использования open source / x86 для подобных задач, поделитесь им, пожалуйста:

* на каких программно-аппаратных конфигурациях какую предельную производительность удалось получить (до начала потерь пакетов)? o CPU/MB/RAM (тип, частота) o NIC (производитель, модель) o операционная система o софт / библиотеки o алгоритм и длина ключа для симметричного шифрования (в реальности - интересует, конечно же, AES-256)

Спасибо!

Andriy Berestovskyy

9:39 p.m.

Согласен, и даже больше. Мне кажется даже без инструкций AES процессор будет быстрее, чем оффлоад для небольших пакетов. время передачи даных через PCIe и обратно несоизмеримо с какими-то перестановками байтиков в 16-байтном блоке... Вопрос в том, есть ли у процессора время ещё и на IPSec. Андрей

...

On 1 Feb 2017, at 14:42, Sergey Smitienko wrote:

IPSec offload есть в Intel ethernet 82576EB. Но что-то я не могу найти детального описания. Но думаю будет медленнее, чем в aes-ni на хорошем cpu.

...
А про какие именно модели ты говоришь? Я не припоминаю такой функциональности в NIC.

...
On 1/31/17 2:07 PM, Max Tulyev wrote: Добрый день!

Пользуясь случаем, спрошу ;)

В Intel NIC гигабитках и старше есть аппаратная поддержка IPSec/AES, которая типа дает wire speed шифрование.

Но вот беда: под Linux/BSD на момент когда я последний раз это смотрел - не написали драйвера под это дело.

Может, ситуация уже поменялась в лучшую сторону?

On 31.01.17 01:14, Volodymyr Litovka wrote:

...
Привет,

есть задача - запустить сеть с шифрованием трафика на основе механизма GRE over IPSec/IKEv2 (GRE нужен для dynamic routing, IPSec - для совместимости с решениями других производителей - таковы требования).Если у кого есть опыт использования open source / x86 для подобных задач, поделитесь им, пожалуйста:

* на каких программно-аппаратных конфигурациях какую предельную производительность удалось получить (до начала потерь пакетов)? o CPU/MB/RAM (тип, частота) o NIC (производитель, модель) o операционная система o софт / библиотеки o алгоритм и длина ключа для симметричного шифрования (в реальности - интересует, конечно же, AES-256)

Спасибо!

uanog mailing list uanog@uanog.kiev.ua http://mailman.uanog.kiev.ua/mailman/listinfo/uanog

Sergey Smitienko

10:41 a.m.

Привет. core.i7.6700k#openssl speed -evp aes-128-cbc Doing aes-128-cbc for 3s on 16 size blocks: 227357080 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 64 size blocks: 64897721 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 256 size blocks: 16590421 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 1024 size blocks: 4189099 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 8192 size blocks: 524904 aes-128-cbc's in 3.00s OpenSSL 1.0.2g 1 Mar 2016 built on: reproducible build, date unspecified options:bn(64,64) rc4(16x,int) des(idx,cisc,16,int) aes(partial) blowfish(idx) compiler: cc -I. -I.. -I../include -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -m64 -DL_ENDIAN -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -Wl,-Bsymbolic-functions -Wl,-z,relro -Wa,--noexecstack -Wall -DMD32_REG_T=int -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM -DECP_NISTZ256_ASM The 'numbers' are in 1000s of bytes per second processed. type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes aes-128-cbc 1212571.09k 1384484.71k 1415715.93k 1429879.13k 1433337.86k В блоках по 64 байта (самый плохой случай - voip) дает 1.3 гигабайта в секунду при полной загрузки одного ядра. Без AES-NI The 'numbers' are in 1000s of bytes per second processed. type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes aes-128 cbc 167418.06k 182451.93k 188739.07k 187727.19k 194005.67k - 182 мегабайта в секунду. В обоих случаях это больше, чем нужно, для загрузки гигабитного канала. Скорости работы AES в openssl и в linux kernel практически можно считать одинаковыми. А AES-256 не нужен. AES-256 на самом деле слабее, чем AES-128. "Assuming you're talking about AES 128 versus AES 256, there is a known weakness in the key expansion function that affects AES256. Fundamentally, the weakness reduces the complexity of AES256 to that lower than AES128." http://eprint.iacr.org/2009/374

...

В Intel NIC гигабитках и старше есть аппаратная поддержка IPSec/AES, которая типа дает wire speed шифрование.

...
Привет,

есть задача - запустить сеть с шифрованием трафика на основе механизма GRE over IPSec/IKEv2 (GRE нужен для dynamic routing, IPSec - для совместимости с решениями других производителей - таковы требования).Если у кого есть опыт использования open source / x86 для подобных задач, поделитесь им, пожалуйста:

* на каких программно-аппаратных конфигурациях какую предельную производительность удалось получить (до начала потерь пакетов)? o CPU/MB/RAM (тип, частота) o NIC (производитель, модель) o операционная система o софт / библиотеки o алгоритм и длина ключа для симметричного шифрования (в реальности - интересует, конечно же, AES-256)

Спасибо!

Volodymyr Litovka

12:17 p.m.

On 2/1/17 12:41 PM, Sergey Smitienko wrote:

...

А AES-256 не нужен. AES-256 на самом деле слабее, чем AES-128. "Assuming you're talking about AES 128 versus AES 256, there is a known weakness in the key expansion function that affects AES256. Fundamentally, the weakness reduces the complexity of AES256 to that lower than AES128." http://eprint.iacr.org/2009/374 http://crypto.stackexchange.com/questions/5118/is-aes-256-weaker-than-192-an...

"Related-key attacks are not a problem when the encryption algorithm is used for encryption, because they work only when the victim uses several distinct keys, such that the differences (bitwise XOR) between the keys are known to the attacker and follow a very definite pattern. This is not the kind of thing which often occurs in protocols where AES is used; correspondingly, resistance to related-key attacks was not a design criterion for the AES competition." "No. AES-256 is not weaker than AES-128. Absolutely not. And I disagree with the the advice that you should avoid AES-256. The attack against AES-256 is a related-key attack, which is irrelevant to most real-world uses of AES-256. Related-key attacks only become relevant if you use the block cipher improperly, which is not something that you ought to be doing. [ ... ] So, basically, pay no attention to those claimed attacks on AES-256. They are a theoretical curiousity with little or no relevance to practice at the moment." " Note, that related-key scenarios are very academical. Here, cryptographers assume that an adversary can 'partially control' some relations among keys used in the computation." Как-то так. Атака возможна, если атакующий либо обладает доступом к вычислительной системе, либо "жертва" генерирует related keys по определенному алгоритму и *цепочка *некоторых из них доступна атакующей стороне. Иными словами - *это то, с чем в реальной жизни столкнуться практически невероятно*. -- Volodymyr Litovka "Vision without Execution is Hallucination." -- Thomas Edison

Sergey Smitienko

1:10 p.m.

Hi! С расшифровкой трафика, закрытого 128 bit ключем AES в реальной жизни практически не менее вероятно.

...

...
А AES-256 не нужен. AES-256 на самом деле слабее, чем AES-128. "Assuming you're talking about AES 128 versus AES 256, there is a known weakness in the key expansion function that affects AES256. Fundamentally, the weakness reduces the complexity of AES256 to that lower than AES128." http://eprint.iacr.org/2009/374 http://crypto.stackexchange.com/questions/5118/is-aes-256-weaker-than-192-an...

" Note, that related-key scenarios are very academical. Here, cryptographers assume that an adversary can 'partially control' some relations among keys used in the computation."

Как-то так. Атака возможна, если атакующий либо обладает доступом к вычислительной системе, либо "жертва" генерирует related keys по определенному алгоритму и *цепочка *некоторых из них доступна атакующей стороне. Иными словами - *это то, с чем в реальной жизни столкнуться практически невероятно*.

Volodymyr Litovka

1:15 p.m.

Ну это я к тому, что можно использовать и то, и другое без практических последствий. Выбор определяется соотношением возможностей и требований :) Но за ссылку на документ спасибо - теперь одним вопросом меньше :) осталось чуть менее миллиарда других :) On 2/1/17 3:10 PM, Sergey Smitienko wrote:

...

Hi!

С расшифровкой трафика, закрытого 128 bit ключем AES в реальной жизни практически не менее вероятно.

...
...
А AES-256 не нужен. AES-256 на самом деле слабее, чем AES-128. "Assuming you're talking about AES 128 versus AES 256, there is a known weakness in the key expansion function that affects AES256. Fundamentally, the weakness reduces the complexity of AES256 to that lower than AES128." http://eprint.iacr.org/2009/374 http://crypto.stackexchange.com/questions/5118/is-aes-256-weaker-than-192-an...

" Note, that related-key scenarios are very academical. Here, cryptographers assume that an adversary can 'partially control' some relations among keys used in the computation."

Как-то так. Атака возможна, если атакующий либо обладает доступом к вычислительной системе, либо "жертва" генерирует related keys по определенному алгоритму и *цепочка *некоторых из них доступна атакующей стороне. Иными словами - *это то, с чем в реальной жизни столкнуться практически невероятно*.

-- Volodymyr Litovka "Vision without Execution is Hallucination." -- Thomas Edison

Andriy Berestovskyy

9:21 p.m.

Ребята, Посмотрите исходники: https://github.com/openssl/openssl/blob/master/apps/speed.c openssl speed - это цикл на одних и тех же данных, т.е. ничего, кроме вычислительной мощности процессора он не показывает: данные будут в кэше L1 после первого же оборота. IPSec на шлюзе - это принять пакет, заглянуть в таблицу маршрутизации, заглянуть а SPD, заглянуть в SAD, зашифровать и выслать. Для маленьких пакетов само шифрование занимает лишь малую часть процессорного времени, необходимого на обработку каждого пакета. Андрей

...

On 1 Feb 2017, at 11:41, Sergey Smitienko wrote:

Привет.

core.i7.6700k#openssl speed -evp aes-128-cbc

Doing aes-128-cbc for 3s on 16 size blocks: 227357080 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 64 size blocks: 64897721 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 256 size blocks: 16590421 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 1024 size blocks: 4189099 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 8192 size blocks: 524904 aes-128-cbc's in 3.00s

OpenSSL 1.0.2g 1 Mar 2016 built on: reproducible build, date unspecified options:bn(64,64) rc4(16x,int) des(idx,cisc,16,int) aes(partial) blowfish(idx) compiler: cc -I. -I.. -I../include -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -m64 -DL_ENDIAN -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -Wl,-Bsymbolic-functions -Wl,-z,relro -Wa,--noexecstack -Wall -DMD32_REG_T=int -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM -DECP_NISTZ256_ASM The 'numbers' are in 1000s of bytes per second processed. type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes aes-128-cbc 1212571.09k 1384484.71k 1415715.93k 1429879.13k 1433337.86k

В блоках по 64 байта (самый плохой случай - voip) дает 1.3 гигабайта в секунду при полной загрузки одного ядра. Без AES-NI

The 'numbers' are in 1000s of bytes per second processed. type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes aes-128 cbc 167418.06k 182451.93k 188739.07k 187727.19k 194005.67k - 182 мегабайта в секунду.

В обоих случаях это больше, чем нужно, для загрузки гигабитного канала. Скорости работы AES в openssl и в linux kernel практически можно считать одинаковыми.

А AES-256 не нужен. AES-256 на самом деле слабее, чем AES-128. "Assuming you're talking about AES 128 versus AES 256, there is a known weakness in the key expansion function that affects AES256. Fundamentally, the weakness reduces the complexity of AES256 to that lower than AES128." http://eprint.iacr.org/2009/374

...
В Intel NIC гигабитках и старше есть аппаратная поддержка IPSec/AES, которая типа дает wire speed шифрование.

...
Привет,

есть задача - запустить сеть с шифрованием трафика на основе механизма GRE over IPSec/IKEv2 (GRE нужен для dynamic routing, IPSec - для совместимости с решениями других производителей - таковы требования).Если у кого есть опыт использования open source / x86 для подобных задач, поделитесь им, пожалуйста:

* на каких программно-аппаратных конфигурациях какую предельную производительность удалось получить (до начала потерь пакетов)? o CPU/MB/RAM (тип, частота) o NIC (производитель, модель) o операционная система o софт / библиотеки o алгоритм и длина ключа для симметричного шифрования (в реальности - интересует, конечно же, AES-256)

Спасибо!

_______________________________________________ uanog mailing list uanog@uanog.kiev.ua http://mailman.uanog.kiev.ua/mailman/listinfo/uanog

Sergey Smitienko

9:32 p.m.

Все в порядке. Берете linux, толкого его настраиваете в плане ethernet, прогоняете сколько_вам_там_надо, видите cpu load, и добавляете к этому скорость шифрования. Получаете примерно ожидаемую цифру.

...

Ребята, Посмотрите исходники: https://github.com/openssl/openssl/blob/master/apps/speed.c

openssl speed - это цикл на одних и тех же данных, т.е. ничего, кроме вычислительной мощности процессора он не показывает: данные будут в кэше L1 после первого же оборота.

IPSec на шлюзе - это принять пакет, заглянуть в таблицу маршрутизации, заглянуть а SPD, заглянуть в SAD, зашифровать и выслать. Для маленьких пакетов само шифрование занимает лишь малую часть процессорного времени, необходимого на обработку каждого пакета.

Андрей

On 1 Feb 2017, at 11:41, Sergey Smitienko mailto:hunter@comsys.com.ua> wrote:

...
Привет.

core.i7.6700k#openssl speed -evp aes-128-cbc

Doing aes-128-cbc for 3s on 16 size blocks: 227357080 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 64 size blocks: 64897721 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 256 size blocks: 16590421 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 1024 size blocks: 4189099 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 8192 size blocks: 524904 aes-128-cbc's in 3.00s

OpenSSL 1.0.2g 1 Mar 2016 built on: reproducible build, date unspecified options:bn(64,64) rc4(16x,int) des(idx,cisc,16,int) aes(partial) blowfish(idx) compiler: cc -I. -I.. -I../include -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -m64 -DL_ENDIAN -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -Wl,-Bsymbolic-functions -Wl,-z,relro -Wa,--noexecstack -Wall -DMD32_REG_T=int -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM -DECP_NISTZ256_ASM The 'numbers' are in 1000s of bytes per second processed. type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes aes-128-cbc 1212571.09k 1384484.71k 1415715.93k 1429879.13k 1433337.86k

В блоках по 64 байта (самый плохой случай - voip) дает 1.3 гигабайта в секунду при полной загрузки одного ядра. Без AES-NI

The 'numbers' are in 1000s of bytes per second processed. type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes aes-128 cbc 167418.06k 182451.93k 188739.07k 187727.19k 194005.67k - 182 мегабайта в секунду.

В обоих случаях это больше, чем нужно, для загрузки гигабитного канала. Скорости работы AES в openssl и в linux kernel практически можно считать одинаковыми.

А AES-256 не нужен. AES-256 на самом деле слабее, чем AES-128. "Assuming you're talking about AES 128 versus AES 256, there is a known weakness in the key expansion function that affects AES256. Fundamentally, the weakness reduces the complexity of AES256 to that lower than AES128." http://eprint.iacr.org/2009/374

...
В Intel NIC гигабитках и старше есть аппаратная поддержка IPSec/AES, которая типа дает wire speed шифрование.

...
Привет,

есть задача - запустить сеть с шифрованием трафика на основе механизма GRE over IPSec/IKEv2 (GRE нужен для dynamic routing, IPSec - для совместимости с решениями других производителей - таковы требования).Если у кого есть опыт использования open source / x86 для подобных задач, поделитесь им, пожалуйста:

* на каких программно-аппаратных конфигурациях какую предельную производительность удалось получить (до начала потерь пакетов)? o CPU/MB/RAM (тип, частота) o NIC (производитель, модель) o операционная система o софт / библиотеки o алгоритм и длина ключа для симметричного шифрования (в реальности - интересует, конечно же, AES-256)

Спасибо!

Andriy Berestovskyy

2 Feb 2 Feb

7:06 a.m.

Да, если взять линукс, настроить и пустить генератором line rate, то можно пойти на шаг дальше и вписав статически ip xfrm state + policy без демона IKE померять точную производительность IPSec :) Андрей

...

On 1 Feb 2017, at 22:32, Sergey Smitienko wrote:

Все в порядке. Берете linux, толкого его настраиваете в плане ethernet, прогоняете сколько_вам_там_надо, видите cpu load, и добавляете к этому скорость шифрования. Получаете примерно ожидаемую цифру.

...
Ребята, Посмотрите исходники: https://github.com/openssl/openssl/blob/master/apps/speed.c

openssl speed - это цикл на одних и тех же данных, т.е. ничего, кроме вычислительной мощности процессора он не показывает: данные будут в кэше L1 после первого же оборота.

IPSec на шлюзе - это принять пакет, заглянуть в таблицу маршрутизации, заглянуть а SPD, заглянуть в SAD, зашифровать и выслать. Для маленьких пакетов само шифрование занимает лишь малую часть процессорного времени, необходимого на обработку каждого пакета.

Андрей

On 1 Feb 2017, at 11:41, Sergey Smitienko wrote:

...
Привет.

core.i7.6700k#openssl speed -evp aes-128-cbc

Doing aes-128-cbc for 3s on 16 size blocks: 227357080 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 64 size blocks: 64897721 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 256 size blocks: 16590421 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 1024 size blocks: 4189099 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 8192 size blocks: 524904 aes-128-cbc's in 3.00s

OpenSSL 1.0.2g 1 Mar 2016 built on: reproducible build, date unspecified options:bn(64,64) rc4(16x,int) des(idx,cisc,16,int) aes(partial) blowfish(idx) compiler: cc -I. -I.. -I../include -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -m64 -DL_ENDIAN -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -Wl,-Bsymbolic-functions -Wl,-z,relro -Wa,--noexecstack -Wall -DMD32_REG_T=int -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM -DECP_NISTZ256_ASM The 'numbers' are in 1000s of bytes per second processed. type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes aes-128-cbc 1212571.09k 1384484.71k 1415715.93k 1429879.13k 1433337.86k

В блоках по 64 байта (самый плохой случай - voip) дает 1.3 гигабайта в секунду при полной загрузки одного ядра. Без AES-NI

The 'numbers' are in 1000s of bytes per second processed. type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes aes-128 cbc 167418.06k 182451.93k 188739.07k 187727.19k 194005.67k - 182 мегабайта в секунду.

В обоих случаях это больше, чем нужно, для загрузки гигабитного канала. Скорости работы AES в openssl и в linux kernel практически можно считать одинаковыми.

А AES-256 не нужен. AES-256 на самом деле слабее, чем AES-128. "Assuming you're talking about AES 128 versus AES 256, there is a known weakness in the key expansion function that affects AES256. Fundamentally, the weakness reduces the complexity of AES256 to that lower than AES128." http://eprint.iacr.org/2009/374

...
В Intel NIC гигабитках и старше есть аппаратная поддержка IPSec/AES, которая типа дает wire speed шифрование.

...
Привет,

есть задача - запустить сеть с шифрованием трафика на основе механизма GRE over IPSec/IKEv2 (GRE нужен для dynamic routing, IPSec - для совместимости с решениями других производителей - таковы требования).Если у кого есть опыт использования open source / x86 для подобных задач, поделитесь им, пожалуйста:

* на каких программно-аппаратных конфигурациях какую предельную производительность удалось получить (до начала потерь пакетов)? o CPU/MB/RAM (тип, частота) o NIC (производитель, модель) o операционная система o софт / библиотеки o алгоритм и длина ключа для симметричного шифрования (в реальности - интересует, конечно же, AES-256)

Спасибо!

Volodymyr Litovka

9:42 a.m.

On 2/1/17 11:21 PM, Andriy Berestovskyy wrote:

...

IPSec на шлюзе - это принять пакет, заглянуть в таблицу маршрутизации, заглянуть а SPD, заглянуть в SAD, зашифровать и выслать. Для маленьких пакетов само шифрование занимает лишь малую часть процессорного времени, необходимого на обработку каждого пакета. Безусловно. Для достижения вменяемой производительности нужно разложить задачи по разным ядрам. А если средствами приложений это сделать нельзя, то брать в руки контейнеры :)

-- Volodymyr Litovka "Vision without Execution is Hallucination." -- Thomas Edison

Andriy Berestovskyy

5:26 p.m.

Привет! Да, RSS, RPS, RFS и т.д. Пробуй, но мне кажется просто не будет: пакеты IPSec между двумя шлюзами будут с теми же MAC/IP, соответственно на RX все будет хешироваться в одну очередь... Контейнеры тебе, мне кажется, не нужны ;) Андрей

...

On 2 Feb 2017, at 10:42, Volodymyr Litovka wrote:

On 2/1/17 11:21 PM, Andriy Berestovskyy wrote:

...
IPSec на шлюзе - это принять пакет, заглянуть в таблицу маршрутизации, заглянуть а SPD, заглянуть в SAD, зашифровать и выслать. Для маленьких пакетов само шифрование занимает лишь малую часть процессорного времени, необходимого на обработку каждого пакета. Безусловно. Для достижения вменяемой производительности нужно разложить задачи по разным ядрам. А если средствами приложений это сделать нельзя, то брать в руки контейнеры :)

-- Volodymyr Litovka "Vision without Execution is Hallucination." -- Thomas Edison

Олександр Троцай

31 Jan 31 Jan

2:13 p.m.

On Tue, Jan 31, 2017 at 01:14:25AM +0200, Volodymyr Litovka wrote: Volodymyr> Привет, Volodymyr> Volodymyr> есть задача - запустить сеть с шифрованием трафика на основе Volodymyr> механизма GRE over IPSec/IKEv2 (GRE нужен для dynamic routing, Volodymyr> IPSec - для совместимости с решениями других производителей - Volodymyr> таковы требования).Если у кого есть опыт использования open source Volodymyr> / x86 для подобных задач, поделитесь им, пожалуйста: Volodymyr> Volodymyr> * на каких программно-аппаратных конфигурациях какую предельную Volodymyr> производительность удалось получить (до начала потерь пакетов)? Volodymyr> o CPU/MB/RAM (тип, частота) Volodymyr> o NIC (производитель, модель) Volodymyr> o операционная система Volodymyr> o софт / библиотеки Volodymyr> o алгоритм и длина ключа для симметричного шифрования (в Volodymyr> реальности - интересует, конечно же, AES-256) Давеча достроил наконец L2TP/IPsec (для яблочных устройств) Вот в логах есть такое [142647.656066] CPU feature 'AVX registers' is not supported. [142647.696326] CPU feature 'AVX registers' is not supported. [142647.757168] CPU feature 'AVX registers' is not supported. [142647.824970] CPU feature 'AVX registers' is not supported. [142647.887955] CPU feature 'AVX registers' is not supported. [142647.945358] AVX or AES-NI instructions are not detected. [142647.983295] AVX or AES-NI instructions are not detected. Тут как в старом анекдоте "Раз что-то ищет, значит что-то знает" -- Best regard, Aleksander Trotsai aka MAGE-RIPE aka MAGE-UANIC My public PGP key placed at http://mvps.adamant.ua/pgp/trotsai.asc Как жаль, что вы наконец-то уходите...

Andrii Zarechanskyi

2:53 p.m.

Привет, Сейчас переписывается код всей цепочки обработки транзитного IP для freebsd. В том числе и переделывают ipsec. Детали тут: http://bu7cher.blogspot.com/2016/12/projectsipsec.html http://bu7cher.blogspot.com/2017/01/fastfwd-freebsd-11.html Насколько улучшилась производительность можно смотреть по BSD Router Project, у ae@freebsd есть отсылки к нему. Плюс BSDRP есть уже релиз в этом году с частями имени ae@freebsd. Статистика по производительности: https://bsdrp.net/documentation/faq#what_s_about_ipsec_performance 2017-01-31 1:14 GMT+02:00 Volodymyr Litovka :

...

Привет,

есть задача - запустить сеть с шифрованием трафика на основе механизма GRE over IPSec/IKEv2 (GRE нужен для dynamic routing, IPSec - для совместимости с решениями других производителей - таковы требования). Если у кого есть опыт использования open source / x86 для подобных задач, поделитесь им, пожалуйста:

- на каких программно-аппаратных конфигурациях какую предельную производительность удалось получить (до начала потерь пакетов)? - CPU/MB/RAM (тип, частота) - NIC (производитель, модель) - операционная система - софт / библиотеки - алгоритм и длина ключа для симметричного шифрования (в реальности - интересует, конечно же, AES-256)

Спасибо!

-- Volodymyr Litovka "Vision without Execution is Hallucination." -- Thomas Edison

_______________________________________________ uanog mailing list uanog@uanog.kiev.ua http://mailman.uanog.kiev.ua/mailman/listinfo/uanog

2865

Age (days ago)

2882

Last active (days ago)

List overview

Download

24 comments

8 participants

participants (8)

Andrii Zarechanskyi
Andriy Berestovskyy
Max Tulyev
Paul Arakelyan
Sergey Smitienko
Victor Cheburkin
Volodymyr Litovka
Олександр Троцай