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

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

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

Совместную выставку Музея криптографии и Бастиона «Ключ к доверию. Безопасность в эпоху высоких технологий» готовили целый год. За это время первоначальная концепция проекта успела претерпеть ряд трансформаций, но главная задумка осталась неизменной. Вместо абстрактного рассуждения в духе «вот так правильно, а вот так опасно» выставка дает посетителю самому оказаться в различных ситуациях, сделать осознанный выбор в части кибербеза и посмотреть, к каким последствиям это приведет. 

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

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

Браузер открыл страницу. Замок на месте, предупреждений нет.

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

Можешь ли быть полностью анонимен в интернете? Сделал среду для работы в интернете через Tor поверх Shadowsocks

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

В марте 2026 года две независимые группы объявили о результатах, которые заметно сокращают разрыв между теорией и реальными машинами. Звёздная команда квантовых физиков из Калифорнийского технологического института (Калтеха) представила проект квантового компьютера, способного взламывать шифрование RSA и ECC всего лишь с помощью десятков тысяч кубитов, и заявила о создании компании для его разработки. А исследователи из Google объявили о разработке реализации алгоритма Шора, которая в десять раз эффективнее лучшего из предыдущих методов.

Но почему именно алгоритм Шора так интересует большинство специалистов по квантовым вычислениям? Примерно 30 лет назад математик Питер Шор взял за основу узкоспециализированный физический проект — компьютер, который работал бы по контринтуитивным законам квантовой механики, — и потряс мир.

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

Четвёртая часть цикла про свой удостоверяющий центр. В первой мы развернули Root CA и три промежуточных центра, во второй научились отзывать сертификаты и подняли OCSP-responder, в третьей настроили вход по клиентскому сертификату в nginx и Apache. Осталось ответить на вопрос, который возникает сразу после первого успешного входа: а откуда у людей берутся сертификаты?

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

В четвёртой части:

— PKCS#10 прямо в браузере. Ключ рождается в WebCrypto и не покидает его, запрос собирается на голом JavaScript без единой библиотеки, а результат проверяется настоящим openssl, а не «на глаз».

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

— PKIDesk: движок управления сертификатами на Go, без единой зависимости, под Apache-2.0. Разрезан по границе доверия — у веб-части нет ни ключей УЦ, ни index.txt, ни даже бинарника openssl. Плюс пять архитектурных развилок, за которые придётся отвечать перед аудитом.

— Три дефекта, которые вылезли только на живом стенде: правило subjectAltName = supplied, которое не выполнится никогда; просроченный сертификат, который остаётся действующим и занимает subject; гонка «выпустил — сразу зашёл», где nginx запоминает неудачную проверку отзыва.

— Четыре расширенных справочника, 237 параметров: openssl req, openssl genpkey, структура PKCS#10 и Web Crypto API — синтаксис, значения, умолчания и подводные камни, сверенные с официальной документацией.

«Он подписан, издатель известный» — этим аргументом закрывают вопрос про стороннюю программу, которую тянут в сборку или ставят на рабочий компьютер. Возразить с ходу нечем: вкладка «Цифровые подписи» в свойствах файла и правда показывает «Эта цифровая подпись действительна». Случаи, когда вредоносный файл подписан настоящим сертификатом, редки — на них и не рассчитывают. В таких разговорах я обычно зануда.

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

Знакомая схема защиты от подмены. Сервер кладёт клиенту cookie user=guest&role=reader и рядом — подпись sha256(secret + данные), чтобы клиент не переписал reader на admin. Секрет знает только сервер, поэтому пересчитать подпись под изменённые данные клиент вроде бы не может.

Поломается не сама SHA-256, а конструкция вокруг неё: к данным можно дописать хвост &role=admin и предъявить к нему валидную подпись, не зная секрета вообще. Атака называется length extension, и в статье мы её проделаем на своём же сервере.

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

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

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

Вот почему истинная непредсказуемость крайне важна.

Учёные из Швейцарского федерального технологического института Цюриха (ETH Zurich) опубликовали научную работу, в которой случайность достигает настолько высокого уровня (см. диаграмму в конце статьи со значением CHSH S = 2,271), который вообще невозможен в любой локально-реалистической теории. Только квантовые эффекты позволяют повысить теоретически возможный лимит S с 2 до 2√2.

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

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

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

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

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

В первой части я обещал беспарольный вход в админку. Здесь он наконец заработал.

Что внутри:

— mTLS в nginx и apache: все директивы, все переменные $ssl_client_* и SSL_CLIENT_*, семь справочников на 309 параметров, сверенных с документацией; — вход по кнопке вместо диалога выбора сертификата на первом же заходе — с отдельным хостом, одноразовым пропуском и защитой от login CSRF; — выпуск сертификата в один клик: ключ рождается в браузере и не уезжает на сервер; — свой web-УЦ на Go без единой зависимости, где ключ УЦ отделён от веба сетевой границей.

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

Разработал .fsecurity — отдельный модуль FlautCompany для защиты файлов, в котором ключи шифрования не хранятся в базе данных. Разбираю архитектуру и принцип разделения данных и ключей.

Как я улучшил гибридный квантово-устройчивый протокол шифрования за 4 месяца экспериментов. Разбор различных методов ротации ключей, NTT и других нюансов проектирования протоколов шифрования с объяснением.

Мы храним зашифрованные данные, и рядом с ними лежат ключи, которые к этим данным не подходят. Выглядит как расстройство для взломщика.

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

Броский заголовок есть, а теперь к сути. Сие ошибка, стандартный привет от дефолтного модуля pion/webrtc в Go. Воспроизводится просто – читаем обычные мануалы по использованию pion, выкатываешь красивый WHEP-хендлер, открываешь пару (ладно, ладно, не пару, просто красивый оборот) вкладок с плеером в браузере, и сервер начинает захлебываться. Хендшейки виснут по секундам, ICE отваливается по таймауту, а в pprof половина флеймграфа забита crypto/elliptic.p256OrdSqr и аллокациям мап внутри движка. Сюрприз? Да никакого сюрприза, если более вдумчиво почитать большинство «туториалов» по WebRTC на Go. Мне кажется, что они впринципе написаны теми, кто никогда не тестировал свою реализацию под нагрузкой даже полсотни одновременных зрителей – максимум пару-тройку потоков и успокоились на этом. Так вот, там на каждый POST-запрос с SDP-оффером создают новый webrtc.NewAPI(), регистрируют дефолтные кодеки, дергают api.NewPeerConnection() и со спокойной душой отдают ответ. На локалхосте, с парой клиентов это летает и работает без проблем. А вот на проде – превращается в катастрофу. Проблема здесь не в самом WebRTC (и уж тем более библиотеке pion`a, она очень крутая) и не в Go. Проблема в том, что глобальную и дорогую «инфраструктуру» создают на каждый(!) запросом, вместо того чтобы просто ее переиспользовать.

Мы делаем мессенджер RCQ (rcq.app, исходники клиентов на github.com/rcq-messenger). В нём есть штука, которую в разных приложениях называют по-разному: паничный PIN, duress PIN, подставной код. Смысл один. У вас просят разблокировать телефон, вы вводите второй PIN, и человек напротив видит приложение, в котором ничего интересного нет.

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

2.08.2026 года, в день когда в ЕС реально завелась статья 50 AI Act, Anthropic сделала ход конём: с этого дня каждый текст, который выдаёт свеженькая модель Claude, тащит в себе невидимую метку. (Не пиксель или строчку метаданных в углу, а метку, вплетённую прямо в сам выбор слов) Это подали как жест прозрачности: мол, вот вам транспарентность(как просили).

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

А неделю спустя независимое издание констатировало: доказать, что хоть один из них реально работает, не может никто (ни авторы ни сама Anthropic).

Эта статья – о том, почему это не баг и не провал маркетинга, а неизбежное следствие того, как устроена технология. И заодно — почему у истории куда более длинная борода, чем у чат-ботов: первые водяные знаки придумали за семьсот с лишним лет до GPT.

Если вы поставляете товар в крупную розницу, возите грузы для 3PL-оператора, шлёте платёжные извещения банку или обмениваетесь медицинскими транзакциями X12 — вы почти наверняка обмениваетесь этими документами по AS2. Заказ (EDI 850), счёт (810), уведомление об отгрузке (856), платёжное авизо (820) уходят партнёру не почтой и не через REST, а как подписанный и зашифрованный S/MIME-конверт поверх HTTP, с подписанной квиткой-распиской в ответ. Так работает регламентированный B2B-документооборот в рознице, логистике, финансах, производстве и здравоохранении уже двадцать лет: Walmart, Amazon и их сети поставщиков, банки с host-to-host каналом, автопром, дистрибьюторы — все требуют AS2.

В .NET до сих пор было два пути. Либо коммерческий AS2-шлюз — Cleo, Seeburger, BizTalk — отдельная коробка, отдельная лицензия, отдельная команда сопровождения. Либо Java-сервер с открытым кодом — OpenAS2, Mendelson Community — отдельный JVM-процесс рядом с вашим .NET-бэкендом, со своим inbox-каталогом, откуда документы надо ещё забирать джобой. В обоих случаях AS2 живёт сбоку от вашей интеграции, а не внутри неё.

redb.Route.AS2закрывает этот разрыв: AS2 становится обычным шагом маршрута в вашем .NET-процессе. Приняли конверт от партнёра, расшифровали, проверили подпись, отдали документ в pipeline — провалидировали, трансформировали, положили в Kafka или SQL — и вернули партнёру подписанную расписку. Один процесс, один деплой, одна панель наблюдаемости. Разберём, как это выглядит в коде, где применяется и почему нативный коннектор в ESB выигрывает у отдельного шлюза.

Увы, у меня нет профильного математического образования (я вообще гуманитарий), потому любой стандарт по криптографии для меня ничто иное, как поросячья латынь. А после детального изучения приходит горькое осознание, что это я лезу в калашный ряд со свиным рылом... И вот прилетела задача, решить которую промптом не получится (я пробовал, честно), а потому надо лезть в калашный ряд ISO9797-1 и смотреть, что там такое делается. Результаты изучения решил расписать здесь, т.к. может кому-то будет полезно, а может кто-то из crypto-лордов укажет на недочеты/ошибки.