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

Привет, Хабр! Сегодня я расскажу, как пытался анализировать поведение AES-128-CBC на 500 000 выборках шифротекстов.

Добрый день! Сегодня расскажу, как с помощью 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-шифрование и режим работы в локальной сети без интернета вообще.

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

Это не проблема технологий. Это проблема архитектуры доверия: данные существуют, но им нельзя доверять — ни их сохранности, ни их подлинности, ни тому, кто к ним имел доступ.

Цена этой проблемы измеримa. Согласно отчёту IBM Cost of a Data Breach 2023, средняя стоимость утечки данных в здравоохранении составляет $10,93 млн — почти вдвое больше, чем в финансовом секторе ($5,9 млн) IBM Security, 2023. Но финансовые потери — лишь следствие. Причина глубже: базовая архитектура большинства медицинских информационных систем воспроизводит подходы 1990-х годов: централизованные реляционные базы данных, закрытые проприетарные форматы, точечная интеграция через HL7 или FHIR-адаптеры (HL7 FHIR — международный стандарт обмена медицинскими данными; FHIR, Fast Healthcare Interoperability Resources — его актуальная версия).

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

Утилита Easy-RSA изначально была создана в рамках проекта OpenVPN для упрощения управления ключами и сертификатами Инфраструктуры открытого ключа, использующимися для защиты передаваемой по сети информации. Данное упрощение, несомненно, позволяет сократить затраты времени на освоение развёртывания и сопровождения службы OpenVPN.

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

P.S. Адептам рунглиша с острой аллергической реакцией и когнитивным диссонансом к русскоязычным терминам и сокращениям просьба не беспокоиться.

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

И русские, и французы внедряли агентов в ряды противника, пускали дезинформацию, шифровали сами и перехватывали вражеские шифровки. Что уж там, правая рука и покровитель «черного кабинета» одного из воюющих императоров работал на противника и сливал ему бесценную информацию, а заодно и ключи от шифров. Словом, всё в лучших традициях романов Йена Флеминга и Юлиана Семенова.  

Под катом вас ждет увлекательный рассказ о том, как проходила информационная война между русскими и французами в 1812 году, как перехватывали шифровки и как это помогало войскам. Отдельное внимание уделим шифрам Наполеона.

Всем привет!

Первая статья была несколько дней назад. За это время я нашел два момента, которые захотелось проработать:

1.В переписке активно используются голосовые сообщения. Текущая версия их не обрабатывала.

2.100 000 итераций PBKDF2, которые использовались в первой версии, уже не соответствуют актуальным рекомендациям (OWASP рекомендует от 600 000 для SHA-256).

Для этого потребовалось расширить функциональность и усилить криптографическую стойкость.

Всем привет, я Олег Оболенский, технический директор одного из подразделений VK Tech. Время от времени я задаю себе вопрос: «А вот, находясь на месте ребят-программистов из моей команды, смог бы я так же, как они, или нет? Как сейчас, спустя 25 лет после того, как я вошел в профессию, выглядит программирование?»

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

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

Всем привет! Моя первая статья тут, просьба строго не судить :-)

Предыстория

Когда-то давным-давно, в прошлом десятилетии, я учился в одном техническом университете по специальности "информационная безопасность автоматизированных систем" и один из предметов, который меня заинтересовал, был криптография. В то время для меня это был какой-то вид магии, сверхспособность - возможность передавать информацию так, чтобы ее понял только тот, кому она предназначалась. Однако после учебы, столкнувшись на практике с данной областью ИБ, романтика ушла на второй план, и осталось практическое понимание необходимости использования криптографии для обмена "конфиденциальной" информацией. Там, на месте работы (одна большая государственная организация), где использовал криптографию в практическом аспекте, и познакомился со своим другом. Почти 9 лет прошло)

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

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

Всем привет!

Традиционное вступление в стиле "плач Ярославны": GlobalPlatform, ISO 7816, JavaCard и прочие смежные стандарты - боль. Тонна материала написанная сухим языком так и навивает мысль, что авторы этого всего не инженеры, а юристы. Для примера скажу, что каждый стандарт ETSI начинается со смысловых определений глаголов "shall", "shall not", "should", "should not" и т.д. Нет, в канцелярском стиле ничего плохого нет. Плохо становится когда он плавно переходит поросячью латынь - и это одно из самых терпимых определений. Это же додуматься надо "размазать" требования к несчастной SMS-ске между пятью стандартами (ETSI 102-223/-225/-226 и 131-111/-115).

Ну вот ты преодолел пучины стандартов, затем засел за написание JavaCard-апплета, с чем тоже успешно справился, ну а дальше начинается квест "найди все тулзы". Инструментарий от Oracle для сборки .cap-файлов недоступен из России, благо есть один удобный в открытом доступе. Там же рядышком лежит тулза для установки/удаления апплетов (да и вообще управления жизненным циклом карты).

Итак, ты скомпилировал и загрузил апплет на карту. Классно! А дальше? А дальше поговорим в статье.

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

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

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

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