Криптография *

Хочу рассказать про недавний кейс из своей практики и своих трудовых будней.
Заказчик пришёл с задачей: «Хочу QR-код на сертификатах, чтобы можно было проверить подлинность». У него в голове это выглядело так: он дает мне гугл таблицу с перечнем фамилий, датой, и номером сертификата, скрипт генерирует QR единый для всех сертификатов и как бы этот вопрос закрывается по его мнению. Но при этом должна закрываться самая главная боль - защита от подделки путем переноса QR на другой сертификат. Фактически получалась фикция. С моими возражениями заказчик согласился и я расскажу как мы пришли к криптографическому решению без бэкенда, и покажу конкретный код.

Мы даём кодовым агентам полный доступ к машине: файлы, шелл, git. Значит, сам бинарник должен быть предсказуемым, без сюрпризов. У Claude Code сюрприз есть: он незаметно помечает часть запросов. Судя по логике, цель одна — вычислить тех, кто гоняет Claude, чтобы обучать на его ответах свою модель. Это называется дистилляцией, и для любой AI-компании это прямая кража.

С чего все началось

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

Думал, это вечер работы. requests.get(), выдрать цену, сравнить, отправить в телегу (упрощенно, конечно).

Оказалось, парсинг цен на маркетплейсах — это не про HTTP‑запрос. Это про репутацию IP‑адресов, про то, как браузер выдает себя поведением, и — на финале — про пост‑квантовую криптографию в TLS‑рукопожатии. Три площадки (Ozon, WB, Яндекс.Маркет) дали мне три совершенно разных уровня защиты, и на каждом я застревал по‑своему.

Привет! Задача возникла банальная: нужно передать коллеге пароль, API-ключ или конфиг. Телега — не хочется, почта — тем более. Существующие решения от OneTimeSecret до PasswordPusher и прочих — либо закрытый код и доверяй на слово, либо требуют своего сервера. Одни требуют регистрации, другие — напичканные всем подряд комбайны. Захотелось сделать так: открытый код, шифрование в браузере, сервер физически не может прочитать содержимое и, разумеется, бесплатно.

Так появился BurnAfterRead — self-destructing E2E encrypted drops на Cloudflare Workers.

Представьте, что ваш зашифрованный трафик злоумышленники записывают прямо сейчас. На первый взгляд, это бессмысленно: расшифровать его классическими методами невозможно. Однако существует стратегия «собери сейчас, расшифруй потом» (Harvest Now, Decrypt Later). Суть такого подхода заключается в накоплении зашифрованных данных сегодня, чтобы взломать их завтра, когда появится достаточно мощный квантовый компьютер, называемый в литературе криптографически-значимым квантовым компьютером (Cryptographically Relevant Quantum Computer – CRQC). По нейтральным оценкам крупных международных корпораций, он может появиться через 5–10 лет. С другой стороны, некоторые криптографы считают, что у спецслужб криптографически значимые квантовые компьютеры появятся к 2029 году, а для широкого пользования – примерно к 2032. Для госсектора и крупного бизнеса, где информация требует защиты десятилетиями, это критическая угроза.

Значительная часть такого трафика передается по защищенным каналам на базе набора протоколов IPsec. Его ключевой компонент – протокол IKEv2, отвечающий за согласование ключей и алгоритмов. Изначально он не был рассчитан на использование постквантовых алгоритмов: большие размеры ключей и подписей создавали эксплуатационные сложности. Однако благодаря техническим расширениям IKEv2 теперь поддерживает гибридный режим – одновременное использование классического протокола Диффи–Хеллмана (он позволяет двум сторонам выработать общий секретный ключ по открытому каналу связи) и постквантовых алгоритмов.

TLS 1.3 с прямой секретностью - это правильный выбор. Если завтра скомпрометируют серверный ключ - прошлые сессии не расшифруются. Эфемерные ключи уничтожены. Все продумано.

Проблема в том, что это защита от одного сценария. Не от того, о котором идет речь.

Привет, Хабр! Меня зовут Максим Теплых, эксперт по тестированию на проникновение в ИТ-компании Innostage. В этой статье я хочу рассмотреть тему, которая с годами становится все более актуальной — тестирование систем, использующих ГОСТ TLS. Кратко расскажу о самой технологии, а также покажу подходы и наработки, которые применяем на практике. 

Заранее приношу извинения за объемное и несколько затянутое введение. Хотя изложение начинается не с динозавров и не с истории древней Руси, тему все же необходимо раскрыть с некоторой предыстории.

Это продолжение поста о WardLink — P2P-синхронизации между своими устройствами по LAN без сервера в петле. Здесь про то, куда это может пойти, и про несколько вопросов, на которые у меня пока нет хорошего ответа.

Блетчли-Парк, центр британской разведки во время Второй мировой войны, был хранилищем секретов в то время, когда нацистская угроза продвигалась по Европе. Но для некоторых эти секреты не исчезли и после окончания войны.

В начале XXI века много говорилось о мучительной личной жизни Алана Тьюринга — от его символического помилования британским правительством в 2009 году (после того как в начале 1950-х годов он был привлечён к ответственности и подвергнут химической кастрации за гомосексуальные отношения, которые тогда считались незаконными) до оскароносной биографической картины 2014 года «Игра в имитацию», в которой было показано его величайшее достижение военного времени — расшифровка сообщений, закодированных нацистской машиной «Энигма».

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

Эти документы известны как «Документы Бейли» — по имени их прежнего владельца, Дональда Бейли, который в 1944–1945 годах был помощником Тьюринга в Ханслоуп-Парке и хранил эти документы до самой своей смерти в 2020 году. Как написал Джек Коупленд в статье для журнала «IEEE Spectrum», именно Бейли, недавно окончивший университет по специальности «электротехника», научил Тьюринга «практическим навыкам», необходимым для воплощения идей в области электротехники в реальные схемы. Бейли, который называл Тьюринга «профессором», делал обширные записи о мыслях и экспериментах Тьюринга во время их совместной работы над электротехническими проектами в Ханслоуп-Парке. Проработав там несколько часов, Тьюринг ехал на велосипеде пятнадцать километров до Блетчли-Парка, чтобы заняться своей тогда ещё секретной деятельностью по взлому кодов. Записи Бейли составляют значительную часть вышеупомянутых документов и дают совершенно новое представление о том грандиозном проекте под кодовым названием «Далила», над которым они оба работали.

Сертификат скомпрометирован, а срок действия ещё не вышел — как сказать клиентам «больше ему не верьте»? Разбираем оба механизма отзыва, CRL и OCSP: отзыв, генерация и публикация списков, responder, stapling в nginx/apache. С полным справочником всех параметров.

Выбираете алгоритм хеширования паролей — берёте bcrypt, потому что все берут bcrypt, ставите rounds=10, потому что так в туториале, и идёте дальше. Разбираем, почему это может быть ошибкой, чем отличаются Argon2, scrypt и PBKDF2, и как правильно настроить каждый из них.

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

Звучит как безнадежная задача. Все, что Алиса крикнет Коле, услышит и Ева. Любая информация, которая дойдет до Коли, дойдет и до нее. Кажется, что общий секрет в таких условиях невозможен в принципе.

А теперь плохая новость для нашей интуиции: именно это сейчас происходит на вашем устройстве.

Приглашаем на вебинар, где разберём, как с помощью Axiom JDK Certified внедрять криптографию по ГОСТ без сложной настройки и лишнего кода. На вебинаре покажем живую демонстрацию: как Java-сервисы внутри Kubernetes устанавливают защищённое mTLS-соединение с использованием Axiom JDK Certified, КриптоПро/JTLS (ГОСТ TLS).

Что будет на вебинаре:

В этой статье мы рассмотрим рюкзачную, или ранцевую, криптосистему Шора-Ривеста (Chor-Rivest knapsack). Это один из немногих алгоритмов классической криптографии, который можно рассматривать как постквантовый кандидат. Несмотря на то что сегодня он не считается современной и надёжной постквантовой криптосистемой, его всё равно интересно разобрать как один из нестандартных вариантов такого рода.

Два месяца назад я опубликовал статью про свой pet-проект — E2EE-мессенджер.

Честно говоря, я не ожидал, что она вызовет такой интерес. Прилетели комментарии, замечания, вопросы и довольно полезная критика. Где-то меня поправили по делу. Где-то заставили пересмотреть решения, которые мне самому на тот момент казались нормальными.

И, что самое приятное, часть вещей, которые тогда были только в roadmap, за это время удалось реализовать.

Первая часть:

https://habr.com/ru/articles/1030854/

Проект:

https://github.com/vaazhen/chaos-e2ee-messenger

Вообще, за эти два месяца я понял одну простую вещь.

Написать чат оказалось не так сложно.

Написать E2EE-мессенджер — уже сложнее.

А вот понять, почему Signal делали столько лет, оказалось совсем другой историей.

Сначала кажется: ну есть же документация, есть X3DH, есть Double Ratchet, есть WebCrypto, есть статьи, есть спецификации. Осталось просто аккуратно всё собрать.

Примерно в этот момент где-то вдалеке начинает смеяться инженер из Signal.

Сразу оговорюсь: chaos messenger — это не замена Signal и не “готовый безопасный мессенджер”, а open-source pet-проект, на котором я разбираюсь, как E2EE-системы устроены изнутри.

Готовый децентрализованный бэкенд без своего сервера — звучит заманчиво. На личном опыте двух приложений разбираю, где Nostr реально экономит месяцы работы, а где упирается в одно базовое ограничение и начинает мешать: заметки, чаты, ленты, communities, организации.

1 декабря 1969 года, Вашингтон, штаб-квартира Selective Service. Восемь вечера. В прямом эфире, на глазах у всей страны, конгрессмен Александр Пирни опускает руку в большую стеклянную банку и достаёт первую из 366 синих пластиковых капсул. Внутри — дата: 14 сентября. Этой дате присваивается призывной номер 1. Все мужчины 1944–1950 годов рождения, родившиеся 14 сентября, идут на войну первыми.

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

ONYX — мой pet-project: self-hosted, анонимный, E2E-шифрованный мессенджер. Клиент — Flutter, есть под Windows/Linux/macOS/Android, аккаунт без телефона и почты.

Вышла v1.7-beta. Список изменений ниже, но текст в основном про одну фичу: WardLink, ради которой стоило катить этот релиз.

В российском вебе за неделю сломалось две вещи. 13 июня GlobalSign начал массовый отзыв сертификатов у российских компаний — до 20 000 доменов второго уровня под ударом. Let’s Encrypt 4 июня формализовал санкционные ограничения в новой редакции пользовательского соглашения. Я держу около десятка сайтов, все на Let’s Encrypt; сел и прошёл их по списку — какой issuer у каждого, кому грозит и в каком порядке, какие альтернативы реально работают в 2026 году. Внутри: пайплайн инвентаризации через openssl и crt.sh, конфиг Caddy с двумя issuer-ами в fallback, разбор Google Trust Services, НУЦ Минцифры и тех, кто уже выбыл (Buypass) или присоединился к ограничениям (ZeroSSL).

Что будет, если взять один HTML-файл, браузер, localStorage и git-хостинг с CRUD API? Получится мессенджер. Без backend, базы данных, регистрации, npm и WebSocket. В статье показываю, как устроен Macaroni Messenger: хранение сообщений в .macaroni/, outbox, git-agnostic adapters, storage branch, plugin API и опциональное шифрование.