--- tags: [security] verified: 2026-09-13 --- # Криптографические примитивы — план цикла статей ## Чем этот файл является Замысел цикла `crypto-*`: почему он такой, из чего состоит и чем отличается от остальной базы. Здесь живёт то, что не помещается в отдельную статью и теряется, когда закрывается тикет, — граница цикла, порядок статей и решения, принятые один раз для всех. Появился он позже первых статей, и это нормально: пока тем было три, картой служила таблица в тикете. Как только стало пять, карта перестала помещаться в тикет, который к тому же закрывается вместе со статьёй и уносит план с собой. ## Чем цикл отличается от остальной базы Остальная база написана с позиции того, кто систему эксплуатирует: что настроено, чем вариант A отличается от варианта B, что смотреть, когда сломалось. Цикл `crypto-*` смотрит на уровень ниже — на примитив как таковой, вне конкретного протокола, который его использует. Разница видна на конкретной паре. [reverse-proxy-tls.md](./reverse-proxy-tls.md) объясняет, как терминировать TLS: какие директивы, какие сертификаты, что проверить. [crypto-aead.md](./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](./crypto-aead.md). Вводит понятия, на которые опирается весь цикл: ключ, nonce, AAD, тег, лимит на объём под одним ключом. Почему шифрование без аутентификации не защищает ни от чего, кроме пассивного чтения; почему повтор nonce стоит по-разному в AES-GCM и ChaCha20-Poly1305; откуда берутся лимиты и почему у файлового формата они выглядят иначе, чем у протокола. ### 2. ChaCha20 и Poly1305: устройство связки Написана — [crypto-chacha20-poly1305.md](./crypto-chacha20-poly1305.md). Как устроены обе половины: ARX-конструкция ChaCha20 как ответ на кэш-тайминговую атаку на AES, универсальная хеш-функция Poly1305 в духе Вегмана–Картера и обрезка её ключа, конструкция AEAD из RFC 8439 и цена перехода на 96-битный nonce. Сквозной сюжет — что связку собрал не автор алгоритмов, а потребитель, и что обе половины при этом проектировались под один и тот же профиль нагрузки: много живых ключей без предвычислений на ключ. ### 3. AES-GCM против ChaCha20-Poly1305: что выбирать Написана — [crypto-aes-vs-chacha20.md](./crypto-aes-vs-chacha20.md). Сравнение с вердиктом: обе половины AES-GCM опираются на специальные команды процессора, обе половины ChaCha20-Poly1305 — нет, и отсюда следует всё остальное. Как дважды переворачивался ответ и почему оба раза из-за железа, а не из-за криптоанализа; измерение на одной машине с замаскированными AES-NI и PCLMULQDQ; постоянство времени как свойство конструкции против свойства реализации; вес выводов статей 1 и 2 при выборе; закрытый список одобренных функций FIPS 140-3 как единственная ось, где вердикт не технический. ### 4. Обмен ключами и вывод ключей Написана — [crypto-key-exchange.md](./crypto-key-exchange.md). Закрывает вопрос, который статья 1 оставила открытым: откуда берётся ключ. Диффи-Хеллман и X25519, почему обмен ключами сам по себе не аутентифицирует, KEM как интерфейс и ML-KEM, гибриды как ответ на «записать сегодня — расшифровать завтра», HKDF с разделением `extract` и `expand`. ### 5. KDF для паролей: Argon2id, scrypt, yescrypt Написана — [crypto-password-kdf.md](./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, и до его появления в базе объяснять было не через что. Запланированных статей после этого не остаётся: цикл в заявленном составе закрыт. Что писать дальше — вопрос не очерёдности, а нового замысла, и черновые формулировки для него собраны ниже, в разделе «Продолжение цикла». ## Граф зависимостей ```text 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`, поведение при старте системы и в виртуальной машине, форк процесса. --- ## Связанные заметки - [Устройство ОС — план цикла статей](./os-knowledge-base-plan.md) — план соседнего цикла, взятый за образец структуры - [Linux — план цикла статей](./linux-knowledge-base-plan.md) — самый старый из планов, с которого пошёл жанр - [AEAD: аутентифицированное шифрование, nonce и лимиты](./crypto-aead.md) — первая статья цикла: интерфейс, nonce, лимиты и границы обещания - [ChaCha20 и Poly1305: устройство связки](./crypto-chacha20-poly1305.md) — вторая статья цикла: ARX, Poly1305, конструкция AEAD и состояние криптоанализа - [AES-GCM против ChaCha20-Poly1305: как выбирать](./crypto-aes-vs-chacha20.md) — третья статья цикла: зависимость от команд процессора, постоянство времени и вердикт по классам машин - [Обмен ключами и вывод ключей](./crypto-key-exchange.md) — четвёртая статья цикла: X25519, KEM, гибриды и вывод ключей из общего секрета - [KDF для паролей: почему медленно и с памятью](./crypto-password-kdf.md) — пятая статья цикла: три поколения защиты от перебора, yescrypt в системном `shadow`, подбор параметров под своё железо