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

Илья Шипицин chipitsine на gmail.com
Пт Сен 27 11:34:13 UTC 2019


пт, 27 сент. 2019 г. в 02:13, Vasiliy Tolstov <v.tolstov на selfip.ru>:

> чт, 26 сент. 2019 г. в 20:15, Maxim Dounin <mdounin на mdounin.ru>:
> >
> > Hello!
> >
> > On Thu, Sep 26, 2019 at 07:47:41PM +0300, Vasiliy Tolstov wrote:
> >
> > > ср, 25 сент. 2019 г. в 16:27, Maxim Dounin <mdounin на 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.tolstov на selfip.ru
> _______________________________________________
> nginx-ru mailing list
> nginx-ru на nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
----------- следущая часть -----------
Вложение в формате HTML было извлечено…
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20190927/d56c0e35/attachment-0001.htm>


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