Ключи и алгоритмы: приватный и публичный ключ

Любой сертификат в инфраструктуре Netgap начинается с пары ключей. Трафик между шлюзами шифруется TLS 1.3, а компоненты аутентифицируют друг друга по mTLS — и стойкость всей этой конструкции определяется тем, какой алгоритм выбран для ключа и как обращаются с его приватной частью. Эта статья объясняет, из чего состоит пара ключей, какие семейства алгоритмов поддерживает TLS-стек rustls, и что выбирать для корневого CA тестовой PKI и для сервисов.

Общая картина PKI описана в обзоре методички; как выпущенный ключ превращается в сертификат — в статье Собственная PKI.

1. Пара ключей и асимметричная криптография

В асимметричной криптографии ключи всегда создаются парой:

• приватный ключ (private key) — секрет, который никогда не покидает владельца. Им создаются цифровые подписи;
• публичный ключ (public key) — открытая часть, которую можно показывать кому угодно. Им подписи проверяются.

Математическая связь между ними односторонняя: из приватного ключа публичный вычисляется мгновенно, а восстановить приватный из публичного — вычислительно невозможно.

Именно на этом принципе держится mTLS в Netgap: сервер и клиент во время handshake доказывают владение приватным ключом, а проверяющая сторона убеждается в этом по публичному ключу из сертификата, подпись на котором ведет к доверенному CA (см. Цепочка доверия).

2. Семейства алгоритмов

В современном mTLS и экосистеме rustls (которая по умолчанию отключает устаревшие и небезопасные алгоритмы) практический выбор сводится к трем семействам.

Критерий	RSA (2048/4096)	ECDSA (P-256, P-384)	Ed25519
Стойкость	2048 бит — индустриальный минимум; 4096 бит — для долгоживущих ключей CA	P-256 примерно эквивалентна RSA 3072; P-384 — существенно выше	Уровень P-256, плюс устойчивость к ряду ошибок реализации
Скорость	Самое медленное семейство: заметная нагрузка на CPU при handshake	В разы быстрее RSA	Самая быстрая подпись и проверка
Размер ключа и подписи	Большие (сотни байт) — растет размер сертификатов и трафик handshake	Компактные (ключ 256/384 бит)	Компактные, фиксированная длина
Совместимость	Максимальная, включая legacy-системы	Повсеместная в современных системах	Может отсутствовать в старых веб-серверах и legacy-стеках
Поддержка в rustls	Да (ключи короче 2048 бит отвергаются)	Да	Да

RSA

Основан на сложности факторизации больших чисел; самый старый и самый совместимый алгоритм. Для безопасности требует длинных ключей, поэтому операции медленные.

# Индустриальный минимум — 2048 бит
openssl genrsa -out service_rsa_2048.key 2048

# Максимальная стойкость — 4096 бит (типовой выбор для Root CA)
openssl genrsa -out ca_rsa_4096.key 4096

Все, что короче 2048 бит (например, 1024), современные библиотеки, включая rustls, отвергают.

ECDSA (эллиптические кривые)

Ключи значительно короче RSA при аналогичной или более высокой стойкости, операции быстрее — меньше нагрузка на CPU и меньше байтов в каждом handshake. Вместо «длины в битах» выбирается имя кривой:

# NIST P-256 (prime256v1, secp256r1) — баланс скорости и совместимости
openssl ecparam -name prime256v1 -genkey -noout -out service_ecc_256.key

# NIST P-384 (secp384r1) — повышенный уровень стойкости для CA
openssl ecparam -name secp384r1 -genkey -noout -out ca_ecc_384.key

Ed25519

Схема подписи EdDSA на кривой Curve25519: еще быстрее ECDSA, ключи фиксированной длины, конструкция устойчива к ряду ошибок реализации (например, не требует качественного источника случайности при каждой подписи). Единственный минус — legacy-системы могут его не поддерживать; rustls поддерживает Ed25519 полноценно.

openssl genpkey -algorithm ed25519 -out service_ed25519.key

3. Что выбирать в Netgap

Назначение ключа	Рекомендация	Почему
Root CA	RSA 4096 или ECDSA P-384	Корень создается один раз на годы; важна максимальная стойкость, а скорость не критична — CA подписывает сертификаты редко
Сервисы (серверы и клиенты mTLS)	ECDSA P-256 или Ed25519	mTLS-соединения между компонентами устанавливаются постоянно; короткие ключи экономят трафик и CPU

подсказка

Если все участники цепочки — компоненты Netgap на rustls и нет требований совместимости с legacy, для leaf-ключей смело выбирайте Ed25519. Практический пример выпуска такого сертификата — в статье Собственная PKI.

4. Почему отдельный файл публичного ключа не нужен

При работе с X.509 отдельный файл .pub создавать не требуется, потому что:

• файл приватного ключа (.key) содержит обе части пары — и приватную, и публичную. Это главный секрет владельца;
• файл сертификата (.crt) — публичный «паспорт»: внутри него зашиты данные владельца (Subject, SAN), подпись CA и тот самый публичный ключ. OpenSSL помещает его туда автоматически на этапе создания CSR и подписания.

Увидеть публичный ключ внутри сертификата можно так:

openssl x509 -in cert.crt -pubkey -noout
# -----BEGIN PUBLIC KEY-----
# MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA0Ix...
# -----END PUBLIC KEY-----

Команда извлечения публичного ключа из приватного в отдельный файл существует (openssl rsa -in service.key -pubout -out service.pub), но в mTLS и веб-технологиях такой файл не используется. Отдельные .pub-файлы нужны в других сценариях:

• SSH (~/.ssh/id_ed25519.pub) — SSH не использует систему сертификатов X.509 и работает с «голыми» ключами;
• шифрование файлов — когда вы хотите получать зашифрованные данные, вы отдаете отправителю только публичный ключ (в Netgap для этого сценария используется GPG, а не X.509).

Больше команд инспекции ключей и сертификатов — в статье Инспекция и проверка.

5. Обращение с приватным ключом

осторожно

Правила обращения с приватным ключом

• Права доступа 600 сразу после генерации: chmod 600 service.key. Ключ читает только владелец, ни группа, ни остальные.
• Не коммитить в репозитории — даже приватные. Добавьте *.key в .gitignore до первой генерации.
• Не пересылать по почте, мессенджерам и через облачные диски. Ключ генерируется там, где будет использоваться; наружу уходит только CSR или сертификат.
• Скомпрометированный ключ означает немедленный отзыв сертификата и выпуск нового.

Следующий шаг после генерации ключа — выпуск сертификата в собственной PKI.