как мы превратили подписи в систему наблюдаемых nonce-инвариантов, решёток и проверяемых forensic-отчётов

Не “сломать Bitcoin”, а научиться видеть слабые nonce

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

Именно nonce — одно из самых хрупких мест ECDSA и Schnorr-подписей. Не потому, что сами протоколы “плохие”, а потому, что они требуют дисциплины: каждый nonce должен быть секретным, уникальным и достаточно случайным. Если nonce повторился, частично утёк, оказался слишком коротким или начал следовать закономерности, приватный ключ может стать вычислимым.

Но реальная проблема сложнее, чем “найти одинаковый r”. Повтор nonce — это катастрофа, которую видно сразу. А что делать, если nonce не повторяется, но лежит в малом окне? Если у него общий префикс? Если последовательность nonce напоминает ladder? Если есть recurrence? Если в MuSig2 дефект спрятан не в одной подписи, а в effective nonce после агрегации коэффициентов?

Так появилась идея nonce-observatory: не пытаться сразу “восстановить ключ”, а построить систему наблюдения за скрытой nonce-геометрией.

Главная идея проста:

подпись — это не просто пара чисел (r, s);
подпись — это публичная проекция скрытого nonce k и приватного ключа d.

Если аккуратно построить protocol bridge, то из публичных подписей можно получить affine-семейства скрытых nonce-кандидатов, точные целочисленные инварианты, признаки сжатия, решёточные HNP-маршруты и, только в строго проверяемых случаях, candidate private key.

Но в системе действует железное правило:

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

Именно это отличает исследовательский forensic engine от “скрипта, который обещает взломать Bitcoin”.

Что уже было известно до нас

Сначала честно: мы не изобрели HNP, LLL, ECDSA lattice attacks или Polynonce.

Hidden Number Problem — известная математическая рамка, появившаяся в работе Boneh–Venkatesan. Интуитивно HNP — это задача восстановления скрытого числа, когда мы много раз видим частичную или “шумную” информацию о линейных выражениях от него в модульной арифметике. В ECDSA это естественно возникает, если nonce частично известен или ограничен. (isa-afp.org)

Есть публичные реализации ECDSA lattice attacks, где приватный ключ восстанавливается при известных MSB/LSB битах nonce. Например, Bitlogik демонстрирует восстановление ECDSA key при известной части ephemeral nonce. (GitHub)

Есть Polynonce — класс атак на polynomial nonce recurrence в ECDSA; Kudelski применяли такую идею к Bitcoin/Ethereum-датасетам и публично описывали методологию и результаты. (Kudelski Security)

Есть Minerva — lattice attack на утечку bit-length nonce через timing leakage в ECDSA и родственных алгоритмах. (Minerva)

Есть BIP340 — стандарт Schnorr-подписей для secp256k1, где верификация строится вокруг уравнения s·G = R + e·P, а публичные ключи и nonce-точки используют x-only представление и even-Y convention. (Bips)

Есть BIP327/MuSig2 — стандарт multi-signature scheme, совместимый с BIP340. (Bips)

То есть отдельные кирпичи известны. Новизна nonce-observatory не в том, что мы “открыли LLL” или “открыли HNP”. Новизна — в том, что мы собрали эти кирпичи в строгую forensic-систему, где каждый переход контролируется evidence gate.

В чём уникальность nonce-observatory

Я бы сформулировал так:

nonce-observatory — это multi-protocol forensic operating system для weak-nonce analysis, где ECDSA, Schnorr/BIP340 и MuSig2/BIP327 переводятся в protocol-valid affine nonce geometry, а любые recovery claims разрешены только через exact public-key validation.

Ключевые элементы, которые в такой комбинации публично встречаются редко или вообще не видны как единая система:

ECDSA / Schnorr / MuSig2 bridge
+ affine hidden-nonce families
+ exact integer/rational metrics
+ null baseline / positive controls
+ recoverability sanity
+ HNP/Kannan/HNF route
+ Q-LLL backend
+ fplll same-case baseline
+ target embedding decoder
+ nonce error reconstruction
+ cross-signature vote
+ d·G == pubkey acceptance
+ redaction layer
+ claim-boundary scanner
+ full-system audit
+ local AI sidecar on gpt-oss-20b-TurboQuant-MLX-8bit

Это не “одна атака”. Это инженерная среда, которая умеет:

увидеть сигнал;
понять, есть ли bridge к recovery;
отказать, если bridge слабый;
построить lattice/HNP route;
проверить recoverability;
запустить backend;
декодировать candidate;
принять candidate только по d·G == P;
сформировать public-safe evidence.

Математический минимум: почему nonce опасен

ECDSA

ECDSA-подпись удовлетворяет уравнению:

s = k^{-1}(z + r·d) mod n

где:

d — приватный ключ
k — nonce
z — hash сообщения
(r, s) — подпись
n — порядок группы secp256k1

Перепишем:

s·k ≡ z + r·d mod n

или:

k ≡ s^{-1}(z + r·d) mod n

Теперь введём гипотетический секрет d':

k_i(d') = s_i^{-1}(z_i + r_i·d') mod n

Для группы подписей одного public key получаем семейство:

K(d') = { k_1(d'), k_2(d'), ..., k_m(d') }

Истинный d — это параметр, при котором скрытые nonce соответствуют тому, что реально происходило при подписании. Если генератор nonce был слабым, это может проявиться как сжатие, повтор, малый диапазон, prefix family, recurrence или HNP-структура.

Schnorr / BIP340

BIP340-подпись удовлетворяет:

s·G = R + e·P

где:

e = H_challenge(r || P || m) mod n

Из публичных данных можно восстановить:

R* = s·G − e·P

И проверить membership:

r ∈ [0, p)
s ∈ [0, n)
R* != O
y(R*) even
x(R*) == r

Это важно. Мы не “угадываем” R. Мы реконструируем единственную protocol-valid точку и проверяем её соответствие BIP340.

Affine-модель:

s = k + e·d mod n

значит:

k_i(d') = s_i − e_i·d' mod n

То есть Schnorr тоже ложится в affine hidden-nonce geometry.

MuSig2 / BIP327

MuSig2 сложнее. Там есть aggregate key, aggregate nonce, nonce coefficient, key aggregation coefficient, parity corrections. Но partial signature участника можно привести к форме:

s_i = k_eff,i + c_i·d_i mod n

где:

k_eff = k1_eff + b·k2_eff
c_i = e·a_i·g·gacc

Здесь b, a_i, g, gacc — не украшения, а часть protocol bridge. Ошибка в этих коэффициентах ломает анализ.

Суть: MuSig2 partial signature можно свести к Schnorr-like affine equation, но только если аккуратно раскрыть все коэффициенты контекста.

От “сигнала” к “восстановлению”: зачем нужен HNP

HNP — это мост между слабостью nonce и решёткой.

Предположим, nonce не полностью известен, но имеет вид:

k_i = known_i + ε_i

где ε_i — маленькая ошибка.

Подставляем в ECDSA:

s_i·(known_i + ε_i) ≡ z_i + r_i·d mod n

Переносим:

r_i·d − s_i·ε_i ≡ s_i·known_i − z_i mod n

Теперь неизвестны:

d
ε_1, ε_2, ..., ε_m

Но ε_i маленькие. Это типичный HNP/lattice case: правильное решение соответствует короткому или декодируемому вектору.

В nonce-observatory это выглядит так:

signature corpus
  → leakage contract
  → HNP/Kannan lattice case
  → exact HNF row-lattice basis
  → Q-LLL / fplll
  → target_embedding_decode
  → nonce_error_reconstruct
  → cross_signature_vote
  → candidate d
  → d·G == pubkey

Важно: HNP не используется против корректных случайных nonce. HNP route работает только если есть явная nonce-слабость: известные биты, малый error bound, bounded nonce, window locality, prefix leakage или synthetic positive-control.

Что использует Q-LLL

Q-LLL не “угадывает приватный ключ”.

Он не использует маленький d.

Он не делает brute force по nonce.

Он не принимает решение потому, что AI сказал “похоже”.

Q-LLL использует только то, что можно превратить в lattice object:

bounded / partial nonce leakage
→ HNP
→ Kannan target embedding
→ short/decodeable vector

Типы слабостей, которые в принципе могут вести к Q-LLL/HNP route:

В нашем последнем milestone Q-LLL использует controlled ECDSA-HNP positive-control: d берётся из полного диапазона secp256k1, но nonce имеет специальную recoverable HNP-структуру.

Почему было недостаточно “запустить Q-LLL”

На раннем full-range checkpoint Q-LLL и fplll оба запускались, но не восстанавливали d. Это не означало, что Q-LLL “плохой”. Recoverability sanity показал:

truth_vector_constructible: true
truth_vector_norm2_bits: 512
truth_vs_det_root_floor: truth_norm2_greater
case_expected_to_recover: false
likely_cause: truth_vector_not_short_enough_for_current_lattice

Перевод на человеческий:

правильный solution vector существует,
но в этой lattice formulation он слишком длинный,
поэтому reduced basis не обязан его вытаскивать.

То есть проблема была не в backend, а в постановке.

Дальше recoverability layer нашёл другой вариант:

kannan_plus_b_transform

Он был recoverable, но имел overcomplete/rank-deficient форму [6,5]: fplll такую систему обрабатывал, а reference Q-LLL требовал square full-rank row basis.

Мы не стали переписывать Go/Q-LLL под rank-deficient systems. Вместо этого сделали более аккуратный путь:

overcomplete Kannan row system
→ exact HNF row-lattice basis
→ square full-rank Q-LLL-compatible basis

Так появились модели:

kannan_plus_b_transform_hnf_basis
kannan_minus_b_transform_hnf_basis

Это важная инженерная часть: мы сохранили integer row-lattice, но дали Q-LLL форму, которую он может корректно редуцировать.

Главный milestone: full-range Q-LLL recovery

Текущий golden state:

secret_bits: 0
secret_range: full_secp256k1
nonce_bruteforce_disabled: true
lattice_model: kannan_plus_b_transform_hnf_basis
basis_conversion: exact_row_lattice_hnf_basis
decoders:
  target_embedding_decode
  nonce_error_reconstruct
  cross_signature_vote
candidate_source: target_embedding_decode
candidate_acceptance_rule: d*G == pubkey

Результат same-case:

fplll:
  backend_ok: 3
  pubkey_matches: 3
  matches_truth_d: 3

Q-LLL:
  backend_ok: 3
  pubkey_matches: 3
  matches_truth_d: 3

Это означает:

Q-LLL достиг parity с fplll
на full-range controlled ECDSA-HNP regression
без nonce brute force
с acceptance только через d·G == pubkey.

Это не доказывает, что Q-LLL лучше fplll.

Это не доказывает, что реальные сети уязвимы.

Это доказывает:

в корректной recoverable HNP-постановке
Q-LLL может восстановить full-range secp256k1 scalar
внутри nonce-observatory route
с точной публичной проверкой кандидата.

Что такое Q-LLL в этом проекте

Q-LLL в проекте — это не “магическая новая атака”.

Это lattice backend с quantized/oracle machinery и exact-certified boundaries.

Проще:

обычный LLL/fplll:
  редуцирует решётку классическим способом

Q-LLL:
  использует quantized/oracle routing для выбора перспективных действий,
  но все принятые мутации и финальный результат должны проходить exact certificate

В отчётах фиксируется:

valid: true
transform_matches: true
final_exact_certificate: true
exact_gso_calls_during_oracle: 0
fallback: false

То есть quantized/oracle слой не является “истиной”. Он только помогает маршрутизации. Истина остаётся в exact certificate и d·G == pubkey.

Как это отличается от обычных HNP-скриптов

Обычный ECDSA lattice-скрипт часто выглядит так:

есть known nonce bits
строим матрицу
запускаем LLL
пытаемся вытащить d

nonce-observatory делает больше:

1. проверяет protocol validity;
2. строит affine nonce-family;
3. ищет signal;
4. проверяет recoverability;
5. выбирает lattice variant;
6. приводит basis к backend-compatible форме;
7. запускает Q-LLL/fplll same-case;
8. декодирует target embedding;
9. реконструирует nonce errors;
10. голосует по подписям;
11. принимает d только через d·G == pubkey;
12. редактирует секреты в public-safe reports;
13. сканирует claim boundary;
14. гоняет full-system audit.

Именно эта цепочка делает систему интересной.

Сравнение с другими подходами

Где здесь AI и зачем gpt-oss-20b-TurboQuant-MLX-8bit

Отдельная важная часть проекта — локальный AI-sidecar.

Используется локальная модель:

gpt-oss-20b-TurboQuant-MLX-8bit

в окружении Apple Silicon / MLX. Важно понимать роль модели.

Она не делает криптографический вывод.

Она не принимает d.

Она не заменяет верификатор.

Она не имеет права сказать:

этот private key правильный

Её роль другая:

читать отчёты;
классифицировать failure mode;
предлагать следующий route;
проверять claim wording;
искать противоречия;
помогать с audit planning;
подсказывать, какие variants прогнать;
объяснять, почему recovery не должен был произойти;
генерировать buyer-safe summaries.

Почему именно локальная модель важна?

OpenAI выпустила open-weight gpt-oss-120b и gpt-oss-20b как модели, которые можно запускать на собственной инфраструктуре; официальная документация подчёркивает, что они не доступны через ChatGPT/API как hosted-модели и предназначены для запуска под контролем пользователя. (OpenAI Help Center)

OpenAI также указывала, что gpt-oss-20b требует существенно меньше памяти, чем 120b, и распространяется в нативно квантованной форме MXFP4; это делает локальный deployment практичным для задач, где важны приватность, контроль и стоимость. (OpenAI)

В нашем случае модель используется как локальный reviewer/planner, а не как remote oracle. Это важно для криптографической дисциплины: sensitive artifacts, internal reports и маршруты можно анализировать локально, без отправки в облачный сервис.

Где появляется TurboQuant

TurboQuant как исследовательская идея связан с онлайн-векторным квантованием: случайные вращения, scalar quantizers, почти оптимальные границы MSE-искажения, а для inner product — отдельная схема через QJL-остаток, потому что MSE-оптимальный квантователь может давать смещение в оценке скалярного произведения.

В проекте это важно концептуально: quantized machinery допустим как routing/acceleration layer, но не как источник криптографической истины.

То есть правильная архитектурная линия такая:

quantized model / AI / Q-LLL oracle:
  может предложить маршрут, оценить отчёт, помочь выбрать variant

exact verifier:
  принимает или отклоняет криптографический claim

Это принципиально. Если бы AI принимал d, система была бы небезопасной. Но AI у нас работает как sidecar:

AI suggests;
exact verifier decides.

Что делает AI route planner

AI-sidecar planner получает telemetry:

recoverability_sanity report
variant_sweep report
no_recovery_diagnosis
Q-LLL oracle quality report
hardness ladder plan

И выдаёт:

failure_class
recommended_next_variants
forbidden_actions
claim_boundary reminders

Например:

failure_class: truth_vector_not_short_enough
recommendation:
  do not benchmark backend on this variant;
  try Kannan target embedding;
  check HNF basis conversion;
  enable target_embedding_decode.

Это не криптография, но это ускоряет исследовательский цикл.

Система перестаёт быть набором ручных запусков и превращается в управляемый experiment engine.

Full-system audit: почему это важнее красивого demo

После full-range Q-LLL recovery можно было бы остановиться и написать громкий пост. Мы сделали иначе: добавили full-system audit.

Результат:

full_system_audit_passed: true
failure_classes: []
pytest: 79 passed
static_audit_passed: true
qlll_integration_passed: true
qlll_full_range_hnp_passed: true
fplll_full_range_hnp_passed: true
redaction_scan_passed: true
claim_boundary_passed: true
release_hygiene_passed: true
macos_metadata_scan_passed: true

Full-range HNP regression внутри аудита:

cases_total: 3
qlll_positive_control_passed: 3
qlll_pubkey_match_cases: 3
qlll_truth_match_cases: 3
fplll_pubkey_match_cases: 3
fplll_truth_match_cases: 3
qlll_first_recovery_rank_p50/p90/p99: 1/1/1
fplll_first_recovery_rank_p50/p90/p99: 1/1/1

Это означает, что milestone не висит отдельно. Он включён в систему regression/audit gates.

Почему redaction — часть науки, а не бюрократия

Если система работает с synthetic truth, candidate private scalars, raw nonce coordinates и recovery reports, то public-safe слой обязателен.

Мы добавили redaction layer и scanner для опасных полей:

candidate_d
d
secret_d
truth_d
raw_secret_coordinate
k
raw_nonce
MuSig nonce fields

Внутренние отчёты могут содержать synthetic truth для проверки. Но redacted/public reports не должны раскрывать scalar material.

Это не просто “безопасность публикации”. Это часть научной честности:

если claim public-safe,
то он не должен зависеть от скрытого truth material.

Что нового именно в нашем подходе

Снова аккуратно: почти каждый отдельный элемент имеет предшественников.

Но как единая система, новизна выглядит так:

1. Protocol-valid nonce observatory

Мы не анализируем подписи “как числа из CSV”. Мы строим bridge к протоколу:

ECDSA verification
BIP340 R* membership
MuSig2 affine partial-signature reduction

2. Affine hidden-nonce geometry

Для каждой подписи строится hidden nonce family:

k_i(d')

И анализируется не один nonce, а семейство.

3. Recovery claim отделён от observational signal

Система может сказать:

observational_signal_only

и остановиться.

4. Recoverability sanity перед solver benchmark

Система проверяет, должен ли case вообще восстанавливаться:

truth_vector_constructible
truth_vector_norm2
determinant-root comparison
case_expected_to_recover

5. Exact HNF row-lattice conversion для Q-LLL-compatible recoverable HNP basis

Это была ключевая инженерная развилка:

recoverable Kannan system
→ exact HNF row-lattice basis
→ Q-LLL-compatible full-rank basis

6. Decoder stack после reduction

Не просто “посмотрели строки basis”, а:

target_embedding_decode
nonce_error_reconstruct
cross_signature_vote

7. AI как sidecar, не oracle

AI участвует в исследовательском процессе, но не имеет права принимать криптографические утверждения.

8. Full-system audit как обязательный gate

Не просто “получилось один раз”, а:

pytest
integration
full-range HNP regression
redaction
claim boundary
release hygiene

Что мы не утверждаем

Это важный раздел.

Мы не утверждаем:

система ломает Bitcoin;
Q-LLL лучше fplll;
AI восстанавливает приватные ключи;
реальные сетевые подписи уязвимы;
любой Schnorr/MuSig2 можно свести к recovery;
controlled HNP равен real-world exploit.

Мы утверждаем:

nonce-observatory построила протокольно-валидную forensic-систему;
она умеет строить observable nonce geometry;
она умеет отличать signal от recovery;
она умеет отказывать claims;
она умеет проводить full-range controlled ECDSA-HNP recovery;
Q-LLL достиг same-case parity с fplll на HNF-Kannan controlled regression;
final acceptance остаётся только d·G == pubkey.

Почему это может быть полезно

Для криптоаудита

Можно проверять кошельки, библиотеки, HSM, multisig-протоколы и кастомные signing flows на слабые nonce patterns.

Для incident response

Можно разбирать публичные подписи и честно отвечать:

есть exploitable nonce relation?
есть repeated-r?
есть HNP route?
есть recovery evidence?
или только negative forensic result?

Для research

Можно сравнивать:

ECDSA HNP variants
Polynonce-like relations
Schnorr affine families
MuSig2 partial nonce structures
Q-LLL vs fplll

Для buyer-safe демонстраций

Можно показывать controlled recovery без раскрытия реальных секретов:

synthetic positive-control
full-range d
no nonce brute force
redacted reports
public-key validation

Что дальше

Следующий этап — не новый громкий claim, а расширение benchmark envelope.

План:

seeds: 50–200
nonce_bits: 4,6,8,10,12,16,20,24
sample_count: 4,8,16,32
models:
  kannan_plus_b_transform_hnf_basis
  kannan_minus_b_transform_hnf_basis
backends:
  Q-LLL
  fplll
metrics:
  recovery_rate
  first_recovery_rank
  runtime
  timeout
  backend_failures
  false_positive_candidates
  pubkey_matches

Только после этого можно говорить что-то о производительности Q-LLL против fplll.

Пока честный статус:

Q-LLL/fplll parity: доказана на текущем full-range controlled regression
Q-LLL superiority: не заявляется

Итог

nonce-observatory — это не “скрипт для взлома приватных ключей”. Это исследовательская и forensic-система, которая делает с цифровыми подписями то, чего часто не хватает в криптоинструментах:

протокол → математика → evidence → отказ или recovery → audit

Она не обещает невозможного. Она делает другое: создаёт строгий путь от публичной подписи к проверяемому выводу.

Главный результат на сегодня:

Full-range ECDSA-HNP controlled recovery:
  secret range: full secp256k1
  nonce brute force: disabled
  lattice: HNF-converted Kannan basis
  backend: Q-LLL and fplll
  decoder: target embedding + nonce error reconstruction + cross-signature vote
  acceptance: d·G == pubkey
  audit: full-system passed

И главный принцип остаётся неизменным:

AI может помогать думать.
Q-LLL может помогать редуцировать.
fplll может быть baseline.
Но истина — только в точной криптографической проверке.

Именно это, на мой взгляд, и есть самая сильная часть проекта: не один “эффектный recovery”, а дисциплина, которая не позволяет системе врать, даже когда очень хочется заявить больше.