пт, 27 сент. 2019 г. в 14:34, Илья Шипицин <chipits...@gmail.com>: > > > > пт, 27 сент. 2019 г. в 02:13, Vasiliy Tolstov <v.tols...@selfip.ru>: >> >> чт, 26 сент. 2019 г. в 20:15, Maxim Dounin <mdou...@mdounin.ru>: >> > >> > Hello! >> > >> > On Thu, Sep 26, 2019 at 07:47:41PM +0300, Vasiliy Tolstov wrote: >> > >> > > ср, 25 сент. 2019 г. в 16:27, Maxim Dounin <mdou...@mdounin.ru>: >> > > > >> > > > Начать стоит с вопроса как именно и где вы измеряете время (и >> > > > зачем). Если время измерять на клиенте - то 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-сертификатов - это существенно меньшая >> > > > нагрузка на сервер, и соответственно возможность обслуживать >> > > > существенно большее количество клиентов. Но её в таком тесте >> > > > просто не будет видно. >> > > >> > > Прошу прощения за небольшой оффтоп, а если используется 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