Криптографические примитивы — план цикла статей

Чем этот файл является

Замысел цикла crypto-*: почему он такой, из чего состоит и чем отличается от остальной базы. Здесь живёт то, что не помещается в отдельную статью и теряется, когда закрывается тикет, — граница цикла, порядок статей и решения, принятые один раз для всех.

Появился он позже первых статей, и это нормально: пока тем было три, картой служила таблица в тикете. Как только стало пять, карта перестала помещаться в тикет, который к тому же закрывается вместе со статьёй и уносит план с собой.

Чем цикл отличается от остальной базы

Остальная база написана с позиции того, кто систему эксплуатирует: что настроено, чем вариант A отличается от варианта B, что смотреть, когда сломалось. Цикл crypto-* смотрит на уровень ниже — на примитив как таковой, вне конкретного протокола, который его использует.

Разница видна на конкретной паре. reverse-proxy-tls.md объясняет, как терминировать TLS: какие директивы, какие сертификаты, что проверить. crypto-aead.md объясняет, что именно обещает шифр, который там настраивается, при каких двух условиях это обещание действует и что происходит, когда условие нарушено. Первая статья нужна, чтобы настроить; вторая — чтобы понимать, почему в TLS 1.3 есть KeyUpdate и откуда в SSH взялся strict KEX.

Отсюда главное ограничение жанра, и его стоит назвать прямо: цикл не учит писать криптографию. Это не кокетство и не осторожность — это вердикт, который сам по себе часть предмета. Реализация примитива своими руками проигрывает не математике, а побочным каналам, и статьи цикла показывают почему: постоянное время сравнения тега, отсутствие ветвлений по секрету в лестнице Монтгомери, кодировка секрета фиксированной длины. Читателю не предлагается написать AES; ему предлагается понимать, что он выбирает и чего это не покрывает.

Из этого следуют три особенности изложения:

• Каждая статья явно называет, чего примитив не обещает. У AEAD это порядок и число сообщений, у обмена ключами — подлинность собеседника. Дыра в обещании — не оговорка в конце, а отдельный раздел, потому что реальные провалы живут именно там: Terrapin не сломал ни один шифр.
• Там, где выбор реален, статья заканчивается вердиктом. «Зависит от задачи» в этом цикле недопустимо ровно потому, что читатель приходит за решением, которое потом годами стоит в конфиге.
• Привязка к версии и дате обязательна в большей степени, чем в остальной базе. Криптография двигается быстро: за время написания первых статей draft-ietf-tls-hybrid-design успел стать RFC 9954, draft-ietf-tls-ecdhe-mlkem — RFC 10024, SSH-гибрид — RFC 10042, а RFC 8446 был отменён RFC 9846 с ужесточением требования о перевыработке ключей. Утверждение без привязки к документу устаревает молча.

Сквозные решения цикла

Префикс crypto-. Цикл не привязан к одной ОС, но и не набор разрозненных кроссплатформенных тем: статьи ссылаются друг на друга и опираются на понятия, введённые соседями. Префикс отмечает эту связность.

Теги security и network. Новых тегов цикл не вводит. network добавляется там, где протокольного материала заметная доля: статьи про AEAD и про обмен ключами наполовину про TLS, QUIC, WireGuard и SSH, и читатель из сетевого кластера должен находить их по тегу.

Иерархия источников жёстче обычной. Спецификация (RFC, FIPS, NIST SP), исходный код реализации и авторская публикация — первичны и обязательны. Блог годится там, где первичного источника нет по природе вопроса: замеры производительности и статистика развёртывания живут у операторов сетей, а не в RFC, и такие ссылки атрибутируются и датируются явно.

Непроверенное помечается словами. Там, где причинно-следственная связь — реконструкция автора, а не утверждение источника, это сказано прямо. Пример из четвёртой статьи: в FIPS 203 слова «Диффи-Хеллман» нет вовсе, поэтому объяснение, почему стандартизация ушла к KEM, помечено как реконструкция.

План статей

1. AEAD: аутентифицированное шифрование, nonce и откуда берутся лимиты

Написана — crypto-aead.md. Вводит понятия, на которые опирается весь цикл: ключ, nonce, AAD, тег, лимит на объём под одним ключом. Почему шифрование без аутентификации не защищает ни от чего, кроме пассивного чтения; почему повтор nonce стоит по-разному в AES-GCM и ChaCha20-Poly1305; откуда берутся лимиты и почему у файлового формата они выглядят иначе, чем у протокола.

2. ChaCha20 и Poly1305: устройство связки

Написана — crypto-chacha20-poly1305.md. Как устроены обе половины: ARX-конструкция ChaCha20 как ответ на кэш-тайминговую атаку на AES, универсальная хеш-функция Poly1305 в духе Вегмана–Картера и обрезка её ключа, конструкция AEAD из RFC 8439 и цена перехода на 96-битный nonce. Сквозной сюжет — что связку собрал не автор алгоритмов, а потребитель, и что обе половины при этом проектировались под один и тот же профиль нагрузки: много живых ключей без предвычислений на ключ.

3. AES-GCM против ChaCha20-Poly1305: что выбирать

Написана — crypto-aes-vs-chacha20.md. Сравнение с вердиктом: обе половины AES-GCM опираются на специальные команды процессора, обе половины ChaCha20-Poly1305 — нет, и отсюда следует всё остальное. Как дважды переворачивался ответ и почему оба раза из-за железа, а не из-за криптоанализа; измерение на одной машине с замаскированными AES-NI и PCLMULQDQ; постоянство времени как свойство конструкции против свойства реализации; вес выводов статей 1 и 2 при выборе; закрытый список одобренных функций FIPS 140-3 как единственная ось, где вердикт не технический.

4. Обмен ключами и вывод ключей

Написана — crypto-key-exchange.md. Закрывает вопрос, который статья 1 оставила открытым: откуда берётся ключ. Диффи-Хеллман и X25519, почему обмен ключами сам по себе не аутентифицирует, KEM как интерфейс и ML-KEM, гибриды как ответ на «записать сегодня — расшифровать завтра», HKDF с разделением extract и expand.

5. KDF для паролей: Argon2id, scrypt, yescrypt

Написана — crypto-password-kdf.md. Почему из пароля ключ выводят медленно и с памятью, тогда как из общего секрета — быстро. Три поколения защиты как ответы на подешевевшее железо: итерации, память-жёсткость, настраиваемые профили. Почему в системном shadow оказался yescrypt, а не победитель PHC. Как выбирают параметры и чем отличается случай «проверок много» от случая «проверка одна». Опирается на HKDF из статьи 4 — противопоставление с ним и есть стержень темы.

Порядок написания

Нумерация задаёт логику чтения, а не очерёдность работы. Фактический порядок другой и определяется тем, какая дыра в базе больнее:

1. Статья 1 написана первой: без неё четыре существующие статьи про TLS, SSH, WireGuard и OpenVPN упирались в AEAD и не могли никуда сослаться.
2. Статья 4 написана второй, обогнав 2 и 3. Причина в том, что она закрывает дыру, на которую первая статья ссылается прямым текстом, тогда как 2 и 3 разбирают и сравнивают то, что уже описано.
3. Статья 2 написана третьей: устройство симметричной связки, на которое опирается сравнение из статьи 3. Порядок этой пары жёсткий — сравнивать имеет смысл то, что уже разобрано.
4. Статья 3 написана четвёртой и закрыла симметричную половину цикла: к моменту её написания обе сравниваемые схемы и общий интерфейс были уже разобраны, так что ей осталось только сравнение и вердикт.
5. Статья 5 написана последней — не по остаточному принципу, а потому что зависимость от 4 жёсткая: парольный KDF объясняется через противопоставление с HKDF, и до его появления в базе объяснять было не через что.

Запланированных статей после этого не остаётся: цикл в заявленном составе закрыт. Что писать дальше — вопрос не очерёдности, а нового замысла, и черновые формулировки для него собраны ниже, в разделе «Продолжение цикла».

Граф зависимостей

1 ──┬──> 2 ──> 3
    └──> 4 ──> 5

Статьи самодостаточны, но опираются на понятия соседей: 2 и 3 не переопределяют nonce, AAD и тег, 5 строится на противопоставлении с HKDF из 4. Жёстких пар две, и обе по одной причине — вторая статья в паре разбирает то, что первая уже ввела: 2 перед 3 (сравнивать имеет смысл разобранное) и 4 перед 5 (парольный KDF объясняется через противопоставление с HKDF). Связь с первой статьёй мягкая: её понятий достаточно, чтобы читать любую другую.

Продолжение цикла

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

• Подписи: Ed25519 и ECDSA, почему подпись не шифрование наоборот, детерминированные схемы и цена ошибки в нонсе. Постквантовые подписи и почему переход к ним не срочен в отличие от обмена ключами.
• Хеш-функции: SHA-2, SHA-3 и BLAKE как три разные конструкции, атака удлинением сообщения и почему HMAC устроен именно так, где хеш-функция подходит для хранения паролей (нигде).
• Сборка протокола из примитивов: Noise как конструктор рукопожатий, чем он отличается от TLS и почему WireGuard выбрал его.
• Генерация случайных чисел: источники энтропии, getrandom и /dev/urandom, поведение при старте системы и в виртуальной машине, форк процесса.

Связанные заметки

• Устройство ОС — план цикла статей — план соседнего цикла, взятый за образец структуры
• Linux — план цикла статей — самый старый из планов, с которого пошёл жанр
• AEAD: аутентифицированное шифрование, nonce и лимиты — первая статья цикла: интерфейс, nonce, лимиты и границы обещания
• ChaCha20 и Poly1305: устройство связки — вторая статья цикла: ARX, Poly1305, конструкция AEAD и состояние криптоанализа
• AES-GCM против ChaCha20-Poly1305: как выбирать — третья статья цикла: зависимость от команд процессора, постоянство времени и вердикт по классам машин
• Обмен ключами и вывод ключей — четвёртая статья цикла: X25519, KEM, гибриды и вывод ключей из общего секрета
• KDF для паролей: почему медленно и с памятью — пятая статья цикла: три поколения защиты от перебора, yescrypt в системном shadow, подбор параметров под своё железо