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

Как мы встроили 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 keyAI score ≠ cryptographic evidence

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

d · G == P

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

---

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

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

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

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

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

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

rule-based direct algebrabounded searchHNP lattice routefplllQ-LLLcustom decodercross-signature votepublic-key validation

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

feature_contract.jsonrisk_ranking.jsonsolver_report.jsonredacted_solver_report.jsonclaim_boundary_report.jsonai_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      |      vAI analysis      |      v"candidate key seems valid"      |      vrecovery 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 может принять 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 keyraw noncetruth dtruth kcandidate secretunredacted solver material

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

---

Что AI выдаёт

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

candidate_d = ...private key recoverednonce recoveredrecovery 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      |      vdeterministic integrity gate      |      vcandidate 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 - ePR* != Ohas_even_y(R*) == truex(R*) == r0 <= r < p0 <= 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## BoundaryAI 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 опасна тем, что у неё есть много промежуточных состояний, которые выглядят впечатляюще, но ещё ничего не доказывают.

Например:

В таких системах главная угроза — не ошибка 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: noneReason: no solver-ready signal under current evidence contractClaim: observational clean/refusal

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

---

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

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

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

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

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

R* = sG - eP

и проверить:

0 <= r < p0 <= s < nR* != Oy(R*) is evenx(R*) == r

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

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

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

promotion_allowed = falsereason = bridge starvation

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

---

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

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

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

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

bounded leakageknown MSB/LSBshort noncebounded errorwindow localityrecoverability 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.

То есть:

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

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

---

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

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

Но prompt — это не boundary.

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

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

input sanitizerforbidden-field scannerrole declarationschema validationqueue-only outputdeterministic gatesredaction scanclaim-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 даёт несколько практических эффектов.

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

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 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      |      vprotocol bridge      |      vexact feature contract      |      vgoverned AI route planner      |      vsolver queue      |      vsolver backend      |      vdeterministic integrity gate      |      vredacted evidence      |      vclaim boundary report

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

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

---

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

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

truth_access == falseai_role == route_planner_and_solver_scheduler_onlyai_accepts_candidate_d == falseai_accepts_recovery_claim == falseai_score_is_cryptographic_evidence == falseacceptance_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.