Безопасность по построению: DJB от qmail до Curve25519

Что такое «безопасность по построению»

«Безопасность по построению» — это подход, при котором система спроектирована так, чтобы ошибаться было трудно, а проверять правильность — относительно просто. Идея не в том, чтобы после релиза «добавить шифрование» или закрыть найденные дыры заплатками, а в том, чтобы заранее заложить ограничения, понятные правила и безопасные значения по умолчанию.

Почему важнее дизайн и интерфейсы, чем «самый сильный алгоритм»

На практике взломы чаще происходят не потому, что «криптография слабая», а потому что:

• API позволяет легко сделать опасную вещь (например, отключить проверку, выбрать неправильный режим, перепутать ключи).
• Настройки по умолчанию небезопасны, и их «нужно не забыть включить».
• Слишком много вариантов и скрытых условий: система сложна, значит, неизбежны ошибки в интеграции.

Даже отличный алгоритм не спасает, если вокруг него построена неудобная и двусмысленная инженерия.

Примеры из этой темы

В этой статье мы будем опираться на несколько знаковых примеров. qmail часто приводят как систему, где автор сознательно выбирал простоту и изоляцию компонентов, чтобы уменьшить поверхность ошибок. Curve25519 и Ed25519 стали популярны не из‑за «магии», а потому что в них много решений, которые помогают разработчикам получать корректный результат без тонких ловушек. Современные библиотеки тоже идут в эту сторону: меньше ручных настроек, больше безопасных дефолтов.

Что ожидать дальше

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

Кто такой DJB и в чем суть его подхода

DJB — это Дэниел Дж. Бернстайн (Daniel J. Bernstein), исследователь и инженер, известный на стыке прикладного ПО и криптографии. Его имя часто всплывает в трех контекстах: как автора почтового сервера qmail, как разработчика и соавтора криптографических примитивов (например, Curve25519 и Ed25519), и как человека, который последовательно продвигает идею «сделать правильно проще, чем ошибиться».

Меньше сложности — меньше ошибок

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

Отсюда — предпочтение небольших, четко определенных компонентов, минимального числа режимов работы, детерминированных результатов там, где это возможно, и понятных контрактов. Такая инженерия легче тестируется и аудируется: проверяющим проще ответить на вопрос «что именно должно происходить?».

Безопасные умолчания как практический рычаг

В реальных продуктах большинство проблем возникает не из‑за «плохой криптографии», а из‑за выбора небезопасных параметров, неверного режима, выключенной проверки, случайной совместимости со старыми протоколами. Подход DJB делает ставку на безопасные настройки по умолчанию и ограничение опасных режимов: если пользователь ничего не настраивает, система должна оставаться в безопасном состоянии.

Важная оговорка про контекст

Этот подход полезен, даже если вы никогда не будете использовать конкретные инструменты DJB. Идея применима шире: упрощайте интерфейсы, сужайте пространство конфигураций, делайте безопасное поведение стандартным — и вы получите меньше инцидентов и более проверяемую систему.

qmail как пример инженерной простоты

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

Где чаще всего возникают проблемы в почтовых системах

Типичные сбои и уязвимости появляются на стыке трех вещей: некорректные входные данные (письма, заголовки, вложения), сложные форматы (MIME, кодировки, переносы строк) и протоколы (SMTP и соседние механизмы доставки). Чем больше «автоматики» и скрытых допущений в обработке, тем проще атакующему найти неожиданный путь: от переполнений и обходов фильтров до ошибок маршрутизации и неконтролируемых очередей.

Минимизация поверхности атаки: меньше «магии»

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

Разделение обязанностей и наименьшие привилегии

Вместо монолита, который умеет всё и работает с широкими правами, безопаснее раскладывать функции по процессам/компонентам с четкими границами: прием, постановка в очередь, локальная доставка. Каждый элемент получает ровно те права, которые ему нужны. Если один компонент ломается, ущерб ограничен его ролью — это снижает вероятность «падения домино» по всей системе.

Что перенести на любой сервис

Даже если вы не пишете почтовый сервер, принцип тот же: фиксируйте границы между частями системы, делайте поведение максимально детерминированным и убирайте скрытую сложность. Чем проще модель работы сервиса, тем легче её проверить, объяснить команде и поддерживать без накопления опасной «магии».

Принципы простого дизайна для безопасного ПО

Идея «простого» дизайна у DJB иногда неверно сводится к лозунгу «меньше кода». Но ключевой эффект не в объёме строк, а в количестве путей, по которым система может ошибиться.

«Меньше кода» ≠ «меньше функций»

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

Узкие интерфейсы и явные форматы

Безопасность резко улучшается, когда интерфейс делает невозможной двусмысленность. Узкий API — это когда у функции мало параметров, понятны типы данных, а «опасные» режимы не включаются случайно.

То же с форматами: лучше один явный формат сообщений/ключей, чем множество «почти совместимых». Явные форматы облегчают аудит: проверяющий видит, какие байты откуда берутся, где проверяется длина, где допускаются нули, какие поля обязательны.

Стабильные инварианты

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

Практика: как документировать инварианты

Заведите короткий файл вроде /docs/invariants.md и фиксируйте там 10–20 пунктов:

• что считается корректным входом (формат, длины, кодировки);
• какие режимы намеренно отсутствуют (и почему);
• что библиотека/модуль гарантирует на выходе;
• где стоят проверки (ссылки на функции/модули).

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

Проверяемость: от тестов до верификации

«Проверяемость» — это когда безопасность не держится на вере в автора, а опирается на то, что другой человек (или команда) может повторить проверку и получить тот же результат. Чем проще устройство системы, тем легче понять, где именно обеспечивается защита, и тем меньше риск пропустить скрытую предпосылку.

Тестирование как контракт

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

Несколько практик, которые дают максимум отдачи:

• Негативные тесты: неправильные ключи, подписи, форматы, длины. Система должна предсказуемо отказывать, без «полупринятия».
• Граничные условия: нулевые длины, максимальные размеры, повторяющиеся значения, «почти корректные» входы.
• Fuzzing на уровне идеи: даже без сложных инструментов полезно генерировать множество случайных входов и проверять инварианты (например, «проверка подписи никогда не принимает подпись, если изменён хотя бы 1 бит сообщения»).

Воспроизводимость и цепочка поставки

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

Где уместна формальная верификация

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

Где ломается криптография на практике

Криптоалгоритмы часто «не ломают» в лаборатории — они ломаются в продакшене, на стыке кода, протокола и человеческих решений. Ошибки обычно не выглядят как драматический взлом AES или эллиптических кривых. Они выглядят как неправильный параметр, удобный «хак» в логике или неочевидная утечка через интерфейс.

Типичные причины уязвимостей

1) Случайность (randomness) не такая случайная. Ключи, nonce и соли нередко генерируют «как-нибудь»: берут время, PID процесса, слабый генератор, повторяют nonce после перезапуска. Итог — предсказуемые ключи или повторяющиеся значения, из-за которых шифрование и подписи могут раскрывать секреты.

2) Сравнение секретов «по-обычному». Сравнить MAC/токен через стандартное == кажется нормальным, но время выполнения может зависеть от первой отличающейся позиции. Если злоумышленник может много раз измерять задержку, он постепенно угадывает секрет по байтам.

3) Ошибки форматов и парсинга. Криптография почти всегда упакована в формат: base64, ASN.1, JSON‑поля, префиксы длины. Перепутанные кодировки, неоднозначные представления, отсутствие строгой проверки длины и допустимых значений приводят к обходу проверок, «склейке» сообщений и уязвимостям уровня протокола.

Побочные каналы без математики

Даже если алгоритм правильный, устройство может «подсказывать» секрет поведением: временем ответа, количеством обращений к памяти, различиями в ошибках. Принцип простой: если секрет влияет на то, как выполняется код, значит его можно пытаться извлечь наблюдениями.

Почему опасны «свои» протоколы и режимы

Самодельный протокол часто забывает про аутентификацию, повторы сообщений, согласование параметров и обработку ошибок. Самодельный режим шифрования — типичный путь к «шифруем, но подделывать можно». Криптография не терпит «почти правильно».

Безопасные API как защита от неправильного использования

Хороший интерфейс уменьшает шанс ошибки:

• делает безопасные настройки по умолчанию (алгоритм, длины ключей, AEAD вместо «голого» шифрования);
• требует nonce там, где это критично, или генерирует его внутри;
• возвращает единый результат проверки (без «подсказок» в ошибках);
• скрывает опасные примитивы за высокоуровневыми операциями («зашифровать и аутентифицировать», «проверить подпись»).

Идея «безопасности по построению» здесь максимально практична: меньше свободы для неправильных решений — меньше мест, где криптография ломается на практике.

Curve25519: почему она стала популярной

Обмен ключами — это способ двум сторонам договориться об общем секрете, даже если канал связи прослушивается. На практике это основа защищённых соединений: из общего секрета затем получают ключи для шифрования и аутентификации. «Кривая» (в смысле эллиптической кривой) важна, потому что от неё зависят скорость и безопасность математики, но это не единственный фактор: большинство реальных провалов случается из‑за ошибок реализации, выбора параметров и слишком гибких настроек.

Ориентация на безопасную реализацию

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

Одна из ключевых идей — сделать типовой сценарий быстрым и безопасным без тонкой настройки. Это снижает риск того, что команда начнёт «подкручивать» параметры, не до конца понимая последствия.

Единый «правильный путь» вместо зоопарка опций

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

• разные форматы ключей и совместимость между библиотеками;
• разные проверки входных данных;
• разные трактовки «безопасных настроек по умолчанию».

Curve25519 хорошо ложится на принцип «минимум вариантов — максимум повторяемости». Это упрощает ревью, тестирование и эксплуатацию.

Что важно продуктовой команде

С точки зрения продукта решают не абстрактные свойства математики, а приземлённые вещи: совместимость между клиентами и серверами, стабильные библиотеки, понятные режимы и возможность обновляться без сюрпризов. Curve25519 оказалась удобной точкой сборки: её проще стандартизировать внутри компании, описать в документации и встроить в архитектуру так, чтобы «случайно сделать небезопасно» было трудно.

Ed25519 и подписи: практические уроки

Ed25519 — это схема цифровой подписи на базе кривой Curve25519 (точнее, Edwards‑формы). В практических системах подписи отвечают за простую вещь: доказать, что данные выпустил обладатель закрытого ключа, и что данные не были изменены.

Где подписи реально нужны

Чаще всего Ed25519 встречается в трёх сценариях:

• Обновления и дистрибуция: подпись пакетов/релизов позволяет клиенту проверять подлинность перед установкой.
• Токены и авторизация: подпись выдаваемых сервером токенов или утверждений (claims) делает их проверяемыми без «общего секрета».
• Протоколы и рукопожатия: подпись ключевого материала или сообщений фиксирует «кто с кем говорит», снижая риск подмены.

Настройки по умолчанию и форматы

Практический урок DJB‑подхода — минимизировать свободу интерпретации. Хороший API для Ed25519 обычно:

• даёт однозначные форматы: 32 байта публичный ключ, 64 байта подпись;
• не просит выбирать хэш, режимы, «варианты» — меньше шансов собрать несовместимый протокол;
• по умолчанию работает безопасно: корректно проверяет подпись и возвращает чёткий результат «верно/неверно».

Если вам приходится «договариваться», как сериализовать подпись/ключи, или хранить подпись в «своём» формате — это ранний сигнал проблем совместимости и аудита.

На что смотреть в реализации

При выборе библиотеки и конкретной реализации проверяйте:

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

Как избежать самодельных схем

Не смешивайте подписи с «добавим ещё один хэш/шифрование для надёжности». Самодельные комбинации часто ломаются на стыках форматов и проверок. Лучше выбрать стандартный Ed25519, согласовать единый бинарный формат и зафиксировать его в спецификации протокола — это упрощает тестирование, совместимость и последующий аудит.

Как выбирать библиотеки и API для криптографии

Выбор криптобиблиотеки — это не «какая быстрее» и не «какая популярнее», а какая снижает шанс ошибиться при интеграции. Подход в духе DJB — меньше вариантов, меньше скрытых переключателей, больше проверяемости.

На что смотреть в библиотеке

Начните с нескольких приземлённых критериев:

• Активность сопровождения: регулярные релизы, публичный трекер ошибок, понятная реакция на уязвимости.
• Документация без магии: примеры «как сделать правильно» и чёткие ограничения (что нельзя, какие параметры недопустимы).
• Тесты и тест‑вектора: наличие автотестов, совместимость с известными тест‑векторами (RFC/проектов), воспроизводимые результаты.
• Совместимость и портабельность: поддержка ваших платформ и компиляторов, отсутствие «особых сборок», которые легко сломать в CI.

Если документация превращает безопасную настройку в квест — это сигнал.

Опасность слишком «гибких» API

Чрезмерная универсальность часто означает: десятки режимов, опциональные «ускорители», неочевидные параметры, которые меняют смысл операции. Типичные риски:

• выбор неверного режима шифрования «по умолчанию»;
• смешение кодировок/форматов (байты vs hex/base64) без явных проверок;
• неоднозначные ошибки: например, когда проверка подписи возвращает «ошибка формата» и «подпись неверна» одинаково, или наоборот — позволяет различать их и даёт лишний сигнал атакующему.

Предпочитайте API, где «правильный путь» один, а опасные варианты либо отсутствуют, либо требуют явного, «шумного» выбора.

Как проверить корректность интеграции

Минимальный набор практик:

• прогон тест‑векторов на вашей сборке и целевых архитектурах;
• межплатформенные проверки: один и тот же вход должен давать одинаковый результат на сервере, клиенте и в CI;
• мониторинг ошибок: счётчики неуспешных проверок подписи/расшифровки, алерты на аномалии после релиза.

Политика обновлений и миграций

Криптография живёт дольше релиза. Заранее решите, как вы будете обновлять библиотеку и алгоритмы:

• держите план миграции версий и форматов (например, возможность распознавать «старый» и «новый» формат сообщений);
• избегайте «вечных» зависимостей без обновлений;
• фиксируйте правила обратной совместимости и сроки её поддержки — это часть безопасности, а не только удобства.

Архитектура: куда встраивается криптография

Криптография — это не «слой магии», который можно прикрутить в конце. В архитектуре она должна быть видимой: понятно, что именно защищаем, от кого, и в каких границах. Тогда проще выбрать примитивы, API и проверить, что система делает ровно то, что вы ожидаете.

Данные «в покое» и «в пути» — разные задачи

В пути (между клиентом и сервером, между сервисами) цель — защититься от перехвата и подмены. Типовые решения: TLS с современными наборами шифров, взаимная аутентификация для внутренних сервисов, ограничение «зон доверия».

В покое (диски, бэкапы, снапшоты) цель — снизить ущерб при краже носителя или доступе к хранилищу. Типовые решения: шифрование на уровне диска/тома, шифрование на уровне приложения (когда нужно разграничение по арендаторам/пользователям), отдельное шифрование бэкапов.

Важно: шифрование «в покое» редко спасает от злоумышленника, который уже получил права вашего приложения.

Управление ключами: где живут секреты

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

• хранение в выделенном хранилище секретов или HSM/KMS;
• ротация с понятным расписанием и процедурой отката;
• доступ по принципу наименьших привилегий;
• разделение ролей: кто может читать ключи, кто — лишь запускать операции шифрования/подписи.

Логи и метаданные: то, что обычно выдает всё

Частая ошибка — «крипто всё скрыла, но логи рассказали остальное». Не пишите в логи ключи, токены, сырые персональные данные, приватные части протоколов.

Если данные нужны для диагностики — используйте маскирование, хеширование/псевдонимизацию, короткие идентификаторы, а доступ к логам ограничивайте так же строго, как к продакшену.

Границы ответственности

Криптография обеспечивает конфиденциальность/целостность/аутентичность при корректных ключах, настройках и реализации. Дальше начинается операционная безопасность: права доступа, изоляция окружений, защита CI/CD, обновления, мониторинг и реагирование на инциденты. Без этого даже идеальные примитивы не спасут.

Практическая связка с разработкой продукта

Если вы собираете сервисы быстро (например, через vibe‑coding), риск «сделать рабочее, но небезопасное» только растёт — именно из‑за разрастания конфигураций и неоднородных интеграций. Здесь полезна дисциплина «безопасности по построению»: один внутренний модуль криптографии, зафиксированные форматы и инварианты, минимальные переключатели.

В TakProsto.AI этот подход удобно применять организационно: в planning mode можно заранее зафиксировать инварианты (что хранится, где ключи, какие форматы сообщений), а затем требовать, чтобы реализация им соответствовала. Плюс для проектов с повышенными требованиями часто важен контур: платформа работает на серверах в России и использует локализованные модели, не отправляя данные в другие страны — это не заменяет криптодизайн, но помогает удерживать границы доверия в архитектуре.

Чек-лист «простая и проверяемая криптоинженерия»

Ниже — практичный список, который помогает приблизиться к подходу «меньше магии — больше проверяемости». Он не заменяет криптоэксперта, но снижает шанс ошибиться на ровном месте.

1) Примитивы и протоколы: только стандартное и узнаваемое

Выбирайте широко применяемые примитивы и протоколы с понятной моделью угроз и большим числом внедрений. Избегайте «собственных улучшений» поверх шифрования, подписей или обмена ключами: именно на стыках чаще всего появляются уязвимости (не те режимы, не те параметры, неверная обработка ошибок).

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

2) Безопасные настройки по умолчанию — и меньше переключателей

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

Отключайте опасные опции, если они не нужны продукту. Каждая дополнительная «галочка совместимости» — это новая ветка кода, тестов и потенциальных ошибок. Если опцию всё же оставляете, добавьте явное предупреждение и ограничьте её область применения.

3) План аудита: что именно мы считаем «безопасно»

Заведите короткий документ (1–2 страницы):

• предположения (например, про хранение секретов, доверие к клиенту/серверу);
• инварианты (что никогда не должно происходить: повтор nonce, приём неподписанных данных и т.п.);
• модель угроз (кто атакующий, какие у него возможности);
• критерии приёмки (что аудитор/команда проверяет и как).

4) Эксплуатационные проверки и жизненный цикл

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

Компромиссы и типичные возражения

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

Когда простота упирается в требования

Совместимость заставляет поддерживать старые протоколы и форматы ключей.

Регуляторика и стандарты иногда требуют конкретных наборов алгоритмов или процедур, даже если они сложнее в использовании.

Наследие — это не только старый код, но и внешние клиенты/партнёры, у которых нельзя быстро поменять API.

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

Почему «один правильный путь» не всегда работает

В больших экосистемах несколько платформ, языков и команд. Одно «правильное» API может быть неудобно для части стека — и тогда появятся обходные пути, а они обычно менее безопасны. Иногда лучше дать два поддерживаемых сценария и жёстко запретить всё остальное, чем провоцировать самодельные решения.

Как принимать компромиссы осмысленно

Полезная практика — фиксировать компромисс как инженерный долг:

• описать риск (что может пойти не так и при каких предпосылках);
• ограничить область применения (где это допустимо, а где запрещено);
• документировать решение в ADR/README и добавить проверку в CI.

Как упрощать без «большого переписывания»

Начните с «обвязки»: один внутренний модуль криптографии, безопасные настройки по умолчанию, запрет опасных режимов на уровне типов/конфигов. Затем постепенно переводите компоненты на него и отмечайте устаревшие пути как deprecated. Часто этого достаточно, чтобы система становилась проще итеративно, без остановки разработки.

Итоги: как применить подход в своем продукте

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

5–7 тезисов, которые стоит закрепить в команде

1. Упрощайте дизайн до проверяемого ядра. Если компонент нельзя кратко объяснить и протестировать, его сложно сопровождать безопасно.
2. Безопасные умолчания важнее гибкости. Набор параметров «по умолчанию» должен быть единственным очевидным выбором.
3. Сужайте API: меньше ручек — меньше ошибок. Лучше одна функция «сделай правильно», чем десять опций, половина из которых опасна.
4. Четко формулируйте допущения и угрозы. Что защищаем, от кого, какие атаки считаем реалистичными, что не покрываем.
5. Проверяемость — часть требований. Тесты, воспроизводимые сборки, статический анализ и понятные инварианты — не «добавим потом».
6. Консервативный выбор примитивов и режимов. Используйте широко проверенные решения и избегайте самодельной композиции.
7. Обновления — это функция безопасности. План миграций, ротации и замены алгоритмов должен быть предусмотрен заранее.

Следующий шаг: инвентаризация криптомест и упрощение

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

Затем целенаправленно «сжимайте» интерфейсы: убирайте необязательные параметры, фиксируйте форматы, делайте ошибки явными, добавляйте тестовые векторы и проверку совместимости.

Мост к следующему материалу

Даже идеальные Curve25519/Ed25519 не спасают, если ключи хранятся и выдаются хаотично. В следующей части разберем основы управления ключами и практики безопасных умолчаний: где держать секреты, как делать ротацию и как проектировать конфигурацию так, чтобы «правильно» было проще, чем «как-нибудь»."