Коротко и по делу — что сделать и куда писать, чтобы получить полезную оценку и подготовить прототип к hardening. Разобью на: куда обращаться/как просить ревью и — какие конкретные шаги и проверки провести.
Куда и как просить оценку / начать обсуждение
- Подготовьте минимально достаточный пакет для ревью: понятный DESIGN.md (цели безопасности, API, модель использования), threat-model.md, тестовые векторы и инструкции для запуска (чистый CI), SECURITY.md (или security.txt) с контактами и политикой раскрытия уязвимостей. В README явно укажите: “experimental — do not use in production”.
- На GitHub:
- Включите GitHub Discussions и откройте тему “Security review / crypto review / pre-hardening”.
- Создайте issue с меткой help-wanted / security-review и приложите ссылки на SPEC, тесты и векторы.
- Включите GitHub Security Advisories (для приватного приёма уязвимостей).
- Сообщества и форумы:
- crypto.stackexchange.com (для формальных вопросов), r/crypto и r/netsec (для обсуждений и замечаний), Hacker News/LOB communities (при осторожном анонсе).
- OpenSSF Slack, OWASP локальные группы, профильные чаты (Matrix, Telegram) — для практических советов.
- Профессиональные ревью и аудит:
- Для серьёзной оценки ищите фирмы/компании: Trail of Bits, Cure53, NCC Group, Kudelski Security и т.п. Это платно, но даёт профессиональную гарантию.
- Альтернатива — академические криптографы: написать авторам статей/лабораториям (IACR, университеты). Часто могут дать отзыв или направление, но не обязательно полный аудит.
- Багбаунти / публичный вызов:
- Сначала объявите “experimental / bounty for crypto break” с небольшим вознаграждением (HackerOne, Bugcrowd или собственный bounty в README). Это привлечёт практиков.
- При контакте с экспертами:
- Дайте чёткий scope: что вы хотите проверить (криптографическая стойкость, протокол, реализации, side-channel) и какие ресурсы предполагается у атакующего.
- Предоставьте тестовый вектор, скомпилированный бинарник и инструкции по воспроизведению.
Конкретные шаги для подготовки к hardening (проверки и меры)
1) Документация и модель угроз
- Опишите активы (секретная последовательность, одноразовые ключи, серверные секреты), доверенные компоненты, допустимые атаки, требования безопасности (конфиденциальность, целостность, автентичность, устойчивость к переиспользованию, forward secrecy).
- Определите сильнейшего противника (квалификация, ресурсы: локальный/удалённый, взлом оборудования, перехват трафика, компрометация сервера).
2) Критическое замечание: осторожно с «собственной криптографией»
- Если алгоритм — новая криптопримитива/схема аутентификации, не ставьте её в продакшн до независимой крипто-анализа и (по возможности) формальных доказательств безопасности.
- По возможности базируйтеся на проверенных примитивах (HKDF, HMAC, AES-GCM, ChaCha20-Poly1305, Argon2id).
3) Криптоархитектура и рекомендации
- Чётко опишите, как из секретной последовательности получаются одноразовые ключи: KDF/PRF, соль/nonce, счётчик/контекст.
- Используйте KDF типа HKDF или Argon2id для растягивания/усиления секретов, особенно если секрет низкоэнтропийный.
- Для передачи/проверки — AEAD (например, ChaCha20-Poly1305) или подписные схемы; обязательна проверка на повторный ввод/реплеи (nonce, timestamp, серверный state).
- Подумайте о хранении: не храните секрет в чистом виде, используйте OS keychain / secure enclave / TPM по возможности.
4) Формальные и эмпирические проверки крипто
- Формальные доказательства: попытайтесь свести безопасность схемы к стандартной задаче (иконструкция -> PRF/IND-CPA/UF-CMA и т.п.). Если не можете — это риск.
- Статистические тесты ключей/псевдослучайности: NIST STS, Dieharder, TestU01 (чтобы выявить статистические аномалии в генерации).
- Криптоанализ: exhaustivity / meet-in-the-middle / subset-sum / differential анализ в зависимости от конструкции — опишите и попросите ревью у криптографов.
- Предоставьте test-vectors (ключи, ожидаемые OTP) для независимой проверки.
5) Реализация и защита от уязвимостей
- Язык/библиотеки: по возможности безопасные языки (Rust) или минимально — безопасный стиль в C с аудиторией. Используйте battle-tested библиотеки (libsodium, BoringSSL).
- Константное время: критические операции (сравнение ключей, вычисления) — constant-time.
- Секреты в памяти: минимизировать время в памяти, использовать secure zeroing, guard pages, избегать свопа (mlock).
- Защита от side channels: тайминги, кэш-атаки — особенно если цель — высоко ценная секрета.
- Управление зависимостями: Dependabot, SCA (snyk, GitHub Dependabot), CI-сканеры (Semgrep, Bandit, Trivy).
6) Тесты и автоматизация
- Unit тесты + интеграционные тесты (у вас уже есть).
- Fuzzing (LibFuzzer, AFL) для парсеров/сериализации/входов.
- Property-based testing (Hypothesis/QuickCheck) для свойств протокола (например, одноразовость, невозможность предсказания).
- Regression тесты и тест-векторы.
- CI: статический анализ (clang-tidy, cppcheck), SAST, DAST, секрет-сканирование.
7) Threat/Attack specific mitigations
- Защита от перебора: rate-limiting, exponential backoff, account lockout.
- Защита от shoulder-surfing/ловли последовательности: если секрет — последовательность действий, предусмотреть тупиковую политику, биометрию/2FA как опцию.
- Логи и мониторинг: не логировать секреты, логировать аномалии (много неудачных попыток).
- Ревокация/разморозка: процесс восстановления доступа при компрометации секрета.
8) Аудит и публичная проверка
- Перед платным аудитом сделайте “pre-audit” — внутренний чеклист, CI-проход, фиксированные тесты, и public disclosure для сбора фидбека.
- Закажите полный аудит у профильной компании; ожидайте цену от нескольких тысяч до десятков тысяч долларов в зависимости от объёма.
- После аудита — исправляйте, публикуйте ответную ведомость (fix report).
9) Разработка политики безопасности репозитория
- SECURITY.md с инструкцией для отправки уязвимостей.
- CODE_OF_CONDUCT, CONTRIBUTING, ISSUE/PULL_REQUEST шаблоны.
- Добавьте метки “security-review-requested” и используйте CODEOWNERS для специалистов.
10) Если хотите — сделать публичный вызов
- Опубликуйте CTF/challenge: награда за взлом конкретного аспекта (replay, предсказание ключа) — это быстрый способ получить практический криптоанализ от сообщества.
Полезные стандарты/ресурсы (по очереди прочтения)
- OWASP Authentication Cheat Sheet
- NIST SP 800-63 (идентификация и аутентификация)
- IETF RFCs по KDF/HKDF, AEAD
- OpenSSF best practices, Scorecards
- ProVerif / Tamarin / CryptoVerif — для формального моделирования протоколов
Краткий приоритетный план на ближайший месяц
1. Написать DESIGN.md + threat-model.md + SECURITY.md и пометить репо как experimental.
2. Добавить test vectors и инструкции для воспроизведения: “how to break this” (см. 1–2 attack scenarios).
3. Запустить статический анализ + dependency scanning + fuzzing на CI.
4. Опубликовать в GitHub Discussions и сообществах просьбу о крипто-ревью, приложив документы.
5. По результатам отзывов — подготовить scope для профессионального аудита/багбаунти.
Последнее (важное предупреждение)
- Новая криптография — это риск. Не используйте схему в реальных сервисах без независимой рецензии и формальных гарантий. Лучше сначала применить ваш метод в экспериментальном проекте и лишь после полноценной верификации — в продуктиве.
Если хотите, могу:
- помочь составить DESIGN.md и threat-model.md на основе вашей реализации и описания алгоритма;
- составить готовый шаблон SECURITY.md и пример issue для запроса ревью;
- подсказать, какие именно тест-векторы и свойства добавить в ваш репозиторий.
Напишите, хотите ли, чтобы я подготовил шаблоны (по вашим исходным файлам) — и приложите короткое описание алгоритма (как именно из последовательности получаются ключи).