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

Привет, Хабр!

Я Ирина Слонкина из отдела безопасности распределенных систем, Positive Technologies. Вместе с коллегами исследую безопасность смарт-контрактов и блокчейн-приложений. Конечно, всегда интересно вникнуть вглубь каждой технологии, вышедшей на рынок. В этой статье я расскажу про криптографический протокол PLONK, один из самых интересных протоколов в блокчейн-индустрии.

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

В статье рассматриваются избранные места SHA-3 стандарта, относящиеся к анатомии кечак-функции (KECCAK) и, частично, к структуре губчатой функции (sponge function). Не затрагиваются многие другие части стандарта, в частности, описывающие функции с расширенным выходом SHAKE, RawSHAKE.

Стандарт FIPSPUB 202 определяет Secure Hash Algorithm-3 (SHA-3) как семейство функций, оперирующих бинарными данными. Каждая из функций основана на кечак-алгоритме (KECCAK algorithm). Семейство включает четыре криптографические хэш-функции SHA3-224, SHA3-256, SHA3-384, SHA3-512 и две функции с расширенным выходом (extendable-output function, XOF) – SHAKE128 и SHAKE256.

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

От криптоанализа к AI-forensics

Мы привыкли считать LLM «чёрным ящиком»: дал промпт — получил ответ. Максимум — подкрутил fine-tuning или LoRA и надеешься, что стало лучше. Мы пошли в другую сторону. В предыдущей статье я показал, что подписи Schnorr / MuSig2 можно разобрать до уровня строгих affine-инвариантов и работать с ними как с математической системой, а не как с магией. В этой работе мы сделали следующий шаг: перенесли ту же exact-методологию внутрь нейросети.

Что мы сделали? Мы взяли локальный MLX-дистрибутив:

gpt-oss-20b-TurboQuant-MLX-8bit

и не стали его «обучать заново». Вместо этого: вскрыли .safetensors на уровне квантованных кодов; построили детерминированный calibration cache; начали снимать реальные BF16-активации с конкретных слоёв; свели задачу к локальной integer-оптимизации квантованных весов; реализовали безопасный patch прямо в модель; и добавили smoke-check, который проверяет: совпадает ли наша математика с реальным runtime MLX.

Что получилось

Мы впервые получили pipeline, в котором: квантованный слой наблюдаем; его поведение измеримо; его можно локально корректировать; и самое важное - можно проверить, не обманывает ли нас сама среда исполнения. Например: для router.weight мы получили почти полный перенос улучшения на holdout; для q_proj система честно доказала: без внешнего эталона patch не имеет смысла. И это, возможно, даже важнее.

Привет Хабр! Меня зовут Артур Валиев, и я разработчик небольшого мобильного приложения с названием «Echo Layer».

Меня давно не отпускала одна мысль: почти все разговоры о приватной переписке в какой‑то момент упираются не в шифрование, не в криптографию, не в архитектуру, а в банальную человеческую инерцию. Можно сколько угодно строить красивую систему, можно делать open source, end‑to‑end encryption, писать про zero knowledge и отсутствие серверных логов, но потом ты возвращаешься в реальную жизнь и видишь, что люди всё равно сидят там, где им удобно. В Telegram, в WhatsApp, в VK, сейчас уже и MAX, в корпоративных чатах, в почте, в комментариях, где угодно. И если для приватности нужно сначала всех пересадить в новое приложение, то задача почти обречена.

Именно в этот момент у меня и сместился фокус. Я перестал думать о мессенджере как о конечном продукте. Мне стало интереснее другое: а можно ли не строить новый канал связи, а встроить приватный слой поверх уже существующих каналов? Не просить человека менять привычки, не ломать его сценарий общения, не заставлять его уговаривать собеседника «перейти вот сюда», а аккуратно встать между пользователем и текстом. Потому что, если честно, в большинстве случаев мессенджер — это просто оболочка. Внутри всё равно есть текст, который пользователь написал, и текст, который приложение потом отправило. Значит, если контролировать текст до отправки, можно контролировать довольно много.

Так Echo Layer и появился. Не как «новый безопасный чат», а как попытка превратить сам ввод текста в место, где может жить приватность.

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

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

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

В этой статье расскажу, как мы подружили банк с ФЦИИТ, с какими трудностями столкнулись и что из этого вышло.

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

Можно ли смотреть на подпись Schnorr и MuSig2 не как на «чёрный ящик», а как на математическую систему наблюдаемых структур? В статье разбирается строгий BIP340 membership bridge, affine-представление скрытых нонсов, compression/connectivity-метрики и protocol-valid affine-линеаризация MuSig2 partial signatures. Без сенсаций и без заявлений о «магическом взломе» — только формальная модель, подтверждённые артефакты и аккуратный разбор того, что действительно доказано на практике.

Защита конфиденциальных данных — одна из главных проблем при работе с LLM. Главное, чтобы облачный «вычислительный движок» выполнял работу только над зашифрованными данными, не имея доступ к открытой информации. В качестве решения проблемы предлагается полностью гомоморфное шифрование запросов (FHE). Оно позволяет организовать полностью зашифрованный канал между двумя пользователями (E2E) с сервером посредине между ними.

Проблема только в том, что зашифрованные вычисления FHE в десятки тысяч раз медленнее обычных, а размер шифротекста FHE в десятки раз больше оригинала.

На Международной конференции по твердотельным схемам IEEE (ISSCC) в Сан-Франциско компания Intel представила прототип чипа Heracles, ускоряющий вычисления FHE до 5000 раз по сравнению с лучшими серверными CPU. И это не единственный FHE-ускоритель в разработке.

Только недавно Reuters раскрыли личность Бэнкси, как парни из New York Times спешат сорвать покровы с легендарного создателя биткоина (вот здесь архивная версия лонгрида без пэйволла). Кратко пересказываю здесь основные аргументы расследования.

Моё мнение о срочности внедрения квантово-устойчивой криптографии изменилось всего за несколько месяцев. Настало время рассказать о причинах этого.

Уже давно ходили слухи об ожидаемом и неожиданном прогрессе в области криптографически-релевантных квантовых компьютеров (CRQC), но за последние недели мы получили два публичных примера.

Во-первых, Google опубликовала статью, в которой существенно снизила ожидаемое количество кубитов и вентилей, требуемых для взлома 256-битных эллиптических кривых наподобие NIST P-256 и secp256k1, из-за чего в архитектурах с высокими тактовыми частотами (например, в кубитах со сверхпроводимостью) реализация атаки становится возможной за считанные минуты. Авторы странным образом¹ делают упор только на криптовалюты и пулы памяти, но гораздо более важными последствиями могут стать практические MitM-атаки на WebPKI.

Вскоре после этого была опубликована статья Oratomic, демонстрирующая, что благодаря улучшению коррекции ошибок 256-битные эллиптические кривые можно взломать с помощью всего лишь 10000 физических кубитов (при условии наличия нелокальной связи, которую, похоже, обеспечивают нейтральные атомы). Такая атака была бы медленнее, но даже взлом одного ключа в месяц может привести к катастрофическим последствиям.

Новый пост-квантовый гибридный алгоритм шифрования для высоко-нагруженных систем с реализацией на TypeScript. Ring-LWE, работа с ключами с использованием MAC и SHAKE-256, защита от основных видов атак и другие мысли в реализации протокола QuarkDash.

Добрый день! Сегодня расскажу, как с помощью PHP создать генератор случайных байт ( чисел ) с помощью 12 таймеров. Энтропия данного генератора составляет примерно 7.1 бит на символ ( у меня ), но на более мощном железе может подняться до 7.9–8, что по идее неотличимо от истинной случайности. Вот, как работает весь «конвейер»:

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

Мы привыкли, что повтор r в ECDSA — это случайный сбой: плохой генератор, ошибка реализации, повтор nonce. Но что, если за одним repeated-r скрывается целое семейство дефектов (defect-family), которое можно не только обнаружить, но и перенести на другие закрытые ключи?

Представляем закрытую исследовательскую систему — стратификационный анализ ECDSA-подписей на secp256k1. Вместо точечных аномалий мы смотрим на фазовые корпуса подписей, используем торическую геометрию, kNN и перестановочные тесты. Результат:

· Во внешнем корпусе из 30 адресных контекстов и 6257 подписей repeated-r найден только в 1 контексте, межадресных коллизий r — 0. · 58 из 58 контролируемых переносов defect-family с реального адреса-донора на панель реальных адресных целей прошли с полной ECDSA-валидацией реконструированных подписей. · Встроенный publication-safety audit заблокировал открытый bundle, обнаружив 498 проблем (30 критических) — от raw (r,s,z) до восстановленных синтетических k и фрагментов закрытых ключей.

В публичной версии отчёта — только математика, агрегаты и безопасные листинги. Никаких инструкций по эксплуатации. Это продолжение методологии AuditCore, но уже на уровне стратифицированного анализа.

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

30 марта 2026 года Google Quantum AI опубликовал статью, которая сильно меняет эту картину.
Команда Google Quantum AI выпустила 57-страничный whitepaper под названием «Securing Elliptic Curve Cryptocurrencies against Quantum Vulnerabilities». Среди авторов Ryan Babbush (директор исследований квантовых алгоритмов Google), Craig Gidney (автор ключевых оценок по RSA-2048), Hartmut Neven (VP Engineering Google Quantum AI). А также Justin Drake из Ethereum Foundation и Dan Boneh из Стэнфорда. По сути это те, кто строит квантовое железо и те, кто строит блокчейн. вместе.

Что они сделали
Они оптимизировали алгоритм Шора конкретно под задачу взлома 256-битных эллиптических кривых secp256k1. Это та самая криптография, на которой держится безопасность Bitcoin, Ethereum и большинства других блокчейнов.

Результат
Для взлома теперь нужно менее 1 200 логических кубитов и 90 миллионов вентилей Тоффоли. В пересчёте на реальное железо это менее 500 000 физических кубитов. Предыдущая лучшая оценка (Litinski, 2023) требовала около 9 миллионов. То есть порог снизился примерно в 20 раз.

И самое важное. Вычисление занимает минуты. Меньше, чем время одного блока Bitcoin.

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

Рассмотрим классическую задачу криптографии

Алиса отправляет шифрсообщение Бобу с использованием публично известного алгоритма шифрования и ключа известного Бобу

Эвил перехватила шифрсообщение и хочет прочитать его содержимое

Как квантовые вычисления помогут Эвил с её задачей?

В августе 2019 года, за несколько недель до выборов в Московскую городскую думу, Пьерик Годри из исследовательского института INRIA опубликовал результаты анализа кода московской системы дистанционного электронного голосования. Вывод был однозначным: параметры шифрования слабы настолько, что расшифровать голоса избирателей в режиме реального времени можно было за двадцать минут на стандартном ноутбуке с помощью общедоступного программного обеспечения Gaudry, Golovnev, 2019. Не взломал — математически решил задачу, которую разработчики системы, судя по всему, считали нерешаемой за разумное время. Ключ шифрования был построен на 256-битных параметрах ElGamal: при таком размере задача дискретного логарифма решается за минуты на обычном ноутбуке.

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

Всё началось с простой задачи: нужно было безопасно передавать файлы на обычных USB-флешках. Существующие решения либо создавали контейнеры (VeraCrypt), что неудобно для быстрого доступа к отдельным файлам на разных ОС, либо работали слишком сложно для конечного пользователя.

Мне нужно было решение уровня «вставил флешку -> ввел пароль -> файлы зашифрованы». Но главное требование — безопасность данных даже при сбое питания. Если выдернуть флешку посередине шифрования, данные не должны превратиться в кашу.

Так появился crypto_engine. Это не попытка изобрести свою криптографию (мы используем стандартные AES-GCM и ChaCha20), а инженерная работа над тем, как безопасно управлять ключами в памяти, обрабатывать гигабайтные файлы без переполнения RAM и гарантировать целостность данных.

С 24 по 27 марта в Подмосковье проходит ежегодная международная конференция «РусКрипто’2026», отражающая развитие криптографии и информационной безопасности. В этом году многие участники затрагивали вопросы цифрового суверенитета и построения доверенной цифровой среды. Особый интерес вызвал доклад сотрудников лаборатории криптографии компании «Криптонит» Анастасии Чичаевой и Степана Давыдова, посвящённый защите от взлома на специализированном «железе». 

В своём выступлении Анастасия Чичаева рассказала о современных подходах к построению и анализу так называемых memory-hard functions (MHF) — криптографических функций, требовательных к объёму памяти. Они становятся эффективным противодействием использованию специализированных вычислителей для перебора паролей и вырабатываемых из них ключей. 

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

Memory-hard функции как раз устроены так, что для их вычисления требуется значительный объём памяти, поэтому их применение делает массовый перебор паролей на специализированных вычислителях экономически невыгодным, а это – универсальная стратегия защиты. 

Мысль написать свой мессенджер у меня возникла ещё этак в прошлом году, почти четыре месяца назад. Тогда ещё трава была зеленее и Telegram нормально функционировал, без замедления и финального блокирования. Из-за работы, других проектов и в конце-концов лени я откладывал написание мессенджера до лучших худших времён. И вот такие времена настали, телеграм был полностью заблокирован и без использования VPN до него уже нормально не достучаться. С полыхающей пятой точкой и мотивацией Вергилия я решил наконец-таки начать писать мессенджер, который в результате был создан за неделю.

Когда смотришь на существующие self-hosted мессенджеры, часто видишь одно из двух: либо сложную инфраструктуру, которую непросто развернуть (Matrix/Synapse), либо минимализм без шифрования. ONYX — это попытка найти середину: простой в развёртывании сервер, полноценное E2E-шифрование и режим работы в локальной сети без интернета вообще.