Ориентация главы

К концу тома 7 ваша программа могла доставить байты в любой уголок мира — но каждая передача в интернете пересекает магистрали, дата-центры и прокси, которые вы не можете аудировать. Вопрос тома 8: как установить доверие через недоверенный канал. Этот том — полная карта собственной криптографической стопы XRT: от мельчайших примитивов (хеши, HMAC, AEAD, RSA/ECDSA/Ed25519/x25519) через разбор и проверку сертификатов (DER/PEM, X.509, цепочки доверия) к сборке всех примитивов в транспортный слой «одно рукопожатие, взаимное доверие, шифрование каждой записи» в TLS-клиенте и сервере.

Том разворачивается как пирамида доверия, каждый слой зависит только от нижележащих:

1Фундамент (73-76)хеш/HMAC/KDF дают целостность и деривацию ключей; AEAD даёт конфиденциальность + целостность; асимметричная криптография даёт обмен ключами и подписи; глава дисциплины связывает трёх в систему
2Сертификаты (77-79)DER/PEM кодирование -> разбор сертификата X.509 -> проверка цепочки доверия и отзыва — превращая «кому принадлежит этот открытый ключ» в проверяемое утверждение
3Транспорт (80-82)рукопожатие и проверка подлинности TLS-клиента -> TLS-сервер -> TLS-потоки — доверие возвращается на xnetstream тома 7, шифрование по записям

Зачем в 2026 году собственная криптостопа, а не вызов OpenSSL? Ответ XRT записан в таблице обрезки: криптофундамент нарезан минимальными примитивами — программе, использующей только SHA-1 для WebSocket или случайные токены, не нужно тащить полный TLS; встраиваемая цель может взять только ChaCha20-Poly1305 без RSA; каждый макрос возможностей обрезается независимо. Такая нарезка также даёт учебнику возможность объяснить «зачем существует каждый слой» — большинство учебников по криптобиблиотекам умеют учить только «как вызывать», потому что внутри — ком. Расслоение XRT явное: поверх CRYPTO_CORE (метаданные дайджестов, безопасная очистка, сравнение за постоянное время) дайджесты, HMAC/HKDF, AEAD, обмен ключами и подписи образуют независимые слои, а X.509 и TLS компонуют их слой за слоем.

Две сквозные дисциплины проходят через весь том; заявим их здесь, каждая глава их выкупает:

  • Жизненный цикл ключей: откуда ключи приходят (источник случайности, деривация из парольной фразы, согласование DH), как долго живут (сессия, процесс, персистентность), как умирают (xrtSecureZero, Clear) — у каждого звена явный API. Ключи — не обычные данные: они оставляют следы в журналах, файлах подкачки и аварийных дампах; глава дисциплины (76) посвящена этому целиком.
  • Неудача обязана быть единственной: неудача проверки есть неудача — Open AEAD при несовпадении тега отвергает целиком, никогда не возвращая «возможно подделанный открытый текст»; неудача проверки сертификата есть неудача — никакого «продолжить, но предупредить». Границу безопасности криптографии держат эти железные правила; любая «отказоустойчивость» есть поверхность атаки.

Связи вперёд и назад: xnetstream тома 7 — носитель TLS этого тома (глава 87 напрямую выдаёт шифрованные потоки); HTTP/HTTPS тома 9 и xhttp тома 10 стоят на TLS; а источник случайности главы 12 (xrtSecureRandom) — энтропийная отправная точка каждого ключа тома: криптомодули явно зависят от отдельной возможности RANDOM_SECURE, поэтому файловые и сетевые средства не тянут криптографию из-за него. Обратно, «мышление целостности» этого тома (дайджесты, MAC, привязка AAD) вновь появится в кадрировании и протоколах обновления тома 9.

Три типа читателей — три маршрута. Прикладные разработчики (цель — HTTPS): сразу к TLS-клиенту главы 82, затем по надобности к политике проверки главы 80 — но как минимум прочтите дисциплину главы 77: неверное использование опаснее неиспользования. Разработчики протоколов/промежуточного ПО (собственные протоколы, токены, подписи кэша): внимательно главы 74-77 — хеш/KDF/AEAD/асимметрия есть прямой инструментарий; сертификаты и TLS могут подождать. Аудиторы/инженеры безопасности: весь том по порядку, с фокусом на 76 (дисциплина) и 79 (цепочки доверия и отзыв) — эти две главы концентрируют библиотеку паттернов «как ломаются системы безопасности».

Как читать том 8: сначала запреты, потом интерфейсы

Раздел «контракты» каждой главы тома 8 делит одну структуру: сначала что нельзя делать, потом что можно — глава MD5 сначала заявляет «нет стойкости к коллизиям», глава AEAD — «при несовпадении тега выводом пользоваться нельзя», глава сертификатов — «при неудаче проверки продолжать нельзя». Это зеркально первым семи томам, где «контракты пишут гарантии», потому что режимы отказа криптографии невидимы: повторённый nonce не выдаёт ошибки, постоянное время сравнения или нет не влияет на прохождение функциональных тестов, ошибочная политика проверки всё равно соединяется с сервером — дефект становится видимым только когда атакующий его использует, и тогда уже поздно. Правильное чтение тома — заучивать каждый запрет как часть API: запреты важны не меньше сигнатур функций; код, нарушающий запрет, ошибочен так же, как вызов несуществующей функции. Сопутствующая привычка обучения — «посмотреть своими глазами, как это ломается»: ловушки и упражнения каждой главы ставят разрушительные эксперименты (подмена, повтор, переупорядочивание) — один прогон пути отказа впечатляет сильнее десяти прочтений пути успеха.

Одно напоминание: криптография — не вся безопасность

Том даёт криптографические примитивы — они решают «корректность на слое алгоритмов»; безопасность реальной системы держится ещё на двух слоях: корректность слоя протокола (порядок полей, машины состояний, защита от даунгрейда — в реализации TLS глав 82-84 вы увидите, что протокольная корректность ошибается легче выбора алгоритма) и корректность системного слоя (хранение ключей, права, санитизация журналов, канал обновлений — территория главы 77). Частая иллюзия — «у нас AES-256, значит безопасно»: сила алгоритма — слой, меньше всего становящийся слабым звеном; атакующие всегда ищут два других. Читайте том 8 с этой трёхслойной оптикой: на каждый изученный примитив спрашивайте «откуда его ключ, где хранится, кто может трогать» — этот вопрос направит внимание на настоящее слабое звено.

Самопроверка обучения (перед выходом из тома):

  • По любым данным можете ли вы сказать «хеш, HMAC или подпись» — каковы ключевые модели и предположения доверия трёх?
  • Можете ли вы объяснить, почему nonce AEAD «обязан быть уникальным под одним ключом», и компромисс между счётчиком и генератором случайности?
  • Можете ли вы от руки нарисовать четыре сообщения рукопожатия TLS 1.3 (ClientHello, ServerHello, Finished, Finished) — что каждое несёт и что проверяет?
  • Получив один DER и один PEM, можете ли вы назвать их отношение и направление преобразования?
  • Сколько участков ключевого материала в вашей программе прямо сейчас? Для каждого — источник, хранение, путь очистки: всё отвечаетесь?

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

📖 Справочники API в этой главе:crypto (140 записей)hash (11 записей)tls (201 записей)

Полные сигнатуры, ограничения параметров, возвращаемые значения и ошибки