Заметки Lizard'а

The ECB Penguin

2026-05-30T16:20:02.832Z

Суть такова

Данное изображение стало культовым в криптографическом и InfoSec сообществе. Речь идёт о картинке маскота Linux - пингвине Tux, которую зашифровали с помощью блочного шифра в ECB режиме ("Режим простой замены" в терминологии ГОСТ), однако контуры оригинального изображения остались видны. История этого изображения описана в статье Filippo Valsorda, в данной же статье будут результаты моего повторения данного эксперимента, но с разными блочными шифрами

Эксперимент

Для начала эксперимента нам понадобится изображение маскота, но поскольку оригинальное изображение с Википедии очень низкого разрешения, то я решил использовать картинку, найденную на просторах интернета, с разрешением 823x823.

Исходное изображение

Теперь определимся с шифрами:

AES
BelT - белорусский стандарт шифрования (описан в СТБ 34.101.31)
DES
Калина - украинский стандарт шифрования (описан в ДСТУ 7624:2014)
Кузнечик - российский стандарт шифрования (описан в ГОСТ Р 34.12-2015)
Магма - российский и советский стандарт шифрования (описан в ГОСТ Р 34.12-2015, а также ГОСТ 28147-89)
SM4 - китайский стандарт шифрования (описан GB/T 32907-2016)

А также определим дополнительные условия:

Ключ - 00112233445566778899AABBCCDDEEFF , при необходимости уменьшается или расширяется дублированием до нужной длины блока
Padding - Заполнение нулями, пока буфер не будет кратен длине блока (это условие ECB)

Теперь необходимо перевести изображение из PNG в PPM (Формат представляет из себя ASCII заголовок и последовательность из трёхбайтовых RGB пикселей), сделано это было с помощью ImageMagick (с помощью команды convert)

Далее с помощью hex-редактора отделяем ASCII заголовок от самого изображения и сохраняем обе части по отдельности:

Файл .ppm в hex-редакторе

Далее порядок действий таков:

Шифруем изображение с помощью одного из алгоритмов
Присоединяем заголовок к шифрованному изображению
Переводим PPM в PNG

Результаты

В результате "прогона" изображения через все алгоритмы я получил, следующие изображения:

AES:

BelT:

DES:

Калина:

Кузнечик:

Магма:

SM4:

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

Побег из КриптоПро (ч.4, final?)

2026-05-06T12:46:14.864Z

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

Важно: не следует путать понятие неэкспортируемости и неизвлекаемости. Неэкспортируемый контейнер - контейнер, на который наложено софтовое ограничение на экспорт, т.е если программа проигнорирует этот флаг, то она сможет произвести экспорт. Понятие неизвлекаемости относится к токенам с механизмом ФКН (Функциональный ключевой носитель, аля PKCS#11), где сам ключ генерируется на токене и никогда не покидает его (такая возможность попросту отсутствует), все операции вплоть до вычисления хэшей выполняются на самом токене.

Его величество - флаг...

Почему флаг? - Потому, что как оказалась всё софтовое ограничение, запрещающее экспорт, представляет из себя значение в 1 бит. Т.е "1" - экспорт разрешён, а "0" - экспорт запрещён. Такие дела...

А если подробнее?

Давайте взглянем на файл header.key с помощью декодера ASN.1:

Размеченное содержимое header.key

Мы видим всю открытую информацию о контейнере, например байты сертификата под тегом 5, или кусочек публичного ключа под тегом 8, или HMAC для проверки пароля контейнера под тегом 2. Но в данном случае нас интересуют другие данные, а именно 2 SEQUENCE (выделены оранжевым и зелёным). В одном из них мы можем заметить BIT STRING с 3 битами (выделены жёлтым). Данные биты - это параметры приватного ключа. Собственно первый бит и есть флаг экспортируемости. Вообще вся структура там следующая:

Структура битов для параметров приватного ключа

Однако, что за значение выделенное красным? - Это MAC всего контейнера, если мы просто изменим флаг, но не пересчитаем MAC, то КриптоПро такой контейнер не примет. (Кстати подобная схема используется и в экспортном представлении приватного ключа)

Пересчитываем MAC контейнера

Сам алгоритм вычисления MAC довольно прост:

Берём SEQUENCE выделенный оранжевым и сериализуем его в байты;
Вычисляем MAC с помощью шифра Магма (ГОСТ 28147-89) со следующими параметрами:
- Ключ: 32 нулевых байта
- IV/Соль: 8 нулевых байт
- Данные: сериализованый ранее SEQUENCE
- Набор параметров (SBox) - ID_TC26_GOST_28147_PARAM_Z
Подставляем получившейся в MAC (если MAC больше 4 байт то берём только первые 4 байта) в ASN.1 структуру, сериализуем в байты и записываем их в файл
Profit!

В результате изменения бита в параметрах приватного ключа и применения алгоритма вычисления MAC контейнера мы смогли успешно "пролечить" контейнер разрешив экспорт.

Бонус. Как вычисляются остальные MAC

MAC маски и соли

Размеченное содержимое masks.key

Вычисляем MAC с помощью шифра Магма (ГОСТ 28147-89) со следующими параметрами:
- Ключ: Значение маски (выделено жёлтым, если больше 32 байтов, то берём последние 32 байта)
- IV/Соль: 8 нулевых байт
- Данные: Значение соли (выделено оранжевым)
- Набор параметров (SBox) - ID_TC26_GOST_28147_PARAM_Z

Если MAC больше 4 байт то берём только первые 4 байта

MAC пароля

Размеченное содержимое masks.key

Прогоняем через CPKDF (CryptoPro Key derivation function) пароль (в качестве соли для CPKDF берём 8 байт куска публичного ключа (в ASN.1 под тегом 10, на рисунке выделено жёлтым)
Вычисляем MAC с помощью шифра Магма (ГОСТ 28147-89) со следующими параметрами:
- Ключ: Результат из п.1
- IV/Соль: 8 нулевых байт
- Данные: 16 нулевых байт
- Набор параметров (SBox) - ID_TC26_GOST_28147_PARAM_Z
Если MAC больше 4 байт то берём только первые 4 байта

На этом у меня всё, все ASN.1 схемы, а также практические реализации алгоритмов вычисления MAC вы можете найти в исходном коде @li0ard/cpfx. Также туда в скором времени выйдет обновление добавляющее автоматическое изменение флага экспортируемости с пересчётом MAC.

Получаем HTML из Blazorpack

2025-10-25T09:46:31.526Z

Одним вечером у меня появилась необходимость написать парсер HTML одного сайта, но при просмотре содержимого страницы вместо нужных мне данных я увидел данный комментарий:

Я подумал: "Ага, значит данные подгружаются динамически, следовательно должен быть запрос на сервер", однако открыв DevTools я увидел WebSocket, который судя по всему получал HTML от сервера

Как это работает?

Полная схема установки соединения и согласования протоколов

Делать полный разбор протокола я не буду, поэтому кратко пройдёмся по основным этапам:

Установка соединения

После того как браузер загрузил страницу происходит POST запрос на /_blazor/negotiate, который возвращает:

список поддерживаемых транспортных протоколов (WebSockets, Server-Sent Events, Long Polling);
ID соединения (connectionId);
Токен доступа (connectionToken).

Браузер перебирает список протоколов, и пытается установить соединение.
Если первый вариант не удался, то пробуется следующий и так далее.

Обмен данными (BlazorPack)

В качестве протокола обмена сообщениями между сервером и браузером используется протокол SignalR, который в свою очередь использует MessagePack (бинарный формат сериализации)

Также поверх этого используется ещё 1 слой - Binary Message Format (BMF).
К данным добавляются префикс длины, что позволяет передать несколько сообщений за один раз.

Получается такая "матрёшка" из кодировок:

BMF -> SignalR -> MessagePack

Каждый слой решает свою задачу:

MessagePack - компактное представление данных;
SignalR - вызов методов и маршрутизация сообщений (Ядро BlazorPack);
Binary Message Format (BMF) - framing сообщений (Передача нескольких сообщений за раз)

Пример сообщения

Получаем HTML

Данный этап можно назвать самым сложным, так как Blazor не отдаёт HTML в "голом" виде , вместо этого он отдаёт представление DOM в бинарном пакете (RenderBatch) разделённым на секции:

UpdatedComponents (ArrayRange<Diff>);
ReferenceFrames (ArrayRange<Frame>);
DisposedComponentIds (ArrayRange<int>);
DisposedEventHandlerIds (ArrayRange<long>);
StringTable (ArrayRange<string offsets>).

В конце пакета находятся 5 чисел (int32) — это смещения каждой секции в байтах (от начала массива).

Формат DOM

Сами узлы DOM хранятся в структуре под названием RenderTreeFrame, одна структура может описывать:

HTML-тег;
текстовое значение;
атрибут;
компонент Blazor;
"голый" HTML-фрагмент.

Сам RenderTreeFrame выглядит так:

[Тип фрейма][Параметр 1][Параметр 2][Параметр 3][Параметр 4]

Тип фрейма определяет, что это за узел:

1 - HTML-тег (Element);
2 - текст (Text);
3 - атрибут (Attribute);
4 - Компонент Blazor (Component);
5 - Регион (Служебные данные) (Region);
8 - "Голый" HTML (Markup).

Таблица строк

Чтобы не дублировать текст, все строки (имена тегов, атрибуты, значения, текст)
хранятся в конце пакета в таблице строк.

Каждая запись содержит смещение на строку, а сами строки записаны как:

[LEB128-длина][UTF-8 байты строки]

Процесс восстановления HTML

Берём RenderBatch полученный от SignalR
Читаем 5 чисел в конце файла - получаем смещение секций
Переходим в секцию ReferenceFrames - получаем все узлы дерева (RenderTreeFrame)
Последовательно читаем фреймы:
- если Element - создаём элемент;
- если Attribute - добавляем к предыдущему тегу;
- если Text - вставляем текстовое содержимое в предыдущий тег;
- если Markup - вставляем HTML как есть;
- если Region - рекурсивно обрабатываем последующие фреймы;
Используем свойство subtreeLength, чтобы понять, где заканчивается элемент;
Склеиваем всё в строку и получаем HTML.

P.S Реализация TS библиотеки доступна здесь.

Тащим ключи с Рутокен Lite (ч.2)

2025-08-09T16:59:07.277Z

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

Нам понадобится:

Моя утилита
Сам Рутокен Lite и PIN-код пользователя

Важно: Данная статья предполагает, что у вас уже установлен компилятор Go

Клонируем репозиторий и переходим в папку с кодом
Собираем утилиту с помощью go build
Запускаем утилиту, вводим PIN-код пользователя, и вводим метку (см. ниже) нужного контейнера

Пример работы

В указанной утилитой папке будет лежать экспортированный контейнер

Тащим ключи с Рутокен Lite

2025-08-03T17:23:14.015Z

Суть такова

Думаю многим знакома ситуация, когда ФНС (или любой другой УЦ) записывает контейнер с ЭЦП на Рутокен, а в процессе использования возникает необходимость использования ЭЦП без самого Рутокена (например из файловой системы) и т.д.

Однако та же ФНС "отключает" флаг экспортируемости контейнера и при попытке экспорта ключа мы получаем ошибку, а в Центре управления Рутокен'ом есть возможность только экспортировать сертификат.

Скриншот из Центре управления Рутокен'ом

Также следует упомянуть, что существует популярная утилита Tokens.exe от СКБ Контур, однако у неё есть ряд недостатков:

Утилита работает только на Windows
Написана на HTML с использованием устаревшего ActiveXObject с связке с DLL
Утилиту благополучно "выпилили" с сайта, поэтому приходится искать по всему интернету

Тащим ключи

1. Ищем контейнер

Рутокен Lite - не совсем флешка в привычном понимании, у него максимально облегченная файловая система, поэтому просто открыть его в проводнике не получится

Однако для этих целей можно воспользоваться утилитами от проекта OpenSC

Важно: Данная статья предполагает, что у вас уже установлены opensc-tool и opensc-explorer

Поэтому подключаем Рутокен, открываем консоль и вводим opensc-tool --list-files

Файловая система Рутокена

Среди всего списка необходимо найти директорию с 6 файлами, часть из которых доступна для чтения только после авторизации (read[CHV2]). Сделать это легче всего по имени контейнера в КриптоПро, поскольку opensc-tool декодирует ASCII текст:

Совпадение имени контейнера с содержимым файла на Рутокене

Файл на скриншоте это name.key, а директория с контейнером (выделена жёлтым) в нашем случае будет 3f00100010030a00

UPD от 05.08: Вероятнее всего все контейнеры действительно лежат по пути 1000/1003. Соответственно при помощи команды asn1 искать по имени контейнера:

name.key и header.key второго контейнера на Рутокене

2. Выгрузка

Запускаем opensc-explorer и переходим в директорию контейнера с помощью команды cd <путь>

Важно: Необходимо разделить путь директории на группы по 4 символа и убрать 3f00, в нашем случае это будет 1000, 1003, 0a00

В директории файлы лежат в следующем порядке: name.key, header.key, primary.key, masks.key, primary2.key, masks2.key

Файлы контейнера

Теперь самый важный пункт - необходимо авторизоваться по PIN-коду пользователя (в противном случае Рутокен даст выгрузить только name.key и header.key). Сделать это можно с помощью команды verify CHV2 "PIN-код"

Успешная авторизация

Теперь же просто копируем файлы контейнера в память компьютера с помощью команды get File_ID путь_назначения

На этом всё, мы успешно скопировали контейнер с Рутокен Lite в память нашего компьютера. Далее желательно "пролечить" контейнер, чтобы "включить" флаг экспортируемости, но на текущий момент решение ещё в разработке (оповещение о релизе будет в Telegram канале). To be continued...

Бонус. Экспорт приватного ключа

Для удобства использования ключа подписи, его можно экспортировать в формат .pem (с которым умеет работать OpenSSL и прочие утилиты) с помощью моей онлайн-утилиты
В утилиту загружаем файлы header.key, masks.key и primary.key, поле "Пароль" оставляем пустым (поскольку контейнеры на Рутокенах не имеют пароля т.к происходит авторизация по PIN-коду) и нажимаем "Извлечь", через несколько секунд скачается .pem файл с приватным ключом.

KeeLoq и с чем его едят

2025-05-27T20:27:42.908Z

Итак, начнём с выдержки из Википедии:

KeeLoq - блочный шифр, основанный на NLFSR (регистр сдвига с нелинейной обратной связью), разработан компанией Nanoteq Pty Ltd. и продан компании Microchip Technology Inc. Шифрование происходит блоками по 32 бита с помощью 64 битного ключа за 528 итераций. Ранее использовался в автомобильных сигнализациях, а ныне используется в автоматических воротах, гаражных дверях и т.п

Картинка для привлечения внимания

Принцип работы

KeeLoq реализует так называемый code hopping (переключение кода), то есть генерирует уникальный пакет данных для каждой передачи.

Структура пакета данных

Разберём на примере:

239B3DEBF16C47A6

Первые 4 байта - это фиксированная часть (т.н fix), содержит в себе ID нажатой кнопки на пульте (в нашем случае 2) и 28'ми битный серийный номер пульта (39B3DEB)

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

21EB000A

Здесь мы видим всё тот же ID нажатой кнопки (2), 12 бит дополнительной информации (зачастую это serial & 0x3FF) и сам 16 битный счётчик нажатий (000A)

Логика работы счётчика такая:

Если переданное значение счётчика соответствует значению в EEPROM приёмника то приёмник подаёт сигнал контроллеру, что всё хорошо (и контроллер например открывает ворота)

Штатная работа приёмника

Если переданное значение больше значения в EEPROM то приёмник синхронизируется с переданным значением и соответственно после следующей передачи значения начнёт работать штатно

Процесс сихронизации приёмника

Если переданное значение меньше значения в EEPROM то приёмник игнорирует переданную команду, а в некоторых случаях после нескольких отправок "устаревшего" значения и вовсе отвязывает пульт. (Собственно говоря это и есть опасность при экспериментах с KeeLoq)

Реакция на устаревшее значение счётчика и отвязка пульта

Режимы безопасности

В стандарте KeeLoq есть 3 режима безопасности (также известны как KDF, learnings):

Простой режим (Simple learning)
Наименее защищённый режим, при котором мануфактурный ключ никак не преобразуется и используется в шифровании as is.
Классический режим (Normal learning)
Улучшенная версия, где мануфактурный ключ изменяется с помощью серийного номера пульта с помощью побитовых операций

Примерная запись алгоритма

Безопасный режим (Secure learning)
Модифицированная версия классического режима, использующая вместо побитовых операций над серийным номером, дополнительное значение (он же seed), уникальное для каждого пульта и передающееся при первоначальной привязке пульта к приёмнику. На данный момент самый защищённых режим из представленных в стандарте

Примерная запись алгоритма

Однако некоторые производители отклоняются от стандартных режимов безопасности и реализуют свои собственные, давайте рассмотрим некоторые из них:

Magic XOR Type-1 learning
Используется производителем Beninca, представляет из себя XOR серийного номера пульта на мануфактурный ключ

Примерная запись алгоритма

FAAC SLH (SPA) learning
Как понятно из названия, данный алгоритм используется производителем FAAC и по моему мнению является самым продуманным. Представляет из себя серию побитовых операций и шифрования

Примерная запись алгоритма

Теоретические атаки

Слайд-атака

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

На первом этапе набрать порядка 2^32 пар открытый-зашифрованный текст
Далее (M,C) - одна из таких пар, F - функция преобразования. Суть такова:
если (M’,C’) такая, что P’= F(K,M) и C’= F(K,C), то K и есть искомый ключ.

В теории данная атака позволяет получить первые 32 бита ключа.

Корреляционный подход

Атака базируется на свойстве NLFSR - Cor(F) = 1
Оказывается, что для равномерно распределенных x2,x3,x4 имеет место следующее:

{NLFSR(x4, x3, x2, x1, x0) = 0 | x0 ^ x1 = 0} = 5/8
{NLFSR(x4, x3, x2, x1, x0) = 1 | x0 ^ x1 = 1} = 5/8

Используя это и аппроксимируя NLFSR вероятности, можно добиться определения очередной части ключа.

Линейный шаг

Последние 16 бит ключа определяются, если известны все предыдущие. Основываясь на том, что если мы знаем полностью 48 состояние в цикле,то можем записать:

Отсюда находим key^48 и аналогично key^49 ... key^63

Общая сложность всех теоретических атак - ≈2^52 (≈4503599627370496)

Практические атаки

Здесь я хочу поблагодарить Derek Jamison за прекрасные материалы по практическим атакам на KeeLoq

Replay-атака

Очень распространённая атака работающая, преимущественно, для статических кодов, и для уявизмых приёмников, которые не проверяют значение счётчика

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

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

Future-атака

Если мы знаем мануфактурный ключ пульта то можно воспользоваться логикой работы счётчика и отправить "будущее" значение счётчика (было 0001 - стало 3E91), приёмник может подумать, что пульт "убежал" далеко вперёд и синхронизироваться с переданным значением и штатно работать со следующими значениями (3E92, 3E93 и т.п). При данной атаке оригинальный пульт полностью рассинхронизируется и дальнейшее его использования не рекомендуется по описанным выше причинам.

Rollback-атака

Данная атака весьма редкая, однако всё же возможна с некоторыми приёмниками. Она похожа на Future-атаку, однако вместо последующих значений, мы откатываем состояние счётчика после нескольких использований и приёмник может заново синхронизироваться с этими значениями.

Rolljam-атака

Вся суть атаки в том, что вы записываете сигналы с оригинального пульта и не даёте приёмнику получить их (например создавая помехи рядом с приёмником), после чего вы можете использовать записанные сигналы.

Однако следует учесть, что почти во всех странах (например в США, странах ЕС, РФ) глушение сигналов является незаконным.

Атака на мануфактурные ключи (KGB attack)

Идея заключается в том, что, возможно, приёмник умеет работать с несколькими мануфактурными ключами, а не только с одним. Если мы отправим fix от оригинального пульта, но закодируем счётчик с помощью другого мануфактурного ключа, то, возможно, оно откроется (обычно эту атаку комбинируют с Future-атакой, потому что вы не знаете, каким должно быть значение счётчика).

Enc00-атака

Атака представляет собой подмену fix оригинального пульта на fix другого пульта (также привязанного к приёмнику) и использование hop с оригинального пульта.

Важно, что после подмены, пульт, fix которого использовали, рассинхронизируется и перестаёт работать

Unknown-атака

Суть в том, что, когда приёмник не может декодировать hop, он использует значение 0. Для универсальных приёмников есть вероятность, что они откроются при значении 0.

Заключение

Не смотря на все описанные выше уязвимости, KeeLoq, также как и Mifare Classic (чей шифр Crypto-1 был взломан в далёких 2000x) остаётся популярным выбором для бюджетных систем безопасности (автоматические ворота, гаражные двери и т.п). Возможно в будущем все производители перейдут на более стойкие алгоритмы шифрования (например на AES), как это сделали Beninca и Hormann

Кстати, имея на руках мануфактурный ключ вы можете "поиграться" с KeeLoq онлайн в моём мини-приложении.

Использованные материалы

Чиним T5577 с помощью proxmark3

2025-04-09T21:27:32.942Z

Однажды экспериментировав с конфигурацией метки T5577, я получил в результате метку (даже две), которая нормально не определялась через lf search, либо определялась как Valid Indala ID found!.

Valid Indala ID found!, а ведь метка была EM-Marine....

А теперь определяется как ASK и PSK одновременно...

Скорее жив чем мёртв?

Учитывая, что метка всё-таки как-то определялась, то необходимость использования команды lf tune отпадала сама собой.

Поэтому необходимо было определить, может ли proxmark3 считать конфигурацию чипа через lf t55xx [detect / p1detect]. Введя команду, я получил следующий ответ:

[!] Could not detect modulation automatically. Try setting it manually with 'lf t55xx config'

Что ж, ещё не всё потеряно...

Принудительное оживление

Следующим шагом была попытка перезаписать нулевой блок метки, отвечающий за конфигурацию. Я делал это следующими командами:

lf t55xx write -b 0 -d 000880E0 -t
lf t55xx write -b 0 -d 000880E0 --r0 -t
lf t55xx write -b 0 -d 000880E0 --r1 -t
lf t55xx write -b 0 -d 000880E0 --r2 -t
lf t55xx write -b 0 -d 000880E0 --r3 -t

После чего я проверил метку командой lf t55xx detect и... видимо, одна из команд сработала:

Метку удалось вернуть к работе на конфигурации по умолчанию

После чего я попробовал записать на метку какой нибудь рандомный EM-Marine ID и считать его, это сработало!

Метка заработала в стандарте EM-Marine

Заключение

Получилась весьма короткая статья, но я думаю, она кому-нибудь да пригодится.

Вообще, восстановление работоспособности T5577 - это довольно-таки индивидуальная тема. То, что работает в одних случаях, может не работать в других.

Многообразие решений на форуме Dangerous Things :)

Blinded ID в Session и что с ними не так

2024-08-20T10:30:28.968Z

Blinded ID (aka "слепые" айди и т.п) - алгоритм деривации ID пользователя, который является публичным ключом Curve25519, для открытых групп в Session, для того чтобы скрыть настоящий ID пользователя.

Всего существует две версии данного алгоритма:

Legacy версия (ID начинается с префикса 15)
Новая версия (ID начинается с префикса 25)

На данный момент полностью реализованной является legacy версия, а поддержка новой версии есть только в libsession и вроде как планируется в pysogs.

Важно: Все математические операции выполняются в поле Fp кривой ed25519, манипуляции со скалярами (редуцирование, инвертирование) выполняются в поле Fn (order field)

Один ключ -> два ключа. Legacy версия.

Алгоритм

Для работы алгоритма нам понадобится:

ID пользователя
Публичный ключ сервера

Сам алгоритм:

Генерируем т.н "blinding factor": хэшируем с помощью Blake2B публичный ключ сервера и редуцируем результат.
Обозначим, как k.
Из ID пользователя убираем префикс 05 и переводим его в ed25519.
Обозначим, как A.
Умножаем k на A и получаем ключ ed25519, который является одним из возможных "слепых" id.
Обозначим, как kA.

Примерная запись алгоритма

Сломанное условие

Как следует из заголовка, legacy версия генерирует 2 возможных "слепых" ID.

Второй возможный ID (kA2) генерируется на основе kA, только с изменённым (XOR на 128) sign битом.

И для того чтобы выяснить какой из двух ключей следует использовать, pysogs предлагает следующий код:

if kA[31] & 0x80:
    return kA[0:31] + bytes([kA[31] & 0x80])

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

Примерная запись условия

Обратимая необратимость

Так же немало важным является то, что legacy версия (а фактически единственная версия на момент написания статьи) является обратимой вопреки всем заявлениям.

Для этого достаточно инвертировать полученный ранее "blinding factor", умножить его на слепой id, полученный ключ перевести в Curve25519 и в результате мы имеем ID пользователя.

Примерная запись алгоритма

Один ключ -> один ключ. Новая версия

На момент написания статьи эта версия реализована только в libsession, и поэтому может поменяться.

Самое главное отличие этой версии от legacy в том, что в процессе генерации "blinding factor" принимает участие ID пользователя вместе с публичным ключом сервера, что, в свою очередь, исключает возможность обратимости, как это было с legacy версией.

Т.е алгоритм следующий:

Генерируем "blinding factor": хэшируем с помощью Blake2B ID пользователя (вместе с префиксом) и публичный ключ сервера и редуцируем результат.
Обозначим, как k.
Переводим ID пользователя из Curve25519 в ed25519.
Обозначим, как A.
Умножаем скаляр k на A

На выходе получаем единственный Blinded ID для конкретного пользователя на конкретном сервере.

Примерная запись алгоритма

Ссылки

Моя библиотека "Session ID"

Проект Session.js

Проект bunsogs

Расчёт параметров МСК

2024-07-26T06:31:02.435Z

Под МСК (Местная система координат) подразумевается система координат построенная независимо от государственной системы координат (чаще всего на основе СК-42 или СК-63) и для конкретного субъекта Российской Федерации.

Многие программы ГИС позволяют реализовать работу в МСК непосредственно. Так, в QGIS и в MapInfo Pro любая проекция может быть дополнена аффинным преобразованием, а в Global Mapper конформные проекции дополняются разворотом.

Постановка задачи

Имеется 6-7 пунктов, для которых известны координат X и Y в ГСК и в МСК. Необходимо подобрать параметры проекции представляющую МСК в ГИС.

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

Подготовка данных

Имеем 2 каталога координат. Один содержит координаты пунктов в государственной системе, а именно в СК-42, 4 зона (EPSG:28404) в формате Y X:

4645997.49 5768521.60
4661392.15 5770068.91
4650059.09 5783332.41
4634241.37 5778952.22
4631481.69 5764570.61
4642125.18 5754643.12
4655952.19 5757337.28

А второй координаты в местной системе:

67266.64 30088.40
82697.29 31184.27
71759.40 44771.50
55822.67 40857.06
52643.65 26564.42
62990.64 16331.35
76888.20 18619.57

Каждая строка в обоих файлах соответствует одному и тому же пункту. В первой строке центральный пункт системы.

Очень важно помнить, что с точки зрения математической картографии МСК остаётся проекцией Гаусса-Крюгера и наследует её искажения. Поэтому важно знать, на какой именно ГСК основана МСК. Зачастую это заранее неизвестно, и приходится проводить предварительное исследование для выяснения этого вопроса.

В нашем примере мы предполагаем, что это либо СК-42, 4 зона, либо СК-63, район C. Создадим также каталог в СК-63:

cs2cs online by MyGeodata Cloud

330797.453706 5755981.4752
346208.044264 5757327.09534
335051.738244 5770735.14419
319180.795365 5766563.18288
316233.724465 5752221.19702
326744.900981 5742157.23182
340603.316544 5744670.19105

Получение параметров

Для вычислений воспользуемся моей утилитой.

Для начала необходимо определить базовую ГСК, сделаем это с помощью координатных невязок.

Загружаем каталог в СК-42 и в МСК в утилиту, и получаем значение невязок:

Невязки для СК-42

Теперь вычислим невязки аналогичным способом для СК-63:

Невязки для СК-63

Сравнив невязки мы понимаем, что базовая ГСК - СК-63

Получаем параметры 2D преобразования Гельмерта:

А также параметры Аффинного параметрического преобразования:

Побег из КриптоПро (ч.3)

2024-06-23T12:06:45.108Z

В прошлых частях (клик, клик) я разбирался с транспортным ключевым контейнером от КриптоПро (он же PFX, PKCS12, P12). В этой статье пойдёт речь о собственном формате ключевого контейнера КриптоПро (те самые 6 файлов .key)

Проприетарный контейнер КриптоПро

Вообще тема данной статьи не нова, ещё в далёком 2016 года Михаил Куликов (он же shukan) написал статью на Хабре в которой он предоставил программу на C, которая вытаскивала ключ для ГОСТ 34.10-2001. Чуть позже благодаря сообществу появилась версия и для ГОСТ 34.10-2012. Однако пробуя запустить все эти утилиты для контейнера ГОСТ 34.10-2012 512 бит сгенерированного в КриптоПро CSP 5.0, утилиты выдавали ошибку. Собственно это и стало мотивацией разобраться как там всё устроено и написать свою программу.

Как там всё устроено

Файл masks.key

Содержимое masks.key

Содержит в себе три Octet String, которые в свою очередь являются маской ключа (32 байта для 256 бит, 64 для 512), солью для деривации пароля и контрольной суммы маски соответственно.

Файл primary.key

Содержимое primary.key

Содержит зашифрованный приватный ключ (32 байта для 256 бит, 64 для 512), который после расшифровки надо разделить по модулю на поле Q эллиптической кривой ключа.

Файл header.key

Содержимое header.key

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

Получаем приватный ключ

Для получения приватного ключа необходимо выполнить следующие шаги:

Получение так ключа хранения с помощью CPKDF (CryptoPro Key Derivation Function) в которую передаётся пароль и соль из файла masks.key.
Расшифровка основного ключа с помощью ГОСТ 28147-89 (Магма) в ECB режиме с параметрами набора Z от ТК-26
Деление по модулю расшифрованного ключа на маску
Подстановка результата в ASN.1 конструкцию приватного ключа

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

Также хочу выразить благодарность Савелию Красовскому за его утилиту go-decrypto-pro, которая стала основной для моей программы, и VovkaTM за консультации и прочую помощь.

Ссылки

Программа - https://github.com/li0ard/ckey

Утилита go-decrypto-pro - https://github.com/savely-krasovsky/go-decrypto-pro