feat: опциональные ML-DSA65 post-quantum ключи Reality

[nozikov]

Зачем

Сейчас Reality использует X25519 (классический ECDH). Это надёжно сегодня, но уязвимо к harvest-now-decrypt-later атаке: пробер записывает зашифрованный трафик и расшифровывает его лет через 5-10, когда появятся достаточно мощные квантовые компьютеры (CRQC). Особенно актуально для пользователей в авторитарных режимах — записанный трафик может всплыть позже.

XRAY с какой-то версии (надо проверить) поддерживает ML-DSA65 — post-quantum signature scheme, стандартизированная NIST в 2024. Команда xray mldsa65 генерирует пары Seed/Verify, которые подставляются в Reality realitySettings.

Профит спорный (РКН пока нет CRQC), но это бесплатный hardening — ключ генерится разово, runtime-overhead нулевой.

Подсмотрено в xVRVx/autoXRAY:

key_mldsa65=\$(xray mldsa65)
seed_mldsa65=\$(echo \"\$key_mldsa65\" | awk -F': ' '/Seed/ {print \$2}')
verify_mldsa65=\$(echo \"\$key_mldsa65\" | awk -F': ' '/Verify/ {print \$2}')

Что сделать

research (BLOCKER до начала работы)

1. Проверить, что xray mldsa65 есть в текущей stable-версии xray-core, которую устанавливает наш installer.
2. Прочитать актуальные xray-docs про схему — куда подставлять Seed/Verify в realitySettings (Seed = privateKey-аналог, Verify = publicKey-аналог + клиентский publicKey/pbk).
3. Проверить, что популярные клиенты (Happ, v2rayN, v2rayTun, Shadowrocket) уже умеют ML-DSA65. Это критично — если клиент не понимает, подключение провалится.

реализация (если research OK)

scripts/lib/reality.sh → generate_reality_keypair():

generate_reality_keypair() {
    if [[ \"\$REALITY_PQ\" == \"Y\" ]]; then
        local out=\$(xray mldsa65)
        REALITY_PRIVATE_KEY=\$(echo \"\$out\" | awk -F': ' '/Seed/ {print \$2}')
        REALITY_PUBLIC_KEY=\$(echo \"\$out\" | awk -F': ' '/Verify/ {print \$2}')
    else
        local out=\$(xray x25519)
        # ... как сейчас ...
    fi
}

В setup-exit добавить prompt: «Использовать post-quantum ключи (ML-DSA65)? [N]».

update-скрипты

update-exit.sh / update-relay.sh должны сохранять существующий тип ключа (детектить по длине Seed/Verify vs X25519). Не трогать у тех, у кого X25519, не пытаться upgrade'ить — это сломает существующих клиентов.

Готово, когда

• Research-блок: подтверждено, что N% клиентов поддерживают ML-DSA65
• Опциональный setup-flag работает; defaults на X25519
• E2E на тестовом сервере с поддерживающим клиентом
• Update-скрипты не ломают X25519-серверы

Риск-скрин

Если клиенты не поддерживают ML-DSA65 на момент v1.10.0 — issue парковать в v1.11.0 / v1.12.0, дождаться экосистемы. Не делать default'ом, пока не пройдёт год после релиза в xray.

[nozikov]

Research результаты (май 2026) — паркуем

Server-side (xray-core): готов с v25.7.26.
URL-стандарт: параметр pqv в VLESS sharing link (#716).
Config: mldsaSeed в realitySettings (≠ privateKey, target cert chain ≥ 3500 байт).

Client-side: не готов нигде.

Клиент	Версия	Bundle xray	pqv в parser
v2rayN	7.21.1	v26.4.17	❌
Happ Desktop	2.12.0	v26.3.27	❌
Shadowrocket	2.2.80	свой движок	❌
v2rayTun	—	—	❌

Если включить server-side сейчас, старые клиенты не сломаются (TLS игнорирует неизвестные ExtraExtensions), но и защиты post-quantum не получат — просто +2КБ к каждому handshake без профита.

Бонус: в xVRVx/autoXRAY (источник идеи) поле mldsa65Verify в config — пустая строка. Сгенерированные seed_mldsa65/verify_mldsa65 нигде не используются. Dead code.

Условие размораживания: Happ или v2rayN добавляют pqv в share-link parser (явно в changelog). Тогда возвращаемся — работа на ~1 час.

Снимаю milestone v1.10.0, ставлю label `idea`.