Как мы встроили 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.
-Источник
