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

В данной статье в качестве криптоанализа Биткоина разберём вычислительный научный эксперимент, воспроизводящий и расширяющий наблюдение John Zweng (2025) относительно точек-генераторов G семейства кривых Коблица SEC 2 — secp160k1, secp192k1, secp224k1 и secp256k1.

Обнаруженная закономерность: для всех кривых Кобица простого порядка семейства SEC 2 (secp160k1, secp192k1, secp224k1, secp256k1) точка, получаемая «делением» генератора G на 2 (умножением на обратный элемент 2 по модулю порядка подгруппы n), имеет x-координату аномально малой битовой длины и содержит общую 152‑битную гексадецимальную подстроку 8ce563f89a0ed9414f5aa28ad0d96d6795f9c6. Мы даём математическую формализацию операции, воспроизводим вычисления с помощью открытых скриптов на Python/SageMath, обсуждаем историческую непрозрачность стандарта SEC 2, а также — в отдельных разделах — протокольные следствия для Bitcoin, включая принципы NUMS-точек, аудит вторичных генераторов и безопасность ECDSA/Schnorr. Особое внимание уделяется практическим скриптам для Google Colab, которые позволяют каждому исследователю независимо верифицировать находку.

Johannes Zweng известный в GitHub в своём архиве прямо ссылается на выступление криптографа Nadia Heninger, посвящённое открытым вопросам происхождения стандартных кривых, как на дополнительный источник контекста для данной аномалии. Хенингер является одним из ведущих специалистов по практическому криптоанализу реализаций ECC/RSA (в частности, известна работами по атакам на слабую случайность при генерации ключей), и её внимание к теме подчёркивает значимость подобных архивных находок для сообщества академической криптографии.

23 июля Прабханджан Анант (Калифорнийский университет в Санта-Барбаре) и Амит Сахаи (UCLA) выложили на arXiv статью "Unconditional Unclonable Encryption", которая закрывает проблему, стоявшую перед квантовыми криптографами шесть лет. Но не меньше самого результата обсуждают короткий раздел в конце введения: конструкция и основные идеи доказательства были целиком сгенерированы агентом Codex на модели GPT-5.6 Sol Ultra.

Свой open source ИИ-ассистент.

Ассистент

- который помнит вас между разговорами

- ищет по вашим документам и по вебу

- умеет планировать

- работать с фото.

В статье - что появилось с прошлого раза:

- вайб-темы интерфейса, которые LLM генерит под ваш вкус;

- внешний RAG по файлам вашего ПК с шифрованием;

- агентный веб-поиск на SearXNG;

- «объектив», разбирающий фото в контексте тематических помощников.

Бэкенд на Go, фронт на Vue, база на PostgreSQL с pgvector. Работает на локальной Ollama или любом cloud-провайдере. Лицензия AGPL-3.0.

В этой статье разговор пойдет о приложении на Java Card, бегающем на смарт-картах. На хабре уже есть несколько публикаций на эту тему, в своей же я бы хотел немного выйти за рамки стандартного “Hello World”. Здесь вы узнаете как собирать апплет, увидите пример размещения данных в апплет на этапе инсталляции, а также установим защищенный канал между Хостом и картой.

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

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

Эта статья про один баг совместимости, который меня озадачил. Обе стороны честно объявляют версию протокола «dap-18», а байты на проводе не сходятся. Это не туториал по крипте и не показ репозитория - история про то, что строка версии - это не контракт совместимости, и про то, как это чинить, когда наткнулся.

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

Недавно я начал публиковать серию задач с шифрами на кубике Рубика. Первая задача про главный вопрос жизни Вселенной и всего такого была довольно легкой - разминочной. Сегодня публикую более сложную задачу, для решение которой мне потребовалось около трех часов. Берите в руки карандаш, блокнот и кубик Рубика. Жду ваших решений в комментариях. Через пару недель опубликую правильный ответ.

Системы контроля доступа (СКУД) встречают нас в жизни на каждом шагу: в офисах, домах, транспорте и почти в любой сфере ежедневного применения. За последние десятилетия СКУД прошли большой путь эволюции. В данной статье мы не очень глубоко разберём некоторые важные аспекты реализации СКУД c использованием OSDP Crypto.

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

Мы делаем proxykey — credential proxy: настоящие API-ключи лежат у нас зашифрованными, а приложения и ИИ-агенты ходят с отзываемыми виртуальными токенами. Недавно мы писали здесь про саму схему. Под ней и в личках всплыл один и тот же вопрос — самый правильный вопрос к любому такому сервису:

«А вы сами можете прочитать мои ключи?»

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

Добавлял в свою читалку офлайн-словари и упёрся в MDX, формат словарей MDict. Проприетарный, официальной спеки от создателей нет. Готовые Java-парсеры под GPL, а у меня закрытое приложение, тащить нельзя. Значит, пишу свой, с нуля и без зависимостей. Рассказываю, как формат устроен внутри, где я споткнулся, и почему пришлось руками писать RIPEMD-128, чтобы прочитать даже оглавление словаря.

Хочу рассказать про недавний кейс из своей практики и своих трудовых будней.
Заказчик пришёл с задачей: «Хочу QR-код на сертификатах, чтобы можно было проверить подлинность». У него в голове это выглядело так: он дает мне гугл таблицу с перечнем фамилий, датой, и номером сертификата, скрипт генерирует QR единый для всех сертификатов и как бы этот вопрос закрывается по его мнению. Но при этом должна закрываться самая главная боль - защита от подделки путем переноса QR на другой сертификат. Фактически получалась фикция. С моими возражениями заказчик согласился и я расскажу как мы пришли к криптографическому решению без бэкенда, и покажу конкретный код.

Мы даём кодовым агентам полный доступ к машине: файлы, шелл, git. Значит, сам бинарник должен быть предсказуемым, без сюрпризов. У Claude Code сюрприз есть: он незаметно помечает часть запросов. Судя по логике, цель одна — вычислить тех, кто гоняет Claude, чтобы обучать на его ответах свою модель. Это называется дистилляцией, и для любой AI-компании это прямая кража.

С чего все началось

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

Думал, это вечер работы. requests.get(), выдрать цену, сравнить, отправить в телегу (упрощенно, конечно).

Оказалось, парсинг цен на маркетплейсах — это не про HTTP‑запрос. Это про репутацию IP‑адресов, про то, как браузер выдает себя поведением, и — на финале — про пост‑квантовую криптографию в TLS‑рукопожатии. Три площадки (Ozon, WB, Яндекс.Маркет) дали мне три совершенно разных уровня защиты, и на каждом я застревал по‑своему.

Привет! Задача возникла банальная: нужно передать коллеге пароль, API-ключ или конфиг. Телега — не хочется, почта — тем более. Существующие решения от OneTimeSecret до PasswordPusher и прочих — либо закрытый код и доверяй на слово, либо требуют своего сервера. Одни требуют регистрации, другие — напичканные всем подряд комбайны. Захотелось сделать так: открытый код, шифрование в браузере, сервер физически не может прочитать содержимое и, разумеется, бесплатно.

Так появился BurnAfterRead — self-destructing E2E encrypted drops на Cloudflare Workers.

Представьте, что ваш зашифрованный трафик злоумышленники записывают прямо сейчас. На первый взгляд, это бессмысленно: расшифровать его классическими методами невозможно. Однако существует стратегия «собери сейчас, расшифруй потом» (Harvest Now, Decrypt Later). Суть такого подхода заключается в накоплении зашифрованных данных сегодня, чтобы взломать их завтра, когда появится достаточно мощный квантовый компьютер, называемый в литературе криптографически-значимым квантовым компьютером (Cryptographically Relevant Quantum Computer – CRQC). По нейтральным оценкам крупных международных корпораций, он может появиться через 5–10 лет. С другой стороны, некоторые криптографы считают, что у спецслужб криптографически значимые квантовые компьютеры появятся к 2029 году, а для широкого пользования – примерно к 2032. Для госсектора и крупного бизнеса, где информация требует защиты десятилетиями, это критическая угроза.

Значительная часть такого трафика передается по защищенным каналам на базе набора протоколов IPsec. Его ключевой компонент – протокол IKEv2, отвечающий за согласование ключей и алгоритмов. Изначально он не был рассчитан на использование постквантовых алгоритмов: большие размеры ключей и подписей создавали эксплуатационные сложности. Однако благодаря техническим расширениям IKEv2 теперь поддерживает гибридный режим – одновременное использование классического протокола Диффи–Хеллмана (он позволяет двум сторонам выработать общий секретный ключ по открытому каналу связи) и постквантовых алгоритмов.

TLS 1.3 с прямой секретностью - это правильный выбор. Если завтра скомпрометируют серверный ключ - прошлые сессии не расшифруются. Эфемерные ключи уничтожены. Все продумано.

Проблема в том, что это защита от одного сценария. Не от того, о котором идет речь.

Привет, Хабр! Меня зовут Максим Теплых, эксперт по тестированию на проникновение в ИТ-компании Innostage. В этой статье я хочу рассмотреть тему, которая с годами становится все более актуальной — тестирование систем, использующих ГОСТ TLS. Кратко расскажу о самой технологии, а также покажу подходы и наработки, которые применяем на практике. 

Заранее приношу извинения за объемное и несколько затянутое введение. Хотя изложение начинается не с динозавров и не с истории древней Руси, тему все же необходимо раскрыть с некоторой предыстории.