пт, 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 теряются на фоне остального (но вы проверьте) > Время жизни ключа - ротация, допустим 10 минут. > У меня на сервере выходит такое: > sign verify sign/s verify/s > rsa 0.002298s 0.000067s 435.2 14924.7 > sign verify sign/s verify/s > ecdsa 0.0001s 0.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