Постквантовый Xray: 14 вопросов о VLESS Encryption и ML-DSA-65 в REALITY

В чужих конфигах Xray всё чаще попадаются две новые сущности: строка "decryption": "mlkem768x25519plus.native.600s..." вместо привычного "none" и пара полей mldsa65Seed / mldsa65Verify внутри realitySettings. Обе появились недавно, обе про постквантовую криптографию, и обе решают разные задачи — из-за чего в чатах регулярно советуют «включи, там квантовое шифрование», не объясняя, от чего именно оно спасает.

Собрал ответы на вопросы, которые задают чаще всего. Фактура — из документации Project X и описания PR, который эту механику принёс.

1. Что именно добавили и когда

Механика приехала в Xray-core пулл-реквестом #5067 — «VLESS protocol: Add lightweight, Post-Quantum ML-KEM-768-based PFS 1-RTT / anti-replay 0-RTT AEAD Encryption» за авторством RPRX. В списке изменений релиза v26.6.1 (1 июня 2026) «VLESS Post-Quantum Encryption» вынесено отдельным пунктом со ссылкой на этот PR.

Параллельно в REALITY появились поля mldsa65Seed (сервер) и mldsa65Verify (клиент) — это уже про подпись, а не про шифрование. Разница между ними — половина всей путаницы вокруг темы, и к ней мы вернёмся в вопросе 10.

2. Разве REALITY и так не шифрует трафик?

Шифрует, но отвечает не за то, о чём обычно думают.

REALITY — это в первую очередь маскировка и аутентификация сервера. Клиент отправляет настоящий TLS ClientHello с SNI постороннего сайта, сервер подсовывает сертификат этого сайта, а для DPI картина выглядит как обычный визит на example.com. Внутри — X25519, короткий идентификатор shortId и проверка того, что сервер действительно ваш, а не подставленный по дороге.

Чего REALITY делать не обязан — защищать вас от последствий утечки клиентского конфига. Именно эту дыру закрывает VLESS Encryption.

Схема на основе документации xtls.github.io и описания PR XTLS/Xray-core#5067

3. От чего страхует VLESS Encryption, чего не делает REALITY

Сценарий, который прямо разбирают в описании PR: конфиг клиента куда-то утёк. Вы отправили ссылку vless:// в мессенджер, скопировали её через буфер обмена на телефоне с «умной» клавиатурой, положили в облачную заметку, отдали знакомому — вариантов масса.

Со старой схемой ("decryption": "none") владелец такого конфига получает всё: он может подключаться, он может — если параллельно писал ваш трафик — расшифровать записанное, он может встать посередине. С VLESS Encryption ключ каждого соединения выводится из эфемерной пары ML-KEM-768 + X25519, сгенерированной на месте, и из содержимого конфига не восстанавливается.

В описании PR это разложено на два уровня. NFS-слой (non-forward-secret) построен на заранее известных публичных ключах и нужен, чтобы промежуточные узлы в цепочке не могли выдать себя за сервер. PFS-слой договаривается о временных ключах на каждое соединение — и даже утечка приватного ключа сервера не даёт задним числом расшифровать записанный трафик. Для сравнения там же прямо названы Shadowsocks 2022 / AEAD и VMess: они держатся на фиксированном PSK и forward secrecy в этом смысле не дают вовсе.

4. Что значит «постквантовый», если квантового компьютера всё равно нет

Угроза здесь не «завтра сломают», а harvest now, decrypt later: трафик пишут сегодня, расшифровывают через N лет, когда появится подходящая машина. Для мессенджера это неактуально, для человека, чей трафик кто-то методично складывает в архив, — вопрос открытый.

ML-KEM-768 — это стандартизованный NIST механизм инкапсуляции ключа (FIPS 203, в девичестве CRYSTALS-Kyber). В mlkem768x25519plus он используется вместе с классическим X25519, а не вместо: гибрид ломается только если сломать обе половины. Это та же логика, по которой браузеры уже несколько лет гоняют X25519MLKEM768 в обычном TLS.

5. Как читается эта длинная строка

Формат — блоки, разделённые точкой, в фиксированном порядке. Одна и та же грамматика для серверного decryption и клиентского encryption, отличаются третий блок и содержимое ключевого хвоста.

Схема на основе xtls.github.io/config/inbounds/vless.html и PR XTLS/Xray-core#5067

Если блоки 4–6 опустить, применяются значения по умолчанию: 100-111-1111.75-0-111.50-0-3333.

6. native, xorpub или random — что выбрать

В описании PR отдельно отмечено, что связка native/xorpub + XTLS ReadV/Splice даёт лучшую производительность, потому что не приходится шифровать поверх уже зашифрованного. То есть если у вас REALITY + Vision — native тут не «слабый вариант», а осознанно правильный.

7. 0-RTT — экономия или дыра

0rtt разрешает клиенту переиспользовать выданный ранее тикет и пропустить полное рукопожатие: первое сообщение с данными уходит сразу. 1rtt всегда делает полный обмен.

Защита от реплея здесь сделана через срок жизни тикета на стороне сервера (по умолчанию около 10 минут), а не через сверку времени между клиентом и сервером. Практическая разница: вам не нужно ловить рассинхрон часов на роутере или телефоне — типовую боль Shadowsocks-AEAD и старых схем с maxTimeDiff.

8. Как сгенерировать ключи

Самый короткий путь — одна команда, которая выдаёт сразу согласованную пару строк для сервера и клиента:

./xray vlessenc

Ручной путь, если нужно контролировать каждый блок:

./xray x25519      # пара X25519: PrivateKey для сервера, Password для клиента
./xray mlkem768    # Seed для сервера и клиентская часть
./xray uuid        # UUID пользователя, если создаёте нового

shortIds для REALITY — это hex чётной длины, до 8 байт (16 hex-символов) включительно.

9. Как выглядит рабочий конфиг

Серверный inbound — VLESS с Vision поверх XHTTP и REALITY:

{
  "listen": "0.0.0.0",
  "port": 443,
  "protocol": "vless",
  "settings": {
    "clients": [
      { "id": "<UUID>", "flow": "xtls-rprx-vision" }
    ],
    "decryption": "mlkem768x25519plus.native.600s.<X25519 PrivateKey>.<ML-KEM-768 Seed>"
  },
  "streamSettings": {
    "network": "xhttp",
    "security": "reality",
    "realitySettings": {
      "target": "example.com:443",
      "serverNames": ["example.com"],
      "privateKey": "<REALITY PrivateKey>",
      "shortIds": ["0123456789abcdef"]
    },
    "xhttpSettings": { "path": "/<случайный путь>" }
  }
}

Клиентская сторона — зеркально:

{
  "protocol": "vless",
  "settings": {
    "vnext": [{
      "address": "<ваш IP или домен>",
      "port": 443,
      "users": [{
        "id": "<UUID>",
        "flow": "xtls-rprx-vision",
        "encryption": "mlkem768x25519plus.native.0rtt.<X25519 Password>.<ML-KEM-768 Client>"
      }]
    }]
  }
}

10. Тогда что такое mldsa65Seed и mldsa65Verify

Это уже не про шифрование канала, а про подпись сертификата, которым REALITY представляется клиенту.

• mldsa65Seed на сервере — приватный ключ, которым к сертификату добавляется вторая, постквантовая подпись по ML-DSA-65 (FIPS 204).
• mldsa65Verify на клиенте — публичная часть, которой эта подпись проверяется.

Смысл: аутентификация сервера в REALITY исторически держится на X25519, и её ломает тот же гипотетический квантовый противник. ML-DSA-65 добавляет параллельный механизм, который таким противником не ломается. Если поле не заполнено — работает старая схема, всё как раньше.

11. Справочник полей REALITY — что там вообще есть

Разбор самого механизма REALITY — в отдельной теме: Гайд: как работает Reality (XTLS) и почему он обходит DPI.

12. Насколько это дорого по скорости

В описании PR приводятся два аргумента. Первый: у VLESS Encryption нет отдельного поля длины AEAD, за счёт чего заявлен выигрыш около 10 % относительно Shadowsocks 2022. Второй: при включённом XTLS повторной расшифровки проксируемого TLSv1.3 не происходит вовсе — на Linux работает splice на уровне ядра, и трафик идёт почти на нативной скорости.

Отдельно упомянуто ограничение размера пакета — 8K, позже 16K, — введённое ради того, чтобы не копировать буферы лишний раз.

13. Что сломается у клиентов

Главный риск — не криптография, а совместимость. Строка encryption — поле уровня ядра Xray, и клиент, который её не понимает, просто не подключится. В обсуждениях сообщества прямым текстом рекомендуют держать для таких пользователей отдельный inbound с классической схемой vless + vision + reality.

Практический порядок действий:

Отдельно: mlkem768x25519plus — это конструкция Xray-core. Не переносите строку в конфиг другого ядра «по аналогии»; если у вас клиенты на sing-box или mihomo, сверяйтесь с их собственной документацией и не считайте поддержку данностью. Про маршрутизацию в sing-box у нас есть разбор по слоям.

14. Так включать сейчас или подождать

Взвешенно: включать имеет смысл, если вы раздаёте конфиги людям, которые точно перешлют их в мессенджере. Именно этот сценарий даёт реальный выигрыш уже сегодня — вне зависимости от того, когда и появится ли вообще квантовый компьютер.

Не имеет смысла торопиться, если у вас разношёрстный зоопарк клиентов, которые вы не контролируете, а поддержку обновлений некому оказывать. Ломать работающее ради страховки от гипотетической угрозы — плохой размен.

И общая оговорка, которая касается любого туннеля: всё описанное защищает канал до вашего сервера. Что происходит после сервера, и что вы сами отправили в чужой сервис поверх этого канала, ни ML-KEM, ни ML-DSA не лечат.

Если что-то в цепочке всё-таки не работает — есть отдельный справочник «симптом → причина → что делать».

Источники

• PR XTLS/Xray-core#5067 — VLESS protocol: Post-Quantum ML-KEM-768-based PFS / anti-replay 0-RTT AEAD Encryption
• Релизы Xray-core (v26.6.1, 1 июня 2026)
• Документация Project X: VLESS, поле decryption
• Документация Project X: VLESS outbound, поле encryption
• Документация Project X: REALITY
• XTLS/Xray-core Discussion #5372 — минимальная конфигурация vlessenc + vision + xhttp + reality