Как мы встроили LLM в криптофорензику так, чтобы она могла управлять solver’ами, но не могла принять приватный ключ, nonce или recovery claim

Не “AI взломал криптографию”, а “AI не имеет права быть источником криптографической истины”

Когда AI подключают к сложной инженерной системе, обычно задают один и тот же вопрос:

может ли модель найти правильный ответ?

В криптографии этот вопрос почти всегда поставлен неправильно.

Правильный вопрос другой:

можно ли встроить AI так, чтобы даже при ошибке он не мог принять опасное решение?

Это особенно важно в системах, которые работают с цифровыми подписями, nonce, решётками, HNP-маршрутами и candidate private key. Там нельзя сказать: “модель уверена, значит ключ найден”. Нельзя принять candidate_d по confidence score. Нельзя превратить красивое объяснение в cryptographic evidence. Нельзя позволить текстовому reasoning заменить проверку:

candidate_d · G == observed_public_key

Именно поэтому следующий слой nonce-observatory получился немного парадоксальным:

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

Этот слой я называю governed solver orchestration.

Коротко: что было в предыдущей части

В предыдущей публикации мы рассматривали nonce-observatory как forensic-систему для анализа слабых nonce в ECDSA, Schnorr/BIP340 и MuSig2/BIP327.

Главная идея была такой:

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

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

Для ECDSA:

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

Отсюда:

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

Для Schnorr/BIP340:

s = k + e·d mod n

Отсюда:

k(d') = s - e·d' mod n

Для группы подписей одного публичного ключа возникает семейство:

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

Истинный d — это параметр, при котором скрытая nonce-последовательность соответствует тому, что реально происходило при подписании.

Если nonce-генератор был слабым, это может проявиться как:

повтор;
короткий диапазон;
общий префикс;
ladder;
recurrence;
bounded-window leakage;
HNP-структура;
MuSig2 effective nonce defect после protocol aggregation.

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

сигнал ≠ восстановление
candidate ≠ private key
AI score ≠ cryptographic evidence

Кандидат принимается только через deterministic gate:

d · G == P

или через protocol-specific verification, если речь идёт не о private key, а о подписи, partial signature или membership claim.

Зачем вообще нужен AI в такой системе

На первый взгляд, если всё должно решаться exact verifier’ом, AI вообще не нужен.

Но реальная forensic-система быстро становится слишком многомерной.

Есть разные протоколы:

Протокол	Что анализируется
ECDSA	`(r, s, z, P)` и affine pullback через `u_r`, `u_z`
Schnorr/BIP340	`R* = sG - eP`, x-only/even-Y membership
MuSig2/BIP327	partial signatures, aggregate nonce, key aggregation coefficients, parity corrections

Есть разные классы nonce-дефектов:

Класс	Возможный маршрут
repeated nonce	direct algebra
short nonce	bounded search / HNP
known MSB/LSB	HNP / lattice
small nonce difference	difference route / lattice
prefix leakage	bounded-error HNP
recurrence	Polynonce-like route
finite coverage	bounded pullback search
PRF-like / IID	refusal / observational-only

Есть разные solver backend’ы:

rule-based direct algebra
bounded search
HNP lattice route
fplll
Q-LLL
custom decoder
cross-signature vote
public-key validation

Есть разные отчёты:

feature_contract.json
risk_ranking.json
solver_report.json
redacted_solver_report.json
claim_boundary_report.json
ai_review_report.json

На практике возникает проблема:

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

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

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

feature contract
    → route interpretation
    → solver plan
    → solver queue
    → human/machine-readable rationale

Но есть опасность: если AI умеет строить solver plan, он может начать звучать так, будто умеет принимать результат.

И вот это надо запретить архитектурно.

Неправильная архитектура: AI-oracle

Плохая схема выглядит так:

signature corpus
      |
      v
AI analysis
      |
      v
"candidate key seems valid"
      |
      v
recovery claim

Это недопустимо.

Почему?

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

Фраза:

Модель считает, что этот d похож на правильный.

не имеет криптографического смысла.

Криптографический смысл имеет только:

d · G == P

или:

Verify(P, m, sig) == true

или:

BIP340 membership bridge passed all deterministic checks

или:

public signature relation reconstructs exactly

AI может быть полезен в reasoning, но reasoning не является acceptance authority.

Формально:

AI confidence ∉ cryptographic evidence

и:

textual explanation ∉ verification proof

Правильная архитектура: governed solver orchestration

Новый слой был оформлен как отдельный модуль:

src/nonce_observatory/ai/governed_solver_orchestrator.py

Его роль намеренно узкая:

route_planner_and_solver_scheduler_only

То есть AI может:

читать public-safe feature contract;
предложить route plan;
ранжировать solver families;
построить solver queue;
объяснить, почему один маршрут выше другого;
указать, что часть cases должна остаться observational-only;
помочь сформировать human-readable отчёт.

Но AI не может:

видеть truth/private/nonce поля;
принимать candidate_d;
принимать k;
принимать recovery claim;
объявлять solver success;
считать свой score evidence;
обходить deterministic integrity gate.

Архитектурно это выглядит так:

              ┌─────────────────────────────┐
              │ public-safe feature contract │
              └──────────────┬──────────────┘
                             │
                             v
              ┌─────────────────────────────┐
              │ forbidden-field sanitizer    │
              │ truth/private/nonce guard    │
              └──────────────┬──────────────┘
                             │
                             v
              ┌─────────────────────────────┐
              │ AI route planner             │
              │ no cryptographic authority   │
              └──────────────┬──────────────┘
                             │
                             v
              ┌─────────────────────────────┐
              │ governed solver queue        │
              │ routes, priorities, rationale│
              └──────────────┬──────────────┘
                             │
                             v
              ┌─────────────────────────────┐
              │ deterministic solver/backend │
              └──────────────┬──────────────┘
                             │
                             v
              ┌─────────────────────────────┐
              │ integrity gate               │
              │ d·G == P / Verify == true    │
              └──────────────┬──────────────┘
                             │
                             v
              ┌─────────────────────────────┐
              │ redacted evidence report     │
              └─────────────────────────────┘

Ключевой момент:

AI стоит между feature contract и solver queue, а не между solver result и truth acceptance.

Non-escalation boundary

Центральный принцип этого слоя — non-escalation boundary.

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

Можно сформулировать так:

AI may propose actions.
AI may not accept facts.

Или по-русски:

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

Таблица получается такая:

Разрешено AI	Запрещено AI
выбрать порядок solver routes	принять `candidate_d`
предложить solver family	принять `k`
построить solver queue	видеть truth/private fields
объяснить failure mode	сериализовать secret material
предложить bounded follow-up	делать recovery claim
сравнить route confidence	считать score криптографическим evidence
помочь с buyer-safe wording	обходить deterministic verifier

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

Потому что если AI может принять candidate_d, вся evidence-модель ломается.

Почему это не бюрократия

На первый взгляд может показаться, что мы просто добавили много запретов.

Но именно эти запреты делают AI полезным.

Если AI может принять ключ, мы получаем недоверенный oracle.

Если AI может только построить очередь проверяемых действий, мы получаем ускоритель исследования.

В виде формулы:

unsafe AI = reasoning + authority

safe AI = reasoning - authority + deterministic gates

В криптографии полезный AI — не тот, который “сам знает ответ”, а тот, чья ошибка не может стать cryptographic claim.

Что AI видит

AI получает не сырые секреты и не truth manifest, а безопасный feature contract.

Условный public-safe пример:

{
  "case_id": "case_001",
  "protocol": "ecdsa",
  "truth_access": false,
  "integer_only": true,
  "normalized_metrics_used": false,
  "fractional_thresholds_used": false,
  "feature_vector": {
    "signature_count": 128,
    "unique_r_count": 128,
    "repeated_r_value_count": 0,
    "max_repeated_delta_support": 3,
    "prefix32_support": 0,
    "hnp_window_candidate": true,
    "recurrence_candidate": false,
    "clean_control_like": false
  },
  "claim_boundary": {
    "analysis_only": true,
    "recovery_claim_allowed": false,
    "solver_gate_required": true
  }
}

Здесь нет:

private key
raw nonce
truth d
truth k
candidate secret
unredacted solver material

AI может увидеть структуру признаков, но не может увидеть материал, который позволил бы ему стать secret oracle.

Что AI выдаёт

AI не должен выдавать:

candidate_d = ...
private key recovered
nonce recovered
recovery successful

Он должен выдавать solver plan.

Пример безопасного output:

{
  "ai_role": "route_planner_and_solver_scheduler_only",
  "truth_access": false,
  "ai_accepts_candidate_d": false,
  "ai_accepts_recovery_claim": false,
  "ai_score_is_cryptographic_evidence": false,
  "acceptance_authority": "deterministic_integrity_gate_only",
  "solver_queue": [
    {
      "rank": 1,
      "route": "hnp_window_leakage_check",
      "solver_family": "lattice_hnp",
      "reason": "bounded-window signal present; repeated-r absent",
      "claim_after_run": "no claim without public-key verification"
    },
    {
      "rank": 2,
      "route": "delta_recurrence_probe",
      "solver_family": "recurrence_analysis",
      "reason": "small repeated-delta support requires sterile follow-up",
      "claim_after_run": "observational only unless deterministic gate passes"
    },
    {
      "rank": 3,
      "route": "clean_control_refusal_check",
      "solver_family": "none",
      "reason": "ensure no solver is launched on PRF-like control",
      "claim_after_run": "refusal is valid evidence"
    }
  ]
}

Обратите внимание: каждая строка queue — это не claim.

Это только предложение проверяемого действия.

route recommendation ≠ recovery evidence

Где проходит граница acceptance

Допустим, solver что-то нашёл.

Плохой вариант:

AI посмотрел на solver output и написал: похоже, recovery successful.

Правильный вариант:

solver produced candidate
      |
      v
deterministic integrity gate
      |
      v
candidate accepted only if d·G == P

Для ECDSA private-key candidate:

d_candidate · G == P_observed

Для подписи:

ECDSA_Verify(P, z, r, s) == true

Для BIP340 membership:

R* = sG - eP
R* != O
has_even_y(R*) == true
x(R*) == r
0 <= r < p
0 <= s < n

Для MuSig2 partial signature:

partial verification passes under full session context

AI не участвует в этом как authority.

Он может только описать результат после того, как deterministic verifier уже поставил статус.

Почему AI score не доказательство

Допустим, модель выдаёт:

route_confidence = 0.91

Это может быть полезно для сортировки очереди.

Но это не evidence.

Внутри системы это должно быть зафиксировано явно:

{
  "ai_route_score": 0.91,
  "ai_score_used_for": "queue_ordering_only",
  "ai_score_is_cryptographic_evidence": false,
  "recovery_claim_allowed": false
}

Почему так строго?

Потому что cryptographic доказательство должно быть воспроизводимым без AI.

Если убрать модель, результат должен либо всё равно проверяться, либо исчезать как route suggestion.

Правило:

если claim нельзя проверить без AI, это не cryptographic claim

Минимальный CLI-контур

Новый слой можно вызывать как отдельную стадию:

python -m nonce_observatory.cli.main ai governed-solver-orchestration \
  --case-id case_001 \
  --protocol ecdsa \
  --feature-contract-json features.json \
  --output-json runs/ai_routes/governed_solver_orchestration.json \
  --output-md runs/ai_routes/GOVERNED_SOLVER_ORCHESTRATION.md

Смысл этой команды не в том, чтобы восстановить ключ.

Смысл в другом:

feature contract → governed route plan → solver queue

Она должна ответить:

какие маршруты допустимы;
какие маршруты запрещены;
какой solver family можно поставить в очередь;
где нужен refusal;
где результат может быть только observational;
какие deterministic gates потребуются после solver run.

Пример human-readable отчёта

Условный безопасный Markdown-отчёт может выглядеть так:

# Governed Solver Orchestration Report

## Case

- case_id: case_001
- protocol: ecdsa
- AI role: route_planner_and_solver_scheduler_only
- truth_access: false

## Boundary

AI did not receive private fields.
AI did not receive truth nonce fields.
AI did not receive candidate private keys.
AI score is not cryptographic evidence.

## Solver Queue

| Rank | Route | Solver Family | Reason | Claim Boundary |
|---:|---|---|---|---|
| 1 | hnp_window_leakage_check | lattice_hnp | bounded-window signal present | no recovery claim without d·G == P |
| 2 | delta_recurrence_probe | recurrence_analysis | weak repeated-delta support | observational unless exact gate passes |
| 3 | clean_control_refusal_check | none | verify no solver on PRF-like input | refusal is expected |

## Required Integrity Gates

- public-key validation for candidate_d
- protocol verification for candidate signature claims
- redaction scan before export
- claim-boundary scan before publication

Это не “AI решил задачу”.

Это audit trail того, почему система разрешила или запретила дальнейшие действия.

Почему это важно именно для nonce-forensics

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

Например:

Наблюдение	Почему это ещё не claim
есть repeated delta	может быть случайный локальный эффект
есть prefix support	нужен route и null baseline
есть HNP-like форма	надо проверить recoverability
lattice backend вернул короткий вектор	надо декодировать и проверить `d·G == P`
AI считает route перспективным	это только ordering signal
solver нашёл candidate	candidate ещё не private key

В таких системах главная угроза — не ошибка solver’а.

Главная угроза — ложная эскалация статуса:

signal → candidate → recovery claim

без достаточных gates.

Governed orchestration нужен именно для того, чтобы статус не повышался автоматически.

Правильная цепочка:

signal
  → route suggestion
  → solver gate
  → deterministic run
  → deterministic verification
  → redacted evidence
  → claim boundary

Clean control: отказ тоже результат

Один из самых важных принципов системы — clean-control refusal.

Если корпус выглядит как PRF-like/IID и нет solver-ready структуры, правильное поведение не “запустить что-нибудь на всякий случай”, а отказать:

{
  "risk": "clean_control_like",
  "solver_ready": false,
  "recovery_possible": false,
  "solver_runs_on_clean_data": false,
  "passed": true
}

Это может выглядеть скучно, но на самом деле это сильный forensic result.

Почему?

Потому что mature system должна уметь доказывать не только положительные сигналы, но и корректный отказ от ложного вывода.

AI в этом случае тоже не должен “искать любой путь”.

Он должен уметь сказать:

Route: none
Reason: no solver-ready signal under current evidence contract
Claim: observational clean/refusal

Это защищает систему от самого опасного режима: когда solver запускается на шуме, а потом человек пытается интерпретировать шум как открытие.

Bridge starvation: если протокол не дал материала, promotion запрещён

Ещё один важный принцип — bridge starvation.

Если protocol bridge не подтвердил, что входные подписи корректно ложатся в модель, нельзя повышать статус downstream-анализа.

Например, для BIP340 недостаточно увидеть пару (r, s).

Нужно восстановить:

R* = sG - eP

и проверить:

0 <= r < p
0 <= s < n
R* != O
y(R*) is even
x(R*) == r

Если bridge не проходит, AI не имеет права сказать:

всё равно route выглядит перспективным

Правильный статус:

promotion_allowed = false
reason = bridge starvation

AI может объяснить этот отказ, но не может его обойти.

Как это связано с Q-LLL и HNP

Q-LLL в этой системе не является “магической заменой LLL”.

Он может быть solver backend’ом или advisory/backend route внутри HNP-пути.

Но route к Q-LLL должен появляться только тогда, когда feature contract даёт математическое основание:

bounded leakage
known MSB/LSB
short nonce
bounded error
window locality
recoverability sanity

Схема:

feature contract
    → HNP route allowed?
    → recoverability sanity
    → lattice model selection
    → Q-LLL / fplll backend
    → decoder
    → candidate
    → d·G == P

AI может предложить:

поставить HNP route выше recurrence route

Но AI не может сказать:

Q-LLL нашёл правильный ключ

Это может сказать только deterministic verification.

Важная деталь: AI можно заменить

Хороший governed AI layer должен быть заменяемым.

Если завтра вместо Majentik используется другая локальная модель, или вообще rule-based planner, cryptographic truth не должна измениться.

Архитектурный критерий:

замена AI может изменить порядок очереди,
но не может изменить правила acceptance.

То есть:

Что может измениться при замене AI	Что не может измениться
route ordering	public-key validation
rationale wording	protocol verification
suggested follow-up	claim boundary
queue priority	redaction policy
report explanation	deterministic evidence status

Это важное свойство.

Если замена модели меняет cryptographic truth — архитектура неправильная.

Почему это не prompt engineering

Можно было бы сказать: “мы просто написали хороший prompt, где запретили AI принимать ключ”.

Но prompt — это не boundary.

Prompt можно проигнорировать, исказить, неправильно распарсить, случайно изменить.

Governed orchestration должен быть не prompt-слоем, а системным контрактом:

input sanitizer
forbidden-field scanner
role declaration
schema validation
queue-only output
deterministic gates
redaction scan
claim-boundary scan

То есть модель не просто “просим не делать опасное”.

Ей структурно не дают:

secret material;
truth fields;
acceptance endpoint;
authority to emit recovery claim.

Это принципиально другое.

Безопасная схема данных

Условная схема входа:

{
  "case_id": "string",
  "protocol": "ecdsa|bip340|musig2",
  "truth_access": false,
  "integer_only": true,
  "normalized_metrics_used": false,
  "fractional_thresholds_used": false,
  "feature_contract": {
    "group_context": {},
    "public_observables": {},
    "exact_integer_metrics": {},
    "solver_gate_signals": {}
  },
  "forbidden_fields_absent": [
    "private_key",
    "candidate_d",
    "raw_nonce",
    "truth_d",
    "truth_k"
  ]
}

Условная схема выхода:

{
  "case_id": "case_001",
  "ai_role": "route_planner_and_solver_scheduler_only",
  "truth_access": false,
  "acceptance_authority": "deterministic_integrity_gate_only",
  "ai_score_is_cryptographic_evidence": false,
  "solver_queue": [],
  "required_integrity_gates": [],
  "forbidden_claims": [
    "private_key_recovered_by_ai",
    "nonce_recovered_by_ai",
    "recovery_success_without_public_key_validation"
  ]
}

Это скучно в хорошем смысле.

Потому что безопасные криптографические системы должны быть скучными там, где принимаются claims.

Что получает исследователь

Governed solver orchestration даёт несколько практических эффектов.

Проблема	Что даёт слой
много solver variants	строит очередь
трудно объяснить, почему запущен route	пишет rationale
риск ложного recovery narrative	фиксирует claim boundary
AI может галлюцинировать	нет acceptance authority
чистый корпус может получить ложный solver run	clean-control refusal
public/eval/internal контуры смешиваются	truth/private guard
buyer report может звучать слишком агрессивно	buyer-safe wording
сложно воспроизвести ход анализа	JSON + Markdown audit trail

Главный результат:

AI ускоряет triage, но не меняет evidence law.

Что получает покупатель или внешний аудитор

Для внешнего аудитора важно не то, что “в системе есть AI”.

Скорее наоборот: наличие AI обычно повышает тревожность.

Вопрос аудитора будет таким:

Может ли модель повлиять на cryptographic claim?

Правильный ответ:

Нет.
Модель может повлиять только на порядок проверяемых действий.
Acceptance выполняется deterministic verifier’ом.

Это можно выразить как buyer-facing guarantee:

AI cannot accept secrets.
AI cannot produce recovery claims.
AI cannot bypass deterministic gates.
AI output is queue metadata, not cryptographic evidence.

Для serious buyer это звучит намного лучше, чем “у нас AI сам всё анализирует”.

Почему это шире, чем nonce-observatory

Этот паттерн применим не только к криптофорензике.

В high-assurance системах AI почти всегда безопаснее использовать как planner, а не как authority.

Область	AI может	AI не должен
Криптография	планировать solver routes	принимать private key
Формальная верификация	предлагать lemmas	объявлять proof доказанным
Security audit	сортировать findings	подтверждать exploit без проверки
Medicine	предлагать вопросы врачу	ставить окончательный диагноз
Finance risk	ранжировать сценарии	утверждать критическую операцию
Infrastructure	предлагать remediation plan	применять destructive change без gate

Везде одна и та же идея:

AI output becomes a proposal,
not an accepted fact.

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

Этот раздел важнее, чем кажется.

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

AI восстанавливает приватные ключи.

Не утверждаем, что:

AI может заменить cryptographic verifier.

Не утверждаем, что:

AI score является evidence.

Не утверждаем, что:

Q-LLL заменяет LLL/fplll.

Не утверждаем, что:

любой ECDSA/Schnorr/MuSig2 ключ можно восстановить.

Не утверждаем, что:

любой anomaly signal означает уязвимость.

Не утверждаем, что:

route recommendation означает recovery possibility.

Правильная claim boundary такая:

Система может строить public-safe feature contract,
классифицировать nonce-defect signals,
предлагать solver routes,
запускать solver только через gate,
и принимать результат только через deterministic verification.

Итог: AI suggests, exact verifier decides

В этой работе мы не пытались сделать AI умнее криптографии.

Мы сделали обратное:

построили криптографическую систему так, чтобы AI мог быть полезным даже тогда, когда он ошибается.

Он может предложить маршрут.

Он может ошибиться в приоритете.

Он может неудачно объяснить failure mode.

Но он не может:

принять private key;
увидеть truth nonce;
сериализовать candidate_d;
превратить confidence в evidence;
повысить observational signal до recovery claim;
обойти d·G == P.

В криптографии это важнее, чем “умная модель”.

Потому что mature AI layer в high-assurance системе должен быть не оракулом, а управляемым планировщиком внутри формального контура.

Финальная формула всей архитектуры:

AI suggests.
Solver computes.
Exact verifier decides.
Evidence contract speaks.

Именно в таком виде AI становится не угрозой научной честности, а полезным инженерным слоем: он помогает управлять сложностью, но не получает права на истину.

Приложение A. Минимальная evidence-цепочка:

public signatures
      |
      v
protocol bridge
      |
      v
exact feature contract
      |
      v
governed AI route planner
      |
      v
solver queue
      |
      v
solver backend
      |
      v
deterministic integrity gate
      |
      v
redacted evidence
      |
      v
claim boundary report

Главное свойство:

AI расположен до solver run и до acceptance gate.
AI не расположен после candidate как authority.

Приложение B. Минимальный тестовый инвариант:

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

truth_access == false
ai_role == route_planner_and_solver_scheduler_only
ai_accepts_candidate_d == false
ai_accepts_recovery_claim == false
ai_score_is_cryptographic_evidence == false
acceptance_authority == deterministic_integrity_gate_only

Если хотя бы одно из этих утверждений ломается, AI-слой становится небезопасным.

Приложение C. Самая короткая формулировка для README:

Governed Solver Orchestration позволяет локальной AI-модели планировать solver-маршруты по public-safe feature contracts.
AI не получает truth/private/nonce material, не принимает candidate secrets и не формирует recovery claims.
Любое криптографическое принятие результата остаётся за deterministic integrity gates: public-key или protocol verification.

AI, которому запрещено быть правым