Re: Время ssl handshake RSA & ECDSA
Vasiliy Tolstov
v.tolstov на selfip.ru
Чт Сен 26 21:12:58 UTC 2019
чт, 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. На выходе он
будет иметь подписанный паблик ключ.
В такой схеме, что выгоднее использовать на сервисах, к которым потом
будут подключаться?
Время жизни ключа - ротация, допустим 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 at selfip.ru
Подробная информация о списке рассылки nginx-ru