В данной статье в качестве криптоанализа Биткоина разберём вычислительный научный эксперимент, воспроизводящий и расширяющий наблюдение 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 (в частности, известна работами по атакам на слабую случайность при генерации ключей), и её внимание к теме подчёркивает значимость подобных архивных находок для сообщества академической криптографии.
https://www.youtube.com/watch?v=NGLR2N4EK58
Видео, где криптограф Надия Хенингер в соавторстве с Travis Scholl и Dan Shumow обсуждает 152-битную гексадецимальную подстроку
8ce563f89a0ed9414f5aa28ad0d96d6795f9c6, было представлено на Rump Session в рамках конференции Crypto 2019.
Речь идет о странной структуре, найденной в алгоритме ECDSA при анализе блокчейна Bitcoin. Они искали коллизии nonce (случайных одноразовых чисел) и обнаружили следующее:
Около 99% повторяющихся значений nonce в блокчейне (которые позволяют вычислить приватный ключ) равны значению (n−1)/2, где n — порядок эллиптической кривой.
Если умножить это значение на базовую точку (генератор) кривой, получается
X-координата длиной всего 166 бит, в то время как стандартная длина для Bitcoin-кривой — 256 бит.При анализе целого семейства кривых Koblitz (secp) от Certicom выяснилось, что точки-генераторы во всех этих кривых имеют общую константу (ту самую подстроку
8ce563f89a0ed9414f5aa28ad0d96d6795f9c6), которая отличается только в нескольких старших и младших битах.
Эта структура выглядит как недокументированный артефакт процесса генерации базовых точек для этих кривых. Исследователи не нашли доказательств того, что это математический бэкдор (он не помогает в решении задачи дискретного логарифмирования), однако это проливает свет на то, как именно Certicom выбирали генераторы кривых в 1999 году, о чём нигде официально не задокументировано.
Эллиптическая криптография с открытым ключом (ECC) требует задания шести доменных параметров: поля 𝔽p, коэффициентов кривой a, b, порядка подгруппы n, кофактора h и точки-генератора G = (Gx, Gy). Стандарт SEC 2 (Standards for Efficient Cryptography Group, Certicom) фиксирует эти параметры для семейства кривых Кобица secpXXXk1, среди которых secp256k1 лежит в основе Биткоина, Эфириума и многих других блокчейн-протоколов.
Ключевая методологическая проблема, поднятая John Zweng, состоит в том, что процедура построения точки G в спецификации SEC 2 не документирована. В отличие от «верифицируемо случайных» кривых класса «r1» (secp256r1 и др.), для которых существует публичный seed и алгоритм SHA‑1, позволяющий проверить отсутствие «потайных ходов», для Koblitz-кривых такой процедуры нет. Это создаёт зону эпистемической неопределённости, особенно важную для Биткоина, где безопасность активов на сотни миллиардов долларов опирается на эти константы.
Показано, что точка H = G·2⁻¹ (mod n), «отменяющая» операцию удвоения, для всех четырёх кривых обладает x-координатой существенно короче номинальной битовой длины кривой и содержит общую 152-битовую гексадецимальную подстроку 8ce563f89a0ed9414f5aa28ad0d96d6795f9c6. Разбирается код анализируемого блокнота Google Colab по разделам, даётся математическая интерпретация, статистическая оценка вероятности случайного совпадения и историко-криптоаналитический контекст — от скандала с DES S-блоками до Dual_EC_DRBG и принципов nothing-up-my-sleeve (NUMS).
Практическая верификация: скрипты для Google Colab (Python + SageMath)
Для независимого воспроизведения результатов John Zweng мы предлагаем два варианта скриптов, которые можно запустить в среде Google Colab. Первый — на чистом Python с библиотекой ecdsa (доступна в Colab без установки), второй — с использованием SageMath (требует установки, но даёт более прямой доступ к функциям эллиптических кривых).
Скрипт (Python + библиотека ecdsa). Этот скрипт вычисляет точку H для secp256k1 и выводит её x-координату в hex, а также проверяет наличие общей подстроки.
# Устанавливаем библиотеку ecdsa (если ещё не установлена) !pip install ecdsa from ecdsa import SECP256k1 from ecdsa.numbertheory import inverse_mod # Параметры secp256k1 curve = SECP256k1.curve G = SECP256k1.generator n = SECP256k1.order # Находим обратное к 2 по модулю n inv2 = inverse_mod(2, n) # Вычисляем H = G * inv2 H = G * inv2 # Получаем x-координату в шестнадцатеричном виде (без префикса 0x) x_hex = hex(H.x())[2:] print("x(H) = 0x" + x_hex) print("Битовая длина x(H):", len(x_hex) * 4, "бит") # Общая подстрока (152 бита = 38 hex символов) common = "8ce563f89a0ed9414f5aa28ad0d96d6795f9c6" if common in x_hex: print("✅ Общая 152-битная подстрока ОБНАРУЖЕНА!") else: print("❌ Подстрока не найдена.") # Дополнительно: проверка, что 2*H == G twoH = H * 2 assert twoH == G, "Ошибка: 2*H != G" print("✓ Проверка: 2*H == G выполнена.")
Результат выполнения (для secp256k1): x(H) = 0x3b78ce563f89a0ed9414f5aa28ad0d96d6795f9c63, подстрока найдена, битовая длина ~166 бит.
Прикладное применение в аудите Bitcoin. Предложенная методика (деление точки на 2 и анализ битовой длины) может быть встроена в инструментарий проверки новых протокольных констант. Например, при введении вторичных генераторов для конфиденциальных транзакций, Pedersen-коммитментов или агрегированных подписей (MuSig2, FROST) рекомендуется выполнять «тест John Zweng» — деление на малые числа (2, 3, 5, 7) и проверку на аномально короткие координаты, что является эвристическим индикатором непрозрачного или потенциально скомпрометированного конструирования.
Аномалия secp256k1: скрытая структура кривых Коблица
Кривые secp160k1, secp192k1, secp224k1 и secp256k1 относятся к семейству кривых Коблица, стандартизированному в документе SEC 2: Recommended Elliptic Curve Domain Parameters организации Certicom. Кривая secp256k1 приобрела особую значимость благодаря использованию в Bitcoin, Ethereum и десятках других криптовалютных протоколов, где именно генератор G определяет всё пространство открытых ключей ECDSA.
Screencast: https://youtu.be/44CG3WhovE8
Google Colab: https://colab.research.google.com/drive/1e42DLAfRqEwTmsTNwZW2DFNC21umz6d0?usp=sharing
Анализируемый блокнот Google Colab ставит задачу проверить гипотезу, впервые опубликованную John Zweng в 2025 году в виде SageMath-скрипта: если умножить генератор G на мультипликативную обратную двойки по модулю порядка группы n, то результирующая точка H = G·2⁻¹ обладает аномально короткой и структурно повторяющейся x-координатой.
Историческая параллель. Подобные «скрытые регулярности» в криптографических константах — не новость. В 1975 году при стандартизации DES криптографическое сообщество обвиняло NSA во внедрении «непрозрачных» S-блоков; лишь спустя 15 лет, после открытия дифференциального криптоанализа Бихамом и Шамиром, выяснилось, что S-блоки DES были специально усилены против этой ещё не публичной атаки. Аномалия secpXXXk1 — пример того же явления в обратной постановке: структура, которая выглядит подозрительно, но пока не доказана как уязвимость.
Тень Dual_EC_DRBG и загадка x-координаты в криптоанализе
Первая ячейка в Google Colab формулирует «ключевое открытие»: для всех четырёх кривых точка H = G·2⁻¹ имеет x-координату, которая значительно короче номинального размера кривой и содержит общую 152-битовую подстроку. В своих исследованиях нам пришлось не констатировать наличие «backdoor», а поднять вопрос прозрачности процесса генерации параметров, используемых, в том числе, Bitcoin.
Именно такая формулировка соответствует принципу nothing-up-my-sleeve (NUMS) — требованию, чтобы криптографические константы выводились детерминированным и проверяемым способом, исключающим скрытый выбор «удобных» для атакующего значений.
Пример из архивов криптоанализа. Наиболее известный исторический случай нарушения принципа NUMS — генератор псевдослучайных чисел Dual_EC_DRBG, стандартизированный NIST в SP 800-90A. Константы P и Q, задающие эллиптическую кривую генератора, были предложены NSA без объяснения происхождения.
Установка библиотек (fastecdsa pandas)
!pip install fastecdsa pandas
Первая кодовая ячейка в Google Colab устанавливает библиотеку fastecdsa, предоставляющую примитивы для арифметики на эллиптических кривых, и pandas для табличного представления результатов. В выводе фиксируется конфликт версий пакетов (pandas 3.0.3 против требуемой Colab pandas<2.2.2) — типичная для Colab-окружений проблема зависимостей, не влияющая на математический результат, но требующая внимания при воспроизведении эксперимента.
Диагностика сбоя импорта кривых до ситуацию с шифром Enigma
Вторая markdown-ячейка в Google Colab описывает диагностированную проблему: прямой импорт объектов secp160k1, secp192k1, secp224k1, secp256k1 из fastecdsa.curve оказывается нестабильным между в
Решение — явное конструирование объектов кривых из опубликованных доменных параметров SEC 2 (p, a, b, порядок q, координаты генератора gx, gy), что делает вычисление независимым от внутренней структуры конкретной версии библиотеки.
Историческая параллель. Зависимость криптографического кода от «магических» констант библиотек напоминает ситуацию с шифром Enigma: захват немецких таблиц коммутаций и роторных настроек (например, в ходе операций польского Biuro Szyfrów и позже Bletchley Park) позволял союзникам восстанавливать «параметры системы» напрямую, а не полагаться на предположения о её внутреннем устройстве — методологически это то же самое, что явное задание доменных параметров вместо доверия недокументированному импорту.
Инициализация параметров кривых Коблица в Google Colab
Ключевая ячейка в Google Colab задаёт словарь CURVE_PARAMS с параметрами p, a, b, q (порядок подгруппы), gx, gy для всех четырёх кривых Коблица и функцию build_curve(), создающую объект Curve библиотеки fastecdsa. Здесь же определена константа COMMON_SUBSTRING = "8ce563f89a0ed9414f5aa28ad0d96d6795f9c6" — искомая 152-битовая подстрока, вокруг которой строится весь последующий анализ.
Важно отметить математический смысл величин b: для secp160k1 b=7, secp192k1 b=3, secp224k1 b=5, secp256k1 b=7 — это простые «короткие» коэффициенты кривой Вейерштрасса y² = x³ + b, что само по себе соответствует практике NUMS для параметра кривой, но не распространяется на выбор генератора G.
Анализ битовых длин генераторов secp-кривых
Ячейка в Google Colab строит таблицу pandas с битовой длиной x и y координат генератора и порядка группы для каждой кривой. Результат подтверждает ожидаемые размеры (secp256k1: order 256 бит, gx 255 бит, gy 255 бит), демонстрируя, что генераторы G сами по себе выглядят «случайными» — аномалия проявляется только после операции деления на 2.
Кривая | Бит длина G.x | Бит длина G.y | Бит длина порядка n |
|---|---|---|---|
secp160k1 | 158 | 160 | 161 |
secp192k1 | 160 | 192 | 192 |
secp224k1 | 224 | 191 | 221 |
secp256k1 | 255 | 255 | 256 |
Деление точки G: вычисление модульного обратного и точки H
Функции inv_mod(a, p) (реализована через pow(a, -1, p), эффективный алгоритм расширенного Евклида/Ферма) и compute_H(curve_obj, order) реализуют центральную операцию эксперимента:
inv2 = inv_mod(2, order) H = G * inv2 # H = G * 2⁻¹ mod n x_hex = hex(H.x)[2:]
Математически это эквивалентно поиску такой точки H, что 2H = G, то есть «раздваиванию в обратную сторону» операции удвоения точки на кривой. Если исходное G было получено как удвоение некоторой «красивой» точки H₀ (2H₀ = G), то восстановленное H совпадёт с H₀ и будет нести следы этой более простой исходной формы — короткую битовую длину и повторяющуюся подстроку.
Пример из архивов криптоанализа. Похожий приём «обращения операции конструирования» использовался при взломе шифровальной машины Lorenz SZ40/42 Биллом Татом (Bill Tutte) в 1942 году: анализируя структуру ключевого потока, криптоаналитики Bletchley Park восстановили внутреннюю логику генерации, не имея физического доступа к машине, — то есть «отменяли» неизвестное преобразование по наблюдаемым артефактам, точно как в данном блокноте Google Colab отменяется удвоение точки для восстановления скрытого прообраза генератора.
Уязвимость точек вне кривой в ECDH/ECDSA: явное построение точки G
Уточнённая версия compute_H() строит генератор явно через Point(curve_obj.gx, curve_obj.gy, curve_obj) и проверяет G.on_curve перед вычислением H — необходимая мера защиты от «invalid curve point» атак, класса атак на реализации ECDH/ECDSA, когда подсунутая точка вне кривой раскрывает секретный скаляр через китайскую теорему об остатках (атака Antipa/Biehl/Meyer/Müller, 2003).
Историческая параллель. Invalid-curve атаки — не абстракция: в 2015 году исследователи продемонстрировали практическое извлечение приватных ключей TLS-серверов через отправку точек, не лежащих на заявленной кривой, эксплуатируя отсутствие проверки on_curve в некоторых реализациях OpenSSL и Bouncy Castle. Явная проверка в блокноте Google Colab — прямое методологическое эхо этого урока.
Специфичность аномалии базовой точки: проверка малых делителей 3, 5, 7
Функция test_small_divisors() обобщает эксперимент, вычисляя G·d⁻¹ для d = 3, 5, 7 и проверяя наличие той же общей подстроки и аномально короткой битовой длины. Результат для secp256k1 показывает полную длину x-координаты (256 бит) без совпадения подстроки для всех трёх делителей — то есть аномалия строго специфична для делителя 2, что усиливает гипотезу о её происхождении именно как «G = 2·H₀» при выборе базовой точки.
Делитель d | Бит-длина x(G·d⁻¹) | Общая подстрока |
|---|---|---|
3 | 256 | нет |
5 | 256 | нет |
7 | 256 | нет |
Математика против случайности: анализ генерации кривых и статистическая интерпретация
Заключительный раздел блокнота Google Colab даёт количественную оценку: для случайно выбранного генератора 256-битовой кривой вероятность того, что x-координата H = G·2⁻¹ имеет битовую длину 166 бит или меньше (то есть отсутствуют по крайней мере 90 верхних бит), составляет порядка 2⁻90 — величина, астрономически малая. Совпадение этого паттерна сразу для четырёх независимо стандартизированных кривых, объединённых общей 152-битовой подстрокой, статистически исключает случайность и указывает на единый детерминированный метод генерации базовых точек.
Формально, если событие «короткая x-координата H» независимо и равновероятно для каждой кривой с вероятностью \(p \approx 2⁻90\), то вероятность наблюдения такого паттерна во всех четырёх кривых одновременно, да ещё с идентичной подстрокой, оценивается как \(p^4\) в самом консервативном приближении — величина, не имеющая практического шанса случайного возникновения.
Пример из архивов криптоанализа. Похожая статистическая аргументация лежала в основе разоблачения слабости в генераторе Debian OpenSSL PRNG (2006–2008): обнаружение того, что энтропия сид-пула сократилась до 15 бит из-за случайно удалённой строки кода, было доказано именно через статистическую невозможность наблюдаемого распределения ключей при истинно случайной генерации — уязвимость затронула тысячи SSH-ключей и SSL-сертификатов по всему миру.
Выводы для Bitcoin и криптографии в целом
Подчёркивают принципиальное различие между кривыми secp*r1 (verifiably random, параметры которых выводятся из хеш-семени по прозрачному алгоритму согласно X9.62/FIPS 186) и кривыми Коблица secp*k1, для которых публично не документирован ни сид, ни алгоритм генерации базовой точки. Это не означает наличие математической уязвимости в самой схеме ECDSA/Schnorr — общепризнано, что выбор конкретного генератора G среди генераторов группы простого порядка не влияет на стойкость схем, использующих единственный генератор. Однако находка усиливает аргумент в пользу строгого применения NUMS-принципов при введении новых констант — например, дополнительных генераторов для Taproot-коммитментов или confidential transactions, где взаимосвязь между несколькими точками уже критична для безопасности.
Пример из архивов криптоанализа. Именно из-за подобных опасений сообщество разработало альтернативные кривые с полностью документируемым, детерминированным происхождением: Curve25519 Дэниела Бернстайна (2005) и семейство NUMS curves (IETF draft-black-numscurves, 2014) явно фиксируют алгоритм выбора каждой константы, что исключает саму возможность «спрятанного» выбора, аналогичного обнаруженному в secpXXXk1.
Историко-стандартизационный контекст
В спецификации SEC 2 для Koblitz-кривых указано лишь, что параметры были «выбраны путём повторного подбора, допускающих эффективно вычислимый эндоморфизм, до тех пор пока не была найдена кривая простого порядка». Это описание касается выбора p и b, но не объясняет алгоритм выбора G. Для сравнения: для кривых NIST P-256 (secp256r1) используется процедура с публичным seed-значением и SHA‑1, что позволяет проверить отсутствие скрытых «лазеек» (verifiably random). Отсутствие такой процедуры для secp256k1 означает, что сообщество Bitcoin вынуждено доверять разработчикам Certicom, многие из которых уже недоступны для комментариев.
Находка John Zweng подтверждает, что G не был выбран случайно: общая подстрока и короткая длина координат указывают на детерминированный процесс, возможно, с использованием хеш-функции (например, SHA‑1), но точный алгоритм остаётся неизвестным. Это ставит серьёзные вопросы о том, насколько параметры secp256k1 соответствуют принципу «nothing-up-my-sleeve» (NUMS).
Криптографические следствия: уязвимость или артефакт?
Важно подчеркнуть, что сам по себе факт наличия общей подстроки не является уязвимостью для протоколов, использующих единственный генератор G (ECDSA, Schnorr). Безопасность ECDLP в циклической группе простого порядка не зависит от выбора образующего элемента — любой генератор эквивалентен любому другому с точностью до известного скалярного множителя.
Однако существуют три аспекта, придающих находке криптоаналитическую значимость:
Эпистемический: документирование непрозрачности стандартизации, что важно для оценки доверия (trust assumptions).
Методологический: предложенный тест является универсальным инструментом аудита ECC-параметров.
Практический для расширений протокола: если в будущем Bitcoin введёт второй генератор H с неизвестным соотношением к G (например, для конфиденциальных транзакций), то непрозрачное конструирование H может позволить создателю параметров вычислить дискретный логарифм logG H, что в схемах типа Pedersen-коммитментов эквивалентно возможности неограниченной эмиссии. Именно поэтому в BIP‑341 (Taproot) введено строгое требование NUMS-точек с полностью документированным алгоритмом получения.
Вывод для Bitcoin-разработчиков. Прецедент John Zweng служит эмпирическим обоснованием необходимости верифицируемой случайности при выборе любых новых криптографических констант в экосистеме Bitcoin. Любые предложения по добавлению дополнительных точек должны сопровождаться общедоступным, воспроизводимым скриптом, аналогичным представленным выше, и проходить «тест на аномалию» (малая битовая длина координат при делении на малые числа).
Формальная постановка гипотезы и модель случайности
В этом разделе мы формализуем модель, по которой оценивается случайность базовых точек в кривых семейства secp*k1, и рассматриваем вопросы выбора генераторов.
Перед нами встает один из душетрепещущих вопросов насколько корректна нулевая гипотеза о случайности x-координаты точки H = G·2⁻¹ mod n для стандартизованных генераторов семейства secp*k1? Ответом всплывает объяснение, что нулевая гипотеза предполагает, что генератор G выбран абсолютно случайно из всех точек кривой. При таком выборе точка H = G·2⁻¹ также должна быть псевдослучайной, и её x-координата должна иметь длину, близкую к порядку кривой (например, 256 бит для secp256k1). Обнаружение того факта, что координата x точки H ограничена примерно 166 битами и содержит фиксированную 152-битную подстроку для четырех различных кривых, делает нулевую гипотезу статистически несостоятельной. Вероятность такого события для одной кривой оценивается как 2⁻⁹⁰, а для четырех — как 2⁻³⁶⁰. Это однозначно указывает на детерминированный процесс выбора.
Также в наших криптоаналитических наблюдениях всплывает вопрос о том можно ли реконструировать правдоподобный детерминированный алгоритм выбора G, который объясняет наблюдаемую структуру лучше, чем модель случайного выбора? В конечном итоге мы положительно отрегировали на поставленную задачу и вопрос так как структура прямо указывает на алгоритм, в котором сначала детерминированно выбирается некая «базовая» точка H₀. Эта точка H₀ конструируется путем добавления переменного префикса (зависящего от конкретной кривой) к фиксированной 152-битной строке (8ce563f89a0ed9414f5aa28ad0d96d6795f9c6). Затем результирующая точка H₀ удваивается на кривой: G = 2H₀. Опубликованным стандартом генератором становится именно точка G, скрывая простую структуру H₀ до тех пор, пока кто-то не вычислит G·2⁻¹.
Безусловно мы рассмотрели вопрос чем случай secp*k1 отличается от verifiably random подхода для других стандартных кривых и от позднейших NUMS-практик? Также безусловно все имеющие кривые серии secp*r1 (например, secp256r1) генерировались по алгоритму verifiably random: параметры и базовая точка получались путем хеширования публично известного seed-значения (в соответствии со стандартами X9.62/FIPS 186). Это доказывает, что параметры не были выбраны для создания бэкдора. Для secp*k1 ни seed, ни алгоритм генерации G никогда не публиковались. Современные NUMS-практики (Nothing Up My Sleeve) требуют, чтобы константы выводились из фундаментальных чисел (например, цифр Пи) или прозрачных хеш-функций. Отсутствие такого обоснования для G в secp*k1 является отклонением от идеалов NUMS.
Статистические ограничения и множественные сравнения
Анализ аномалий часто страдает от проблемы множественных сравнений (p-hacking), однако в данном случае результаты обладают высокой робастностью.
Для этого мы подняли один самых важных вопросов как меняется статистическая значимость результата при учёте множественных сравнений и post hoc-выбора признаков аномальности? В итоге выяснили что даже с учетом поправки на множественные сравнения (например, если исследователь проверял умножение на различные малые константы 2, 3, 4, 5… и разные подстроки), изначальная вероятность 2⁻³⁶⁰ (для четырех кривых) настолько мала, что поправки Бонферрони или аналогичные методы не могут свести результат к статистической незначимости. Post-hoc выбор признаков мог бы объяснить случайное совпадение вероятностью 10⁻³ или 10⁻⁶, но не астрономические величины порядка 10⁻¹⁰⁰. Это подтверждает, что аномалия является намеренным артефактом генерации.
Углубившись в процессы криптоанализа у нас всплыл ещё один важный вопрос является ли обнаруженный паттерн свойством именно делителя 2 или проявляется в более широком семействе обратимых скаляров при иных метриках структуры? Ответ однозначно был в том что вычислительный эксперимент показал, что при делении на 3, 5 и 7 (вычисление G·d⁻¹) для secp256k1 получаются точки с полной 256-битной x-координатой без каких-либо общих подстрок. Аномалия строго специфична для делителя 2 (операции отмены удвоения). Это означает, что паттерн не является общим структурным свойством группы, а является прямым следствием конкретной алгебраической операции (G = 2H₀), примененной создателями при поиске генератора.
Криптографические последствия и границы интерпретации
Выявленная аномалия ставит важные вопросы доверия, но не обязательно означает наличие уязвимостей в современных протоколах.
В своих криптоаналитических исследованиях мы задались вопросом имеет ли наблюдаемая структура прикладные последствия для стойкости ECDSA/Schnorr, либо её значение ограничивается вопросами прозрачности стандартизации и криптографического доверия? В итоге, мы пришли к выводу что для протоколов ECDSA и Schnorr, использующих единственный генератор G, алгебраическая структура этого генератора (например, знание того, что G = 2H₀) не снижает криптографическую стойкость. Задача дискретного логарифмирования остается сложной. Однако, это открытие является серьезным вопросом криптографической гигиены и доверия. Недокументированная структура констант исторически ассоциируется с потенциальными бэкдорами (как в случае с Dual_EC_DRBG), что подчеркивает необходимость максимальной прозрачности.
Также какие критерии происхождения базовых точек должны считаться достаточными для современных стандартов открытых параметров? Наши исследование показали что современные стандарты должны требовать полностью прозрачного, воспроизводимого процесса (NUMS). Генерация базовых точек должна осуществляться путем применения односторонней функции (например, SHA-256 или SHA-3) к публично известной, очевидно нейтральной строке (например, «Bitcoin secp256k1 base point generation»). Алгоритм должен детерминированно отображать этот хеш в валидную точку кривой (например, метод hash-to-curve), исключая любую возможность создателя тайно выбрать точку с известным ему дискретным логарифмом относительно другой точки.
Следует ли применять подобный аудит ко всем публичным генераторам в протоколах Bitcoin и смежных системах, особенно там, где используется более одной базовой точки так как в системах, использующих несколько генераторов (например, протоколы с Pedersen commitments, Confidential Transactions, Taproot), критически важно, чтобы дискретный логарифм одного генератора относительно другого был неизвестен (принцип NUMS для нескольких генераторов). Отсутствие прозрачности в происхождении таких точек может позволить создателю подделывать обязательства или нарушать приватность. Аудит подобных структур обязателен для обеспечения доверия к сложным криптографическим протоколам.
Итоговое заключение:
Разобранный блокнот Google Colab представляет собой воспроизводимый вычислительный эксперимент, который методом явного и валидированного построения эллиптических кривых демонстрирует статистически значимую структурную регулярность в генераторах четырёх стандартизированных кривых Коблица. Хотя это открытие не компрометирует напрямую криптографическую стойкость ECDSA в Bitcoin, оно поднимает фундаментальный вопрос доверия к процессу стандартизации криптографических параметров — вопрос, исторически возникавший при DES, Dual_EC_DRBG и других эпизодах, где отсутствие прозрачности впоследствии оказывалось либо тревожным сигналом, либо, как в случае DES, скрытым усилением, распознанным лишь десятилетия позже.
Проведённый анализ вычислительного эксперимента неопровержимо доказывает, что базовые точки-генераторы в кривых семейства secp*k1, включая широко используемую в криптовалютах secp256k1, были сгенерированы не случайным образом. Статистическая вероятность обнаруженного структурного паттерна — дефицита битовой длины и наличия общей 152-битовой константы при отмене операции удвоения генератора — ничтожно мала, что исключает возможность случайного совпадения. Наличие детерминированного алгоритма генерации, скрытого от публики, противоречит современным стандартам открытых криптографических параметров и парадигме NUMS (Nothing Up My Sleeve).
Хотя данная структурная аномалия напрямую не компрометирует математическую стойкость протоколов ECDSA и Schnorr, использующих единственный генератор, она поднимает критически важные вопросы доверия к процессам стандартизации. В контексте сложных криптографических систем, требующих нескольких генераторов с неизвестными друг другу дискретными логарифмами, непрозрачность выбора базовых точек становится недопустимым риском. Дальнейшее развитие криптографических стандартов должно бескомпромиссно опираться на полностью прозрачные, верифицируемые методы генерации параметров, исключающие любую возможность скрытого манипулирования со стороны их создателей.
📚 Огромное благодарность:
Standards for Efficient Cryptography Group (SECG). SEC 2: Recommended Elliptic Curve Domain Parameters. Certicom Research.
Zweng, John. The mystery of the generation points of the secpXXXk1 curves. GitHub Gist, 2025. URL: https://gist.github.com/johnzweng/863f412689ee383cc41ac7c709ca662c.
Coppersmith, D. (1994). The Data Encryption Standard (DES) and its strength against attacks. IBM Journal of Research and Development.
Nothing-up-my-sleeve number. Wikipedia.
Green, M.; Bernstein, D.J. et al. Analyses of the Dual_EC_DRBG backdoor (2013–2014); NIST SP 800-90A withdrawal notices.
Antipa, A.; Brown, D.; Menezes, A.; Struik, R.; Vanstone, S. (2003). Validation of elliptic curve public keys. PKC 2003; invalid-curve attack disclosures (2015).
Debian OpenSSL predictable PRNG vulnerability (CVE-2008-0166), Debian Security Advisory.
ANSI X9.62 / FIPS 186-4 verifiably random elliptic curve parameter generation procedure.
Bernstein, Daniel J. Curve25519: new Diffie-Hellman speed records. Public-Key Cryptography (PKC) 2006, Lecture Notes in Computer Science, vol 3958. Springer, 2006.
Wuille, Pieter, Nick, Jonas, and Ruffing, Tim. BIP 341: Taproot: SegWit version 1 spending rules. Bitcoin Improvement Proposals, 2020. URL: https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki.
Certicom Research. SEC 2: Recommended Elliptic Curve Domain Parameters, Version 2.0. Standards for Efficient Cryptography Group (SECG), 2010. URL: https://www.secg.org/sec2-v2.pdf.
Brown, Daniel R.L. SEC 1: Elliptic Curve Cryptography, Version 2.0. Standards for Efficient Cryptography Group (SECG), 2009. URL: https://www.secg.org/sec1-v2.pdf.
Bernstein, Daniel J. Curve25519: new Diffie-Hellman speed records. Public-Key Cryptography (PKC) 2006, Lecture Notes in Computer Science, vol 3958. Springer, 2006.
Presentation at the Crypto 2019 rump session on work of Nadia Heninger, Travis Scholl, Dan Shumow (The IACR is the International Association for Cryptologic Research, online at http://www.iacr.org)
Данный материал создан для портала CRYPTO DEEP TECH для обеспечения финансовой безопасности данных и криптографии на эллиптических кривых secp256k1 против слабых подписей ECDSA в криптовалюте BITCOIN. Создатели программного обеспечения не несут ответственность за использование материалов.
Telegram: https://t.me/cryptodeeptech
Видеоматериал: https://youtu.be/ytFVasVx6Ak
Video tutorial: https://dzen.ru/video/watch/6a660f77a52c4438aad88da8
Источник: https://cryptodeeptool.ru/curve-anomalies
