Re: Время ssl handshake RSA & ECDSA

Vasiliy Tolstov v.tolstov на selfip.ru
Пт Сен 27 23:34:38 UTC 2019


пт, 27 сент. 2019 г. в 14:34, Илья Шипицин <chipitsine at gmail.com>:
>
>
>
> пт, 27 сент. 2019 г. в 02:13, Vasiliy Tolstov <v.tolstov at selfip.ru>:
>>
>> чт, 26 сент. 2019 г. в 20:15, Maxim Dounin <mdounin at mdounin.ru>:
>> >
>> > Hello!
>> >
>> > On Thu, Sep 26, 2019 at 07:47:41PM +0300, Vasiliy Tolstov wrote:
>> >
>> > > ср, 25 сент. 2019 г. в 16:27, Maxim Dounin <mdounin at 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.tolstov at selfip.ru


Подробная информация о списке рассылки nginx-ru