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

Надвигающаяся угроза со стороны заточенных на криптографию квантовых компьютеров заставила срочно менять действующие примитивы асимметричной криптографии — обмен ключами (ECDH) и цифровые подписи (RSA, ECDSA, EdDSA) — которые уязвимы для квантового алгоритма Шора. Однако существующих симметричных методов криптографии (AES, SHA-2, SHA-3) или уровней их стойкости это не коснулось. ccc

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

AES-128, как и SHA-256, обеспечивает достаточную защиту от атак с применением квантовых компьютеров. В рамках перехода в постквантовую эпоху размер симметричных ключей изменять не требуется. Это почти единогласное мнение среди профильных экспертов и органов стандартизации, которое нужно распространить среди остальной части IT-сообщества. И дальше в статье я подкреплю это утверждение техническими аргументами со ссылками на авторитетные источники.

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

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

1. Фундамент: сервер, который мало что знает

Сначала коротко про основание, иначе дальше будет непонятно.

- Идентификатор это UIN, просто число. Никакого номера телефона, никакой загрузки списка контактов. Аккаунт не привязан к личности, его можно сжечь и завести новый за секунды.

- Sealed sender: отправитель запечатан внутри зашифрованного конверта, а не лежит в заголовке. На транспортном уровне сервер видит "кому доставить", но не "от кого". Кто это понимает, тот сразу видит, что граф общения на сервере не собирается.

- Контент шифруется end-to-end: эфемерный X25519 на сообщение, HKDF, ChaCha20-Poly1305. Сервер пересылает шифротекст, ключей у него нет.

Идея простая: сервер это в основном тупая труба для шифротекста. Нет телефонов, нет графа, нет содержимого. Это важно для всего дальнейшего.

2. Острова: свой сервер вместо нашего

Раз сервер это тупая труба, его можно вынести куда угодно. Любая организация (редакция, юрфирма, команда, НКО) поднимает свой экземпляр RCQ, свой остров, и общается внутри него: свой сервер, свои UIN, своя история, свои группы, отдельно от публичной сети.

Как организовать шифрование на уровне протокола? На самом деле тема непростая и пожалуй (имхо) это как раз та самая тема, где прийти к компромиссу почти никогда не получается. Разве что просто не передавать чувствительные данные вовсе.

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

Я пилю VantageDNS — рекурсивный DNS-резолвер с фильтрацией. NextDNS-clone, если коротко: юзер настраивает роутер на наш DoH endpoint, а мы рекурсивно резолвим и заодно режем рекламу, трекеры и malware.

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

В этой статье конкретика: что edge-нода не пишет на диск, как устроен кольцевой буфер для query log, что делать с crash dumps, и как юзер может проверить, что мы не врём, через strace.

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

Древние греки и римляне изобрели почти всё — от демократии до акведуков и… стеганографии, о чем шла речь в предыдущей публикации. С закатом же античности в значительной части мира наступил упадок культуры и технологий. Однако стеганографический «олимпийский огонь» не погас, а лишь временно поблек: вскоре его подхватили и разожгли с новой силой на Ближнем Востоке и в Европе. Некоторые методики тайнописи Средних веков и Ренессанса опередили свое время и даже создали отложенную предпосылку к появлению компьютеров и переходу в цифровую эпоху.

В блог Бастиона снова заглянула старший научный сотрудник Московского музей криптографии, кандидат исторических наук Анастасия Ашаева. В прошлой статье эксперт рассказала о стеганографических методиках и контейнерах античности. На этот раз поговорим о тайнописи Средневековья и эпохи Возрождения. Итак, поехали.

С момента (раз, два, три) публикаций о бесплатной свободно распространяемой многофункциональной утилите Easy Disk Checker вышел major update 5.* в котором по итогам голосования на "Хабре" появилась и развивается новая ветка “Восстановления данных”, где я, как практикующий с 2003 года дата-рекавери специалист, постарался реализовать функции которые могут помочь как обычным пользователям, так и мне, в моей ежедневной профессиональной деятельности.

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

Первого мая на Engineering at Meta вышел пост «How Meta Is Strengthening End-to-End Encrypted Backups». Одиннадцатого мая продолжение про Labyrinth 1.1, реализацию для Android. Я прочитал оба, потом полез в whitepaper, потом сравнил с тем что делаю у себя, и решил написать разбор. Не пересказ маркетингового материала, а нормальный технический разбор. Что они сделали, почему именно так, где у меня болело по дороге, какие компромиссы они выбрали, какие выбрал я.

Сразу важная оговорка про что эта статья. Она не про шифрование сообщений в транзите. Signal Protocol, Double Ratchet, X3DH — всё это давно стандарт, все нормальные мессенджеры это используют. WhatsApp лицензировал Signal Protocol ещё в 2016-м. Транзит решённая задача.

Эта статья про следующее звено цепи, которое для большинства пользователей до сих пор сломано. Про бэкапы.

Безопасность данных сегодня стала главным приоритетом для любого веб-ресурса. Базовым стандартом защиты учетных записей является хеширование паролей. Этот процесс превращает конфиденциальные символы в необратимый код. Без него утечка базы данных мгновенно скомпрометирует пользователей.

Однако обычного хеширования недостаточно из-за угрозы быстрых хакерских атак. Для защиты разработчики применяют «соль» (salt) — случайные данные, добавляемые к паролю. Минус соли в том, что она хранится рядом с хешем и не спасает от мощного перебора. Тогда на помощь приходит «перец» (pepper), скрытый в коде сервера. Его главная проблема — высокий риск потерять доступ ко всем аккаунтам при компрометации самого секретного ключа.

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

Долгое время, схемы выработки ЭЦП, для которых была доказана безопасность в схеме ROM считались надёжными, однако всё изменилось после публикации атаки ROS, о которой мы поговорим позже. В основе этой атаки лежит принцип параллельного выполнения, при котором противник может получить преимущество в подделке подписи, открывая множество сеансов параллельно.

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

В блог Бастиона снова заглянула кандидат исторических наук, старший научный сотрудник Московского музея криптографии Анастасия Ашаева. Она рассказала о том, какой путь прошла стеганография с древнейших времен до современности, какие стегоконтейнеры использовались в разные исторические эпохи. Отдельное внимание эксперт уделила конкретным кейсам применения стегоконтейнеров. Передаем ей слово.

12 мая 2017 года мир столкнулся с беспрецедентной киберкатастрофой. Больницы разворачивали машины скорой помощи прямо на ходу, вставали конвейеры автозаводов, парализовало серверы банков и министерств в 150 странах. На экранах сотен тысяч компьютеров загорелось агрессивное красное окно шифровальщика WannaCry с тикающим таймером.

Но самое поразительное в этой истории — не масштаб ущерба, оцениваемый в миллиарды долларов. Самое поразительное то, что этот цифровой «франкенштейн» был собран из утекшего в сеть секретного кибероружия АНБ США, а остановил его 22-летний аналитик-самоучка с темным прошлым, просто зарегистрировав бессмысленный домен за 10 баксов.

Это вторая часть цикла про mTLS. В первой разобрали теорию: как работает рукопожатие, от каких атак защищает и где принципиально бессилен. Здесь — практика. Разберём реальный сценарий: homelab на одном сервере с Traefik и Dokploy. Пройдём путь от модели угроз до конкретных попыток атаковать собственный сервер — с командами и объяснениями, что происходит.

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

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

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

Если вы когда-нибудь выкатывали фичу, которая хранит персональные данные - почтовые адреса, заметки в свободной форме, API-токены, идентификационные номера - у вас наверняка возникала та же неприятная мысль: врядли стоит доверять базе данных. Бэкапы копируются на ноутбуки. Снапшоты оседают на файловых ресурсах. Галочка “encryption at rest” в облачной консоли защищает только от одного конкретного вида кражи - от того, что кто-то унесет диск.

Зашифровать данные до того, как они попадут в базу, на слайде звучит просто - AES, ключ, готово. В реальном коде простая версия ломается ровно в тот момент, когда вы пытаетесь ротировать ключ, найти запись по email, или объяснить ревьюверу, каким именно ключом зашифрована конкретная строка.

Разработанный в компании «Криптонит» (входит в «ИКС Холдинг») алгоритм S3G-5G прошёл новый этап согласования: Технический комитет 26 (ТК 26) по стандартизации «Криптографическая защита информации» утвердил методические рекомендации по его применению. Алгоритм представляет собой российский аналог криптографических функций 3GPP (f1–f5), предназначенных для выработки вспомогательных секретных ключей и аутентификационных векторов в сетях подвижной радиотелефонной связи пятого поколения (5G). Его внедрение позволит значительно повысить безопасность абонентов.

Методические рекомендации S3G-5G — это усовершенствованная и специализированная для сетей 5G версия ранее принятых рекомендаций S3G-256 (Р1323565.1.003-2024). Ключевое отличие заключается в добавлении случайности со стороны устройства абонента (UE — User Equipment), что делает невозможными атаки повторного воспроизведения (replay attack). В отсутствие такой защиты злоумышленник может легко отследить факт аутентификации и перемещения пользователя, выяснить, где и когда он бывает, и получить возможность для целенаправленных атак. Таким образом, основная функция нового алгоритма — надёжная защита от отслеживания местоположения абонентов.

Не так давно я публиковал на Хабре обзорную статью о применении кубика Рубика в криптографии, где приводил интересный кейс с крипто-челленджем Клауса Шмеха. Потом мне стали попадаться еще интересные задачи с зашифрованными посланиями на кубике Рубика, как, например, случай на Reddit, где пользователь просил сообщество помочь расшифровать сообщение, которое ему оставила девушка на кубике Рубика. На олимпиадах по криптографии, как выяснилось, тоже периодически появляются задачки с шифрами на кубике Рубика. Всё это привело меня к мысли, что шифрование на кубике Рубика может быть весьма интересным занятными. И я решил поэкспериментировать с "рубошифрованием". В этой статье приведу первую (простую) задачку, на решение которой мне понадобилось около часа. Жду ваших решений в комментариях. А правильный ответ и собственное решение опубликую через пару недель.

AI, которому запрещено быть правым

Когда AI подключают к криптографической системе, обычно задают вопрос: может ли модель найти правильный ответ? Но в криптографии это неправильный вопрос. Правильный вопрос другой: можно ли встроить AI так, чтобы даже при ошибке он не мог принять опасное решение? В этой статье я показываю, как мы реализовали в nonce-observatory отдельный слой governed solver orchestration — архитектуру, в которой AI может:

анализировать public-safe feature contract;

предлагать solver routes;

строить очередь запусков;

помогать с triage и объяснением маршрутов;

но не может:

видеть truth/private/nonce поля;

принимать candidate_d;

принимать k;

формировать recovery claim;

превращать свой score в криптографическое evidence.

Иными словами:

AI suggests. Exact verifier decides. Разбираю, почему для high-assurance систем важен не “умный AI”, а AI без authority, как устроена граница non-escalation, где проходит deterministic integrity gate, и почему в зрелой криптографической системе модель должна оставаться только планировщиком, а не источником истины.

Внутри статьи:

ECDSA / Schnorr / BIP340 контекст;

governed solver orchestration;

non-escalation boundary;

safe payload и forbidden fields;

solver queue vs cryptographic evidence;

deterministic verifier;

clean-control refusal;

claim boundary: что мы не утверждаем.

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

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