montana/Формальная Документация/13 Приватный Финансовый Слой Монеро-Монтана/Постквантовые-замены.md

199 lines
11 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

# Постквантовые замены Monero-примитивов
**Версия:** 1.0 draft
**Цель:** для каждого ключевого Monero-примитива — конкретная PQ-замена с обоснованием выбора и known-tradeoffs.
## Сводная таблица
| Monero (классический) | PQ-замена в Монеро-Монтане | Источник | Готовность |
|------------------------|----------------------------|----------|------------|
| CLSAG ring signature (Ed25519) | Lattice ring signature (MatRiCT+ или новейшая) | Esgin-Steinfeld-Sun 2019, MatRiCT+ 2022 | Research, не production |
| Stealth addresses (curve25519 DH) | PQ stealth via ML-KEM-768 KEM | NIST FIPS 203 | Готов, нужна формализация derivation |
| Pedersen commitment + Bulletproofs (SECP) | Lattice commitment + Lattice range proof | Esgin-Nguyen-Seiler 2020, Lyubashevsky-Nguyen-Plançon 2022 | Research, тяжёлая |
| Triptych anonymity (next-gen) | Lattice-based аналог | Не существует production-ready | TBD |
| EdDSA (transaction signatures) | ML-DSA-65 (FIPS 204) | NIST 2024 | Production-ready |
| SHA-3 (some hashes) | SHA-256 (consistent с TimeChain) | NIST FIPS 180-4 | Production-ready |
## 1. Ring Signature: CLSAG → Lattice Ring Signature
### Что делает CLSAG в Monero
Подписант доказывает что он один из K=11 потенциальных подписантов из anonymity set без раскрытия конкретного. Использует Ed25519 + Schnorr-подобную конструкцию + linkability tag для предотвращения двойного подписания.
### Почему нужна замена
Ed25519 базируется на эллиптической кривой (curve25519). Алгоритм Шора ломает дискретный логарифм за полиномиальное время → ring signature становится тривиально проследимой при появлении достаточно мощного квантового компьютера.
### MatRiCT+ как кандидат
Esgin et al. (2022) предложили improved version их 2019-й работы. Параметры:
- Категория безопасности: NIST L3 (≥192 бит классических, ≥128 квантовых).
- Размер подписи: ~520 КБ (в зависимости от K). Bigger чем Monero CLSAG ~0.5 КБ, но в пределах разумного.
- Время подписания: ~100500 мс на современном CPU.
- Время верификации: ~50200 мс.
### Альтернативы
- **Mubarak-Shen 2024** и другие более поздние lattice ring signatures — могут быть лучше по размеру, но менее проверены.
- **One-out-of-many SNARK** — теоретически возможно, но требует trusted setup или post-quantum SNARK с большим overhead.
### Решение
Использовать MatRiCT+ как baseline, мониторить новые публикации каждые 6 месяцев. Если появится production-grade implementation с лучшими параметрами — мигрировать через MIP в [12 Управление](../12%20Управление%20и%20Обновления/).
### Открытые вопросы
- Готовая audited implementation на Rust? Нет. Нужен либо port from C++ research code, либо самостоятельная реализация. Это значимый риск (см. F-01 в [Internal Audit](../09%20Внешний%20Аудит/Internal-Audit-2026-05-04.md)).
- Совместимость с lightweight clients (мобильные кошельки)? Требует оптимизации.
## 2. Stealth Addresses: curve25519 DH → ML-KEM-768
### Что делают stealth addresses в Monero
Получатель публикует одну пару ключей (view, spend). Отправитель генерирует one-time public key для конкретной транзакции через DH-протокол:
```
r = random scalar
R = r·G (опубликовано в transaction)
P = Hash(r·V)·G + S (target one-time address)
```
Получатель сканирует транзакции, проверяет принадлежность через свой view-secret-key.
### PQ адаптация через ML-KEM-768
Заменяем DH на key encapsulation:
```
(view_pk, view_sk) ← ML-KEM-768 keygen()
(spend_pk, spend_sk) ← ML-DSA-65 keygen()
Sender:
(ct, K) ← ML-KEM-768 encapsulate(view_pk)
one_time_addr = spend_pk + Hash(K)·G_PQ # G_PQ — generator в lattice space
Publish (one_time_addr, ct) on chain.
Recipient (scan):
K' ← ML-KEM-768 decapsulate(view_sk, ct)
expected = spend_pk + Hash(K')·G_PQ
if expected == one_time_addr: this transaction is mine.
```
### Параметры
- ML-KEM-768 ciphertext: 1088 байт.
- ML-KEM-768 public key: 1184 байт.
- Размер one-time-address packet: ~1.5 КБ vs ~64 байт классический Monero.
### Открытые вопросы
- Корректность derivation `spend_pk + Hash(K)·G_PQ` в lattice space — нужна формальная проверка что this preserves ML-DSA-65 EUF-CMA.
- Sub-address scheme (Monero supports multiple stealth addresses from one base) — нужна PQ-адаптация.
## 3. Range Proofs: Bulletproofs → Lattice Range Proofs
### Что делают Bulletproofs в Monero
Доказательство `0 ≤ amount < 2^64` без раскрытия amount. Использует Pedersen commitments + inner-product argument на эллиптической кривой.
Параметры Monero (post-2018):
- Размер: ~675 байт для одного output.
- Время верификации: ~5 мс.
### PQ замены
#### 3.1 Esgin-Nguyen-Seiler 2020
Lattice-based exact proofs через amortized SIS protocol.
- Размер: ~515 КБ за range proof.
- Время верификации: ~50100 мс.
#### 3.2 Lyubashevsky-Nguyen-Plançon 2022
Improvement предыдущих lattice proofs.
- Размер: ~310 КБ.
- Время верификации: ~3080 мс.
#### 3.3 SNARK-based PQ (e.g. STARK)
STARKs пост-квантовы по построению (hash-based).
- Размер: ~50200 КБ (большой!).
- Время верификации: ~520 мс (очень быстро благодаря logarithmic).
- Trusted setup: НЕ нужен (это плюс).
### Решение
Lyubashevsky-Nguyen-Plançon как baseline. STARKs как fallback если lattice не reach acceptable size.
### Trade-off
PQ range proofs **значительно тяжелее** Bulletproofs:
- Размер: 310× больше.
- Verifier time: 620× больше.
Это означает что throughput приватного слоя меньше public Montana. Это **сознательное** решение — приватность стоит производительности.
## 4. Подписи: Ed25519 → ML-DSA-65
Уже решено в основной спецификации Монтаны. ML-DSA-65 (FIPS 204) — production-ready.
| Параметр | Ed25519 | ML-DSA-65 |
|----------|---------|-----------|
| Public key | 32 байт | 1952 байт |
| Подпись | 64 байт | 3309 байт |
| Уровень безопасности | 128 бит классических, **0 квантовых** | 192 классических, 128 квантовых |
## 5. Хеш-функции
Унификация: SHA-256 везде где это разумно. Monero использует Keccak; Montana использует SHA-256 (соответствует FIPS 180-4 и используется в VDF). При интеграции на boundary — convertor.
## 6. Сводный анализ trade-off
```
Размер транзакции:
Public Monero: ~23 КБ
Public Montana: ~5 КБ
Монеро-Монтана: ~50100 КБ (1020× public Montana)
Время верификации одной транзакции:
Public Monero: ~10 мс
Public Montana: ~5 мс
Монеро-Монтана: ~100500 мс (20100× public Montana)
Throughput транзакций в окне τ₁=60с:
Public Monero: ~10⁴+ tx/блок
Public Montana: ~10⁴+ tx/окно
Монеро-Монтана: ~100 tx/окно (consensus bottleneck — verification time)
```
**Это значит:** приватный слой имеет существенно меньшую пропускную способность чем публичный. Это **honest trade-off** — приватность дорогая.
## 7. Открытые направления исследований
- [ ] Bench MatRiCT+ vs newer schemes — какая лучше для Монтаны.
- [ ] Реальная implementation хотя бы reference в Rust (нет готовых сейчас).
- [ ] Audited cryptographic library с PQ ring sigs (нет в open-source проектах).
- [ ] Optimization range proofs: targeting <5 КБ.
- [ ] Compatibility с mobile/lightweight clients.
## 8. Связанные документы
- [Архитектура](Архитектура.md) где эти примитивы используются.
- [02 Криптография](../02%20Криптография/) базовые PQ-примитивы Монтаны.
- [09 Внешний аудит](../09%20Внешний%20Аудит/) F-01 single-implementation risk применим к этим примитивам тоже.
- [Вызов Монеро-сообществу](Вызов-Монеро-сообществу.md) приглашение к рецензии этих choices.
## 9. Источники
1. Esgin, M. F., Steinfeld, R., Sun, S.-F., et al. (2019). *MatRiCT*. CCS.
2. Esgin, M. F., et al. (2022). *MatRiCT+*. (newer revision).
3. Esgin, M. F., Nguyen, N. K., Seiler, G. (2020). *Practical Exact Proofs from Lattices*. ASIACRYPT.
4. Lyubashevsky, V., Nguyen, N. K., Plançon, M. (2022). *Lattice-Based Zero-Knowledge Proofs and Applications*. EUROCRYPT.
5. Bünz, B., et al. (2018). *Bulletproofs*. IEEE S&P. (для контекста сравнения)
6. Goodell, B., Noether, S., Blue, A. (2020). *CLSAG*. (для контекста сравнения)
7. Ben-Sasson, E., et al. (2018). *Scalable, transparent, and post-quantum secure computational integrity* (STARK).