P-256 или P-384: когда оправдан 192-битный ECDSA

Выбор между P-256 и P-384 — это выбор между двумя кривыми NIST одного семейства: те же алгоритмы (ECDSA и ECDH), те же кодировки, те же инструменты. P-384 поднимает классическую стойкость примерно со 128 до 192 бит; P-256 в несколько раз быстрее, и её поддерживает больше оборудования. Для большинства систем решение определяется политикой, а не риском.

Коротко о главном

Скорость измерялась на одном ядре Apple M4 Max с помощью openssl speed; скрипт для размеров, приведённый ниже, запускался с OpenSSL 3.6.5.

Какая стойкость вам нужна?

NIST SP 800-57, часть 1, относит кривые длиной 256–383 бита к уровню стойкости 128 бит, а кривые длиной 384–511 бит — к уровню 192 бита. Уровень 128 бит далеко за пределами возможностей любой классической атаки, которую можно ожидать в обозримом будущем: лучшей известной атаке на P-256 нужно порядка 2¹²⁸ групповых операций. Дополнительный запас стойкости P-384 защищает от неожиданного прогресса в криптоанализе эллиптических кривых, а не от полного перебора, и никак не помогает против алгоритма Шора, который взламывает обе кривые примерно с одинаковыми затратами. Поэтому NIST IR 8547 (первый публичный проект) относится к ним одинаково: ни одна из них не объявляется устаревшей в 2030 году (это касается только алгоритмов со стойкостью 112 бит, таких как RSA-2048 и P-224), а после 2035 года обе запрещены.

На деле выбор определяет политика. Первоначальный набор алгоритмов NSA Commercial National Security Algorithm Suite (CNSA 1.0) требовал P-384 для ECDH и ECDSA, поэтому продукты для систем национальной безопасности США и их цепочек поставок используют её по умолчанию; CNSA 2.0 заменяет её на ML-KEM-1024 и ML-DSA-87. Центры сертификации часто выбирают P-384 для корневых и промежуточных ключей, которые должны оставаться надёжными десять лет и дольше: ISRG Root X2 от Let's Encrypt и его промежуточные сертификаты ECDSA используют P-384, а сертификаты абонентов (subscriber certificates) могут быть на любой из двух кривых.

Цена в скорости и размере

Для P-256 в OpenSSL есть ассемблерный код, оптимизированный вручную, поэтому разрыв так велик: на одном ядре Apple M4 Max около 87 000 подписей P-256 в секунду против примерно 9 700 для P-384 и около 29 000 проверок против 4 500. У TLS-сервера ключ сертификата подписывает один раз за полное рукопожатие, поэтому P-384 увеличивает эту часть затрат на рукопожатие примерно в девять раз; для центра сертификации, который подписывает несколько сертификатов в секунду, это не имеет значения.

Размеры растут умеренно: подписи в формате raw — на 32 байта, открытые ключи — на 32 байта, сертификаты — примерно на 60 байт.

#!/bin/sh
dir=$(mktemp -d)
cd "$dir" || exit 1
printf 'hello' > msg
for curve in P-256 P-384; do
  openssl genpkey -algorithm EC -pkeyopt ec_paramgen_curve:$curve -out key.pem 2>/dev/null
  openssl req -new -x509 -key key.pem -subj "/CN=example.com" -days 90 -outform DER -out cert.der 2>/dev/null
  openssl dgst -sha256 -sign key.pem -out sig.der msg
  printf '%s: SPKI %s bytes, DER signature %s bytes, self-signed certificate %s bytes\n' "$curve" \
    "$(openssl pkey -in key.pem -pubout -outform DER | wc -c | tr -d ' ')" \
    "$(wc -c < sig.der | tr -d ' ')" \
    "$(wc -c < cert.der | tr -d ' ')"
done
cd / && rm -rf "$dir"

P-256: SPKI 91 bytes, DER signature 71 bytes, self-signed certificate 388 bytes
P-384: SPKI 120 bytes, DER signature 102 bytes, self-signed certificate 451 bytes

Поддержка

Обе кривые есть в FIPS 186-5 и SP 800-186, в каждой библиотеке TLS, в WebCrypto, в JOSE и COSE, в смарт-картах PIV и в списке допустимых ключей сертификатов CA/Browser Forum (P-256, P-384 и P-521). Пробелы — в защищённом оборудовании и аутентификаторах: Secure Enclave от Apple для классических ключей предлагает только P-256, в ключах доступа почти повсеместно используется ES256, а некоторые защищённые элементы для IoT реализуют только P-256. На стороне сервера HSM и облачные сервисы KMS поддерживают обе кривые.

Что когда выбирать

• Публичные сертификаты TLS: P-256. С ней рукопожатия быстрее, и её принимают везде; конечные сертификаты на P-384 не дают выигрыша, который клиент мог бы проверить.
• Ключи корневых и промежуточных CA: P-384 — распространённый и разумный выбор для долгоживущих ключей; такой ключ может подписывать конечные сертификаты на P-256.
• JWT и API-токены: ES256, если только профиль (например, в некоторых государственных или финансовых спецификациях) не требует ES384.
• Ключи доступа и ключи устройств: P-256, потому что именно её предлагает оборудование.
• Системы, на которые распространяется CNSA 1.0, и их поставщики: P-384 с SHA-384, а также AES-256; планируйте переход на ML-KEM-1024 и ML-DSA-87 по CNSA 2.0.
• Гибридный постквантовый TLS: X25519MLKEM768 для общего применения; SecP384r1MLKEM1024 — там, где политика в духе CNSA требует кривых NIST и параметров категории 5.

Заметки о миграции

Смена кривой означает новые ключи, но инструменты остаются прежними.

1. Сгенерируйте новый ключ командой openssl genpkey -algorithm EC -pkeyopt ec_paramgen_curve:P-384 (или P-256) внутри HSM или KMS, где он будет храниться.
2. Подберите к кривой правильный хеш. P-384 обычно используют с SHA-384 (ES384, ecdsa-with-SHA384); ECDSA усекает более длинные хеши до длины порядка группы, но несогласованные пары сбивают с толку проверки политик и некоторые проверяющие стороны.
3. Обновите идентификаторы: alg и crv в JOSE, алгоритм в COSE, схему подписи в TLS и профили сертификатов. На время ротации опубликуйте оба ключа в JWKS с разными значениями kid.
4. Измените размеры фиксированных буферов: подписи в формате raw вырастают с 64 до 96 байт, координаты — с 32 до 48 байт.
5. Измерьте скорость рукопожатий, прежде чем переводить нагруженный эндпоинт TLS на сертификат P-384; большинство систем, которые переходят на P-384 из-за требований политики, оставляют P-256 там, где эта политика не действует.

Источники

• NIST SP 800-186 (P-256 в § 3.2.1.3, P-384 в § 3.2.1.4)
• FIPS 186-5, стандарт цифровой подписи
• NIST SP 800-57, часть 1, редакция 5, таблица 2
• NIST IR 8547, первый публичный проект
• RFC 7518, § 3.4: ES256 и ES384
• NSA: рекомендации по алгоритмам CNSA 2.0
• Базовые требования CA/Browser Forum, § 6.1.5
• Цепочки доверия Let's Encrypt