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

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

В прошлой статье про трёхуровневый кэш сообщений я уже упоминал, что делаю мессенджер ONEMIX на React Native. Базовое E2E у меня было простое: ECDH P-256 для обмена ключами при первом контакте, AES‑GCM для шифрования каждого сообщения общим секретом. Это работает, но имеет одну проблему: общий секрет один на всю переписку. Если у одной из сторон скомпрометируют приватный ключ — все сообщения за всё время превращаются в открытый текст.

Это называется отсутствием Perfect Forward Secrecy (PFS). И это значит, что человек, к которому в руки попадёт твой телефон через год, может прочитать переписку из прошлого года. WhatsApp, Signal, и серьёзные части Telegram давно используют другую схему — Double Ratchet — которая ключи переизбретает заново на каждом сообщении. Так делают потому, что любой ключ компрометируется в один момент времени, и компрометация не должна давать доступа ни к прошлому, ни к будущему.

Я реализовал Double Ratchet с нуля для ONEMIX. В этой статье разберу:

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

Секрет в том, что Петцольд не верит в метафоры. Никаких «паровозиков, везущих нолики и единички», никаких «электронных мозгов».

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

Предлагаю в этой статье пойти дальше и рассмотреть оракул, способный найти прообраз (точнее, совокупность возможных прообразов) заданного хеш-кода конкретной хеш-функции. Поскольку хеш-функции часто используются в более сложных конструкциях, предлагаем посмотреть и порассуждать, как наличие такого оракула влияет на свойства вышележащих криптографических механизмов. В качестве их примера рассмотрим конструкции HMAC (Hash-based Message Authentication Codes – коды аутентификации сообщений на основе хеширования).

Асинхронная клиент-серверная библиотека для обмена сообщениями между микросервисами на базе ZeroMQ. Реализует гарантированную доставку сообщений (At-Least-Once) с персистентной файловой очередью при обрывах связи, автоматический failover сервера переадресации (клиенты могут подхватывать роль сервера на лету) и два уровня защиты: шифрование канала (CurveZMQ) и сквозное шифрование сообщений (HMAC). Лёгкая альтернатива брокерам вроде RabbitMQ, не требующая отдельного сервера.

Nonce Observatory: как превратить цифровые подписи в систему наблюдаемых nonce-инвариантов

Большинство историй про ECDSA/Schnorr nonce звучит одинаково: “повторили nonce — потеряли ключ”. Но реальные дефекты часто тоньше: короткие nonce, частичная утечка битов, смещение, recurrence, window-locality, prefix-семейства, ошибки в multi-signature контексте.

Мы собрали исследовательскую систему Nonce Observatory — не “кнопку взлома”, а forensic framework для анализа слабых nonce-структур в:

ECDSA • Schnorr/BIP340 • MuSig2/BIP327

Что внутри:

protocol-valid bridges affine hidden-nonce families HNP / lattice routes Q-LLL + fplll same-case checks AI sidecar на gpt-oss-20b-TurboQuant-MLX-8bit exact evidence / redaction / claim boundaries full-system audit

Главный принцип системы:

сигнал ≠ восстановление; кандидат ≠ приватный ключ; claim принимается только если d·G == public key.

В статье расскажу:

— что такое HNP и зачем он нужен для ECDSA; — как подписи превращаются в affine nonce geometry; — почему BIP340 и MuSig2 требуют protocol bridge; — как Q-LLL используется как lattice backend, а не “магический oracle”; — зачем нужен AI sidecar и почему AI не имеет права принимать d; — как мы дошли до full-range controlled HNP recovery без nonce brute force; — почему full-system audit важнее красивого demo.

Это статья не про “сломать Bitcoin”. Это статья про инженерную дисциплину в криптографической форензике: наблюдаемость, воспроизводимость, проверяемость и честные границы заявлений.

Мы привыкли воспринимать LLL-редукцию как «чёрный ящик»: подали целочисленный базис, получили редуцированный базис, проверили результат. Но что, если сделать процесс редукции наблюдаемым?

В статье рассказываю о Q-LLL — exact-certified алгоритме семейства LLL, где классическая корректность сохраняется, но выбор редукционных действий управляется квантизированной Gram/Lovász-геометрией.

Главная идея:

approximate geometry observes, exact arithmetic decides, certificate proves.

Q-LLL не заменяет fplll и не меняет Lovász-критерий. Вместо этого он добавляет новый слой: quantized Gram/Lovász oracle, exact gate, fair scheduler и proof-carrying certificates, которые можно независимо проверить.

В статье разбираю:

— почему обычного sequential LLL недостаточно для больших семейств lattice-вариантов; — что такое Lovász slack и как из него получается карта геометрических дефектов; — как работает quantized Gram/Lovász oracle; — почему approximate слой не принимает математических решений; — зачем нужны exact-сертификаты и independent verifier; — как Q-LLL становится lattice-core для nonce-observatory; — какие результаты уже получены и какие ограничения честно остаются.

Это не статья про «магическую кнопку» и не claim про универсальное превосходство над fplll. Это попытка показать новый взгляд на LLL: как на управляемый, наблюдаемый и проверяемый процесс, где квантизированная геометрия направляет редукцию, а exact-арифметика остаётся источником истины.

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

Более того, зашифрованное сообщение можно сделать похожим на обычный текст или даже скрыть в обычном контенте — видео, звуковых файлах и тексте, который не вызовет подозрений у «цензора». Это область стеганографии

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

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

Я Java-разработчик и в основном работаю с backend: Spring Boot, базы данных, интеграции, авторизация, WebSocket — всё то, что обычно находится за интерфейсом.

В какой-то момент я поймал себя на мысли: я каждый день пользуюсь мессенджерами, но плохо понимаю, как они устроены внутри. Окей, JWT, WebSocket, PostgreSQL, Redis — это понятно. Но что технически означает фраза “end-to-end encryption”? Как сервер доставляет сообщения, если он не должен их читать? Где живут ключи? Что хранится в базе? Что происходит, если у пользователя два устройства?

Решил разобраться через практику. Написал мессенджер с нуля. Назвал Chaos Messenger.

Сразу честно: криптографическую часть я изучал вместе с Claude и ChatGPT — читал спецификации X3DH и Double Ratchet, разбирал примеры, задавал вопросы, пока не сложилась цельная картина. Frontend тоже делался с активной помощью ChatGPT: я backend-разработчик, React для меня не основная среда. Но архитектура, backend, интеграция WebCrypto, модель конвертов, хранение сообщений и принципиальные решения — мои.

Для меня AI здесь был не заменой понимания, а инструментом — примерно как документация, Stack Overflow и ревью коллег. Без понимания threat model и архитектуры такой проект всё равно не собрать.

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

Стек: Spring Boot 3, React 18, WebCrypto API, PostgreSQL, Redis, WebSocket/STOMP, Prometheus, Grafana.

После того как я написал статью «Головоломка на 1000 BTC» мне стали писать в личку авторы программ для их решения. В этой статье я расскажу о целом семействе таких программ и протестирую все те, что попали мне в руки, на скорость.

В этом году меня стали посещать мысли о точке невозврата. Мы оказались там, где степень неопределённости настолько высокая, что мозг начинает выдавать обратное: всё понятно, всё под контролем, беспокоиться не о чём.

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

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

Пока весь интернет спорит об уязвимости блокчейна перед квантовыми компьютерами и ИИ, я наткнулся на новость в NYT о том, что у клиентки Fidelity внезапно исчез весь счёт. Все накопления. Просто пропали. Чудом удалось восстановить.

Помните, я говорил, что уверенность — это слабость? Вот оно. Банковские счета, брокерские счета, всё то, чем мы пользуемся последние 50 лет, априори считаются безопасными. Эта уверенность и есть главная уязвимость. Люди просто туда не смотрят. А банковское лобби делает всё, чтобы так и оставалось.

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

В марте 2026 году криптографы из Google Quantum AI опубликовали доказательство, что сверхпроводящий квантовый компьютер с 500 000 физических кубитов (это 1200 кубитов с коррекцией ошибок) способен взломать приватные ключи Bitcoin максимум за 9 минут (быстрее, чем 10-минутное время генерации новых блоков). Хотя опасность квантовых вычислений для традиционных шифров известна давно, ранее для этого предполагалась более серьёзная конфигурация, чем 500 тыс. кубитов.

Новое доказательство поднимает перед финансовой индустрией несколько вопросов. Самый главный — когда будут разработаны и поступят в продажу квантовые компьютеры на 500 тыс. кубитов, если сейчас у самого мощного около 150 кубитов?

Исследователи Google Quantum AI в техническом отчёте дают рекомендации по минимизации ущерба.

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

Я Ирина Слонкина из отдела безопасности распределенных систем, 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-ускоритель в разработке.