Re: Время ssl handshake RSA & ECDSA
пт, 27 сент. 2019 г. в 14:34, Илья Шипицин : > > > > пт, 27 сент. 2019 г. в 02:13, Vasiliy Tolstov : >> >> чт, 26 сент. 2019 г. в 20:15, Maxim Dounin : >> > >> > Hello! >> > >> > On Thu, Sep 26, 2019 at 07:47:41PM +0300, Vasiliy Tolstov wrote: >> > >> > > ср, 25 сент. 2019 г. в 16:27, Maxim Dounin : >> > > > >> > > > Начать стоит с вопроса как именно и где вы измеряете время (и >> > > > зачем). Если время измерять на клиенте - то ECDSA медленнее RSA, >> > > > такак операция проверки подписи в ECDSA сильно дороже. >> > > > >> > > > Скажем, для ECDSA P-256 и RSA 2048 ситуация выглядит так: >> > > > >> > > > $ openssl speed rsa2048 ecdsap256 >> > > > ... >> > > > signverifysign/s verify/s >> > > > rsa 2048 bits 0.005821s 0.000168s171.8 5958.5 >> > > > signverifysign/s verify/s >> > > > 256 bit ecdsa (nistp256) 0.0003s 0.0012s 3588.2858.3 >> > > > >> > > > То есть операция проверки подписи для ECDSA в разы дороже, чем для >> > > > RSA. Соответственно если измерять время handshake'а между ничего >> > > > не делающим быстрым сервером и клиентом фиксированной и не очень >> > > > большой производительности - от ECDSA-сертификатов будет сплошной >> > > > вред, ибо на него ляжет на порядок больше вычислительной работы. >> > > > >> > > > Основная польза от ECDSA-сертификатов - это существенно меньшая >> > > > нагрузка на сервер, и соответственно возможность обслуживать >> > > > существенно большее количество клиентов. Но её в таком тесте >> > > > просто не будет видно. >> > > >> > > Прошу прощения за небольшой оффтоп, а если используется mTLS - что >> > > выгоднее использовать в плане производительности ECDSA или RSA? >> > > Учитывая что там все друг другу клиенты и серверы. >> > >> > Ну вот выше циферки же по аналогичным размерам ключей - в случае >> > RSA 2048 вы получите максимальную производительность, ограниченную >> > количеством подписей в секунду - 171.8 sign/s (стоимость >> > верификации в разы меньше, и ей можно пренебречь), а в случае >> > ECDSA P-256 - количеством верификаций, 858.3 verify/s (стоимостью >> > подписи, опять же, можно пренебречь). То есть ECDSA на круг >> > получается раз в 5 выгоднее. >> > >> >> >> Видимо немного неверно сформулировал вопрос или не понял ответ. >> Я имел ввиду ситуацию, когда есть допустим пара сервисов, которые >> просто занимаются выдачей по jwt токену ключа подписанного public >> ключа. Клиент посылает такому сервису jwt токен и csr. На выходе он >> будет иметь подписанный паблик ключ. >> В такой схеме, что выгоднее использовать на сервисах, к которым потом >> будут подключаться? > > > параметры у вас следующие > > 1) переиспользование http сессий (параметр keepalive_requests 100, который в > дефолтном варианте ограничивает кипэлайв 100 запросами) > 2) переиспользование ssl сессий (ssl tickets, ssl sessions) - если оно не > используется, вы попадете как раз на замеры, которые вы привели (это замеры > для полных хендшейков) > > профилировать, на что уходит цпу, можно например, вот этим > > http://nginx.org/ru/docs/ngx_google_perftools_module.html > > > в случае, если сессии не переиспользуются, действительно будет так, что ECDSA > раза в 4 дешевле. > если переиспользуются, по нашему опыту затраты на ssl теряются на фоне > остального (но вы проверьте) > Понял, спасибо! Вопрос скорее был с заделом на будущее, сейчас действительно проблем нет и в целом действительно затраты на ssl малы по сравнению со всем остальным. -- Vasiliy Tolstov, e-mail: v.tols...@selfip.ru ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Время ssl handshake RSA & ECDSA
пт, 27 сент. 2019 г. в 02:13, Vasiliy Tolstov : > чт, 26 сент. 2019 г. в 20:15, Maxim Dounin : > > > > Hello! > > > > On Thu, Sep 26, 2019 at 07:47:41PM +0300, Vasiliy Tolstov wrote: > > > > > ср, 25 сент. 2019 г. в 16:27, Maxim Dounin : > > > > > > > > Начать стоит с вопроса как именно и где вы измеряете время (и > > > > зачем). Если время измерять на клиенте - то ECDSA медленнее RSA, > > > > такак операция проверки подписи в ECDSA сильно дороже. > > > > > > > > Скажем, для ECDSA P-256 и RSA 2048 ситуация выглядит так: > > > > > > > > $ openssl speed rsa2048 ecdsap256 > > > > ... > > > > signverifysign/s verify/s > > > > rsa 2048 bits 0.005821s 0.000168s171.8 5958.5 > > > > signverifysign/s verify/s > > > > 256 bit ecdsa (nistp256) 0.0003s 0.0012s 3588.2858.3 > > > > > > > > То есть операция проверки подписи для ECDSA в разы дороже, чем для > > > > RSA. Соответственно если измерять время handshake'а между ничего > > > > не делающим быстрым сервером и клиентом фиксированной и не очень > > > > большой производительности - от ECDSA-сертификатов будет сплошной > > > > вред, ибо на него ляжет на порядок больше вычислительной работы. > > > > > > > > Основная польза от ECDSA-сертификатов - это существенно меньшая > > > > нагрузка на сервер, и соответственно возможность обслуживать > > > > существенно большее количество клиентов. Но её в таком тесте > > > > просто не будет видно. > > > > > > Прошу прощения за небольшой оффтоп, а если используется mTLS - что > > > выгоднее использовать в плане производительности ECDSA или RSA? > > > Учитывая что там все друг другу клиенты и серверы. > > > > Ну вот выше циферки же по аналогичным размерам ключей - в случае > > RSA 2048 вы получите максимальную производительность, ограниченную > > количеством подписей в секунду - 171.8 sign/s (стоимость > > верификации в разы меньше, и ей можно пренебречь), а в случае > > ECDSA P-256 - количеством верификаций, 858.3 verify/s (стоимостью > > подписи, опять же, можно пренебречь). То есть ECDSA на круг > > получается раз в 5 выгоднее. > > > > > Видимо немного неверно сформулировал вопрос или не понял ответ. > Я имел ввиду ситуацию, когда есть допустим пара сервисов, которые > просто занимаются выдачей по jwt токену ключа подписанного public > ключа. Клиент посылает такому сервису jwt токен и csr. На выходе он > будет иметь подписанный паблик ключ. > В такой схеме, что выгоднее использовать на сервисах, к которым потом > будут подключаться? > параметры у вас следующие 1) переиспользование http сессий (параметр keepalive_requests 100, который в дефолтном варианте ограничивает кипэлайв 100 запросами) 2) переиспользование ssl сессий (ssl tickets, ssl sessions) - если оно не используется, вы попадете как раз на замеры, которые вы привели (это замеры для полных хендшейков) профилировать, на что уходит цпу, можно например, вот этим http://nginx.org/ru/docs/ngx_google_perftools_module.html в случае, если сессии не переиспользуются, действительно будет так, что ECDSA раза в 4 дешевле. если переиспользуются, по нашему опыту затраты на ssl теряются на фоне остального (но вы проверьте) > Время жизни ключа - ротация, допустим 10 минут. > У меня на сервере выходит такое: > sign verify sign/s verify/s > rsa 0.002298s 0.67s 435.2 14924.7 >sign verify sign/s verify/s > ecdsa 0.0001s0.0002s 16490.3 4867.9 > > Как я понимаю в таком случае выигрышнее будет скорость verify ? > > -- > Vasiliy Tolstov, > e-mail: v.tols...@selfip.ru > ___ > nginx-ru mailing list > nginx-ru@nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Время ssl handshake RSA & ECDSA
чт, 26 сент. 2019 г. в 20:15, Maxim Dounin : > > Hello! > > On Thu, Sep 26, 2019 at 07:47:41PM +0300, Vasiliy Tolstov wrote: > > > ср, 25 сент. 2019 г. в 16:27, Maxim Dounin : > > > > > > Начать стоит с вопроса как именно и где вы измеряете время (и > > > зачем). Если время измерять на клиенте - то ECDSA медленнее RSA, > > > такак операция проверки подписи в ECDSA сильно дороже. > > > > > > Скажем, для ECDSA P-256 и RSA 2048 ситуация выглядит так: > > > > > > $ openssl speed rsa2048 ecdsap256 > > > ... > > > signverifysign/s verify/s > > > rsa 2048 bits 0.005821s 0.000168s171.8 5958.5 > > > signverifysign/s verify/s > > > 256 bit ecdsa (nistp256) 0.0003s 0.0012s 3588.2858.3 > > > > > > То есть операция проверки подписи для ECDSA в разы дороже, чем для > > > RSA. Соответственно если измерять время handshake'а между ничего > > > не делающим быстрым сервером и клиентом фиксированной и не очень > > > большой производительности - от ECDSA-сертификатов будет сплошной > > > вред, ибо на него ляжет на порядок больше вычислительной работы. > > > > > > Основная польза от ECDSA-сертификатов - это существенно меньшая > > > нагрузка на сервер, и соответственно возможность обслуживать > > > существенно большее количество клиентов. Но её в таком тесте > > > просто не будет видно. > > > > Прошу прощения за небольшой оффтоп, а если используется mTLS - что > > выгоднее использовать в плане производительности ECDSA или RSA? > > Учитывая что там все друг другу клиенты и серверы. > > Ну вот выше циферки же по аналогичным размерам ключей - в случае > RSA 2048 вы получите максимальную производительность, ограниченную > количеством подписей в секунду - 171.8 sign/s (стоимость > верификации в разы меньше, и ей можно пренебречь), а в случае > ECDSA P-256 - количеством верификаций, 858.3 verify/s (стоимостью > подписи, опять же, можно пренебречь). То есть ECDSA на круг > получается раз в 5 выгоднее. > Видимо немного неверно сформулировал вопрос или не понял ответ. Я имел ввиду ситуацию, когда есть допустим пара сервисов, которые просто занимаются выдачей по jwt токену ключа подписанного public ключа. Клиент посылает такому сервису jwt токен и csr. На выходе он будет иметь подписанный паблик ключ. В такой схеме, что выгоднее использовать на сервисах, к которым потом будут подключаться? Время жизни ключа - ротация, допустим 10 минут. У меня на сервере выходит такое: sign verify sign/s verify/s rsa 0.002298s 0.67s 435.2 14924.7 sign verify sign/s verify/s ecdsa 0.0001s0.0002s 16490.3 4867.9 Как я понимаю в таком случае выигрышнее будет скорость verify ? -- Vasiliy Tolstov, e-mail: v.tols...@selfip.ru ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Время ssl handshake RSA & ECDSA
Hello! On Thu, Sep 26, 2019 at 07:47:41PM +0300, Vasiliy Tolstov wrote: > ср, 25 сент. 2019 г. в 16:27, Maxim Dounin : > > > > Начать стоит с вопроса как именно и где вы измеряете время (и > > зачем). Если время измерять на клиенте - то ECDSA медленнее RSA, > > такак операция проверки подписи в ECDSA сильно дороже. > > > > Скажем, для ECDSA P-256 и RSA 2048 ситуация выглядит так: > > > > $ openssl speed rsa2048 ecdsap256 > > ... > > signverifysign/s verify/s > > rsa 2048 bits 0.005821s 0.000168s171.8 5958.5 > > signverifysign/s verify/s > > 256 bit ecdsa (nistp256) 0.0003s 0.0012s 3588.2858.3 > > > > То есть операция проверки подписи для ECDSA в разы дороже, чем для > > RSA. Соответственно если измерять время handshake'а между ничего > > не делающим быстрым сервером и клиентом фиксированной и не очень > > большой производительности - от ECDSA-сертификатов будет сплошной > > вред, ибо на него ляжет на порядок больше вычислительной работы. > > > > Основная польза от ECDSA-сертификатов - это существенно меньшая > > нагрузка на сервер, и соответственно возможность обслуживать > > существенно большее количество клиентов. Но её в таком тесте > > просто не будет видно. > > Прошу прощения за небольшой оффтоп, а если используется mTLS - что > выгоднее использовать в плане производительности ECDSA или RSA? > Учитывая что там все друг другу клиенты и серверы. Ну вот выше циферки же по аналогичным размерам ключей - в случае RSA 2048 вы получите максимальную производительность, ограниченную количеством подписей в секунду - 171.8 sign/s (стоимость верификации в разы меньше, и ей можно пренебречь), а в случае ECDSA P-256 - количеством верификаций, 858.3 verify/s (стоимостью подписи, опять же, можно пренебречь). То есть ECDSA на круг получается раз в 5 выгоднее. -- Maxim Dounin http://mdounin.ru/ ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Время ssl handshake RSA & ECDSA
ср, 25 сент. 2019 г. в 16:27, Maxim Dounin : > > Начать стоит с вопроса как именно и где вы измеряете время (и > зачем). Если время измерять на клиенте - то ECDSA медленнее RSA, > такак операция проверки подписи в ECDSA сильно дороже. > > Скажем, для ECDSA P-256 и RSA 2048 ситуация выглядит так: > > $ openssl speed rsa2048 ecdsap256 > ... > signverifysign/s verify/s > rsa 2048 bits 0.005821s 0.000168s171.8 5958.5 > signverifysign/s verify/s > 256 bit ecdsa (nistp256) 0.0003s 0.0012s 3588.2858.3 > > То есть операция проверки подписи для ECDSA в разы дороже, чем для > RSA. Соответственно если измерять время handshake'а между ничего > не делающим быстрым сервером и клиентом фиксированной и не очень > большой производительности - от ECDSA-сертификатов будет сплошной > вред, ибо на него ляжет на порядок больше вычислительной работы. > > Основная польза от ECDSA-сертификатов - это существенно меньшая > нагрузка на сервер, и соответственно возможность обслуживать > существенно большее количество клиентов. Но её в таком тесте > просто не будет видно. > Прошу прощения за небольшой оффтоп, а если используется mTLS - что выгоднее использовать в плане производительности ECDSA или RSA? Учитывая что там все друг другу клиенты и серверы. -- Vasiliy Tolstov, e-mail: v.tols...@selfip.ru ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Время ssl handshake RSA & ECDSA
Благодарю, я изначально неверно понял и решил что на стороне клиента также будет уменьшение времени. Еще раз Спасибо. On 25 September 2019 at 15:27:09, Maxim Dounin (mdou...@mdounin.ru) wrote: Hello! On Wed, Sep 25, 2019 at 02:19:55PM +0200, Дмитрий Рыбалка wrote: > Добрый день, прошу помочь разобраться с проблемой: > Nginx 1.16.1 (проблема была и на прошлых версиях) из оф репозитория nginx > для debian, openssl 1.1.1c (проблема есть и на openssl 1.1.0) > Прописываю два ключа RSA & *ECDSA*. Пробовал ключи как от LE так и от comoda > > Пример настроек: > > > ssl_session_cache shared:SSL:5m; > > ssl_session_timeout 30m; > > ssl_ecdh_curve X25519:prime256v1; > > ssl_buffer_size 4k; > > ssl_session_tickets off; > > resolver 8.8.8.8 8.8.4.4 valid=5m; #ipv6=off > > resolver_timeout 1s; > > ssl_prefer_server_ciphers on; > > ssl_protocols TLSv1.2 TLSv1.3; > > ssl_ciphers > > 'TLS_CHACHA20_POLY1305_SHA256:TLS_AES_256_GCM_SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-GCM-SHA384'; > > ssl_stapling on; - включал выключал, разницы нет. > > > > Время хендшейка около 40мс. > Если оставить только RSA то время уменьшается до 10мс > Если оставить только EDSA, то время незначительно меняется и равно 38-39мс > Если проверять скорость подписей openssl то ECDSA реально быстрее RSA, но > почему при https подключении этого не видно? > Проверял как чистым curl, так и black box экспортером для отслеживания > динамики. > Прошу помочь разобраться с данным нюансом Начать стоит с вопроса как именно и где вы измеряете время (и зачем). Если время измерять на клиенте - то ECDSA медленнее RSA, такак операция проверки подписи в ECDSA сильно дороже. Скажем, для ECDSA P-256 и RSA 2048 ситуация выглядит так: $ openssl speed rsa2048 ecdsap256 ... sign verify sign/s verify/s rsa 2048 bits 0.005821s 0.000168s 171.8 5958.5 sign verify sign/s verify/s 256 bit ecdsa (nistp256) 0.0003s 0.0012s 3588.2 858.3 То есть операция проверки подписи для ECDSA в разы дороже, чем для RSA. Соответственно если измерять время handshake'а между ничего не делающим быстрым сервером и клиентом фиксированной и не очень большой производительности - от ECDSA-сертификатов будет сплошной вред, ибо на него ляжет на порядок больше вычислительной работы. Основная польза от ECDSA-сертификатов - это существенно меньшая нагрузка на сервер, и соответственно возможность обслуживать существенно большее количество клиентов. Но её в таком тесте просто не будет видно. -- Maxim Dounin http://mdounin.ru/ ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Время ssl handshake RSA & ECDSA
Hello! On Wed, Sep 25, 2019 at 02:19:55PM +0200, Дмитрий Рыбалка wrote: > Добрый день, прошу помочь разобраться с проблемой: > Nginx 1.16.1 (проблема была и на прошлых версиях) из оф репозитория nginx > для debian, openssl 1.1.1c (проблема есть и на openssl 1.1.0) > Прописываю два ключа RSA & *ECDSA*. Пробовал ключи как от LE так и от comoda > > Пример настроек: > > > ssl_session_cache shared:SSL:5m; > > ssl_session_timeout 30m; > > ssl_ecdh_curve X25519:prime256v1; > > ssl_buffer_size 4k; > > ssl_session_tickets off; > > resolver 8.8.8.8 8.8.4.4 valid=5m; #ipv6=off > > resolver_timeout 1s; > > ssl_prefer_server_ciphers on; > > ssl_protocols TLSv1.2 TLSv1.3; > > ssl_ciphers > > 'TLS_CHACHA20_POLY1305_SHA256:TLS_AES_256_GCM_SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-GCM-SHA384'; > > ssl_stapling on; - включал выключал, разницы нет. > > > > Время хендшейка около 40мс. > Если оставить только RSA то время уменьшается до 10мс > Если оставить только EDSA, то время незначительно меняется и равно 38-39мс > Если проверять скорость подписей openssl то ECDSA реально быстрее RSA, но > почему при https подключении этого не видно? > Проверял как чистым curl, так и black box экспортером для отслеживания > динамики. > Прошу помочь разобраться с данным нюансом Начать стоит с вопроса как именно и где вы измеряете время (и зачем). Если время измерять на клиенте - то ECDSA медленнее RSA, такак операция проверки подписи в ECDSA сильно дороже. Скажем, для ECDSA P-256 и RSA 2048 ситуация выглядит так: $ openssl speed rsa2048 ecdsap256 ... signverifysign/s verify/s rsa 2048 bits 0.005821s 0.000168s171.8 5958.5 signverifysign/s verify/s 256 bit ecdsa (nistp256) 0.0003s 0.0012s 3588.2858.3 То есть операция проверки подписи для ECDSA в разы дороже, чем для RSA. Соответственно если измерять время handshake'а между ничего не делающим быстрым сервером и клиентом фиксированной и не очень большой производительности - от ECDSA-сертификатов будет сплошной вред, ибо на него ляжет на порядок больше вычислительной работы. Основная польза от ECDSA-сертификатов - это существенно меньшая нагрузка на сервер, и соответственно возможность обслуживать существенно большее количество клиентов. Но её в таком тесте просто не будет видно. -- Maxim Dounin http://mdounin.ru/ ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Время ssl handshake RSA & ECDSA
Добрый день, прошу помочь разобраться с проблемой: Nginx 1.16.1 (проблема была и на прошлых версиях) из оф репозитория nginx для debian, openssl 1.1.1c (проблема есть и на openssl 1.1.0) Прописываю два ключа RSA & *ECDSA*. Пробовал ключи как от LE так и от comoda Пример настроек: > ssl_session_cache shared:SSL:5m; > ssl_session_timeout 30m; > ssl_ecdh_curve X25519:prime256v1; > ssl_buffer_size 4k; > ssl_session_tickets off; > resolver 8.8.8.8 8.8.4.4 valid=5m; #ipv6=off > resolver_timeout 1s; > ssl_prefer_server_ciphers on; > ssl_protocols TLSv1.2 TLSv1.3; > ssl_ciphers > 'TLS_CHACHA20_POLY1305_SHA256:TLS_AES_256_GCM_SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-GCM-SHA384'; > ssl_stapling on; - включал выключал, разницы нет. Время хендшейка около 40мс. Если оставить только RSA то время уменьшается до 10мс Если оставить только EDSA, то время незначительно меняется и равно 38-39мс Если проверять скорость подписей openssl то ECDSA реально быстрее RSA, но почему при https подключении этого не видно? Проверял как чистым curl, так и black box экспортером для отслеживания динамики. Прошу помочь разобраться с данным нюансом ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
