Введение

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

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

Относительно недавно (13 августа 2024 года) NIST опубликовала окончательные версии трёх постквантовых стандартов, в список которых вошли такие алгоритмы как Kyber, Dilithium, Sphincs+, переименованные далее как ML-KEM, ML-DSA и SLH-DSA соответственно. На основе такого благоприятного события я решил перевести анонимную сеть Hidden Lake на алгоритмы постквантовой криптографии и показать с какими особенностями столкнулся при переходе.

Вкратце о Hidden Lake

Анонимная сеть Hidden Lake (HL) - это децентрализованная F2F (friend-to-friend) анонимная сеть с теоретической доказуемостью на базе очередей (QB-задача). В отличие от известных анонимных сетей, подобия Tor, I2P, Mixminion, Crowds и т.п., сеть HL способна противостоять атакам глобального наблюдателя. Сети Hidden Lake для анонимизации своего трафика не важны такие критерии как: 1) уровень сетевой централизации, 2) количество узлов, 3) расположение узлов и 4) связь между узлами в сети.

Более подробный анализ сети Hidden Lake можно найти в работе:
-> Анонимная сеть «Hidden Lake».

Репозиторий Hidden Lake: https://github.com/number571/hidden-lake
Репозиторий проекта go-peer: https://github.com/number571/go-peer

QB-задача

Задача на базе очередей может быть описана следующим списком действий:

  1. Каждое сообщение m шифруется ключом получателя k: c = Ek(m),

  2. Сообщение c отправляется в период = T всем участникам сети,

  3. Период T одного участника независим от периодов T1, T2, ..., Tn других участников,

  4. Если на период T сообщения не существует, то в сеть отправляется ложное сообщение v без получателя (со случайным ключом r): c = Er(v),

  5. Каждый участник пытается расшифровать принятое им сообщение из сети: m = Dk(c).

QB-сеть с тремя узлами A, B, C
QB-сеть с тремя узлами A, B, C

Для любых пассивных наблюдателей, включая и глобального наблюдателя, QB-задача считается трудновыполнимой, потому как она скрывает не только связь между узлами, но и состояние таковых узлов: 1) отправляет ли анализируемый узел какие-нибудь сообщения?; 2) принимает их?; 3) или вовсе бездействует? - таковые вопросы порождает задача.

Функция шифрования

Функция шифрования E в сети Hidden Lake состоит из двух этапов:
1. Шифрование сообщения с аутентификацией по асимметричным ключам E',
2. Шифрование сообщения с аутентификацией по симметричным ключам E''.

E(k, privA, pubB)(m) = E''k(E'(privA, pubB)(m)), где
privA - приватный ключ Алисы
pubB - публичный ключ Боба
m - открытый текст
E'' - второй этап шифрования
E' - первый этап шифрования

Первый этап является базовым в концепте безопасности и анонимизации трафика сети. Он исполняет роль привязки сообщения к конкретному узлу по его публичному идентификатору (ключу), а также приводит сообщение к статичному размеру, чтобы нивелировать атаки по длине передаваемых данных.

E'(privA,pubB)(m) = (EpubB(k') || Ek'(pubA || s || h || SprivA(h) || m')), где
h = Hmac(s)(pubA || pubB || m') - хеш-сумма
Hmac - код аутентификации сообщения на базе хеш-функции
m' - расширенное сообщение до статичного размера
pubA - публичный ключ Алисы
pubB - публичный ключ Боба
SprivA - функция подписи
priva - приватный ключ Алисы
s - криптографическая соль
k' - случайный сеансовый ключ шифрования на одно сообщение
Ek' - функция симметричного шифрования
EpubB - функция асимметричного шифрования (механизм инкапсуляции ключа)

Второй этап является базовым в концепте изоляции сети от других сетей. Он исполняет роль разграничения узлов по их привязке к группе, используя для этого сетевой ключ. Это становится необходимо, т.к. QB-задача имеет проблему масштабируемости, где нагрузка на систему начинает зависеть линейно от количества участников в ней располагаемых. Также данный этап приводит сообщение к динамичному размеру, чтобы нивелировать атаки на определение анонимизированного трафика по статичной длине сообщений.

E"k(m) = Ek(p(h) || h || mv), где
h = Hmac(k)(mv) - хеш-сумма
mv = (m || v) - конкатенация сообщения m и случайных байт v
p - функция доказательства работы
k - сетевой ключ

Используемые криптографические примитивы

В качестве функции симметричного шифрования использовался алгоритм AES-256 в режиме шифрования CFB (обратная связь по шифртексту). В качестве хеш-функции использовался алгоритм SHA-256, а также на его основе HMAC. В качестве функции асимметричного шифрования использовался RSA-OAEP, а в качестве функции подписи использовался RSA-PSS. При этом для обеих схем применялся один 4096-битный ключ, что являлось вполне допустимым, т.к. схемы OAEP, PSS позволяли разделять логику ключа.

Из используемых выше примитивов наиболее слабым оказался RSA, т.к. его безопасность напрямую зависит от успеха разработки квантовых компьютеров. Помимо RSA, хеш-функция SHA-256 в теории также становится более слабой, т.к. есть предположения, что алгоритм Гровера будет способен производить атаку парадокса дней рождения более эффективно: не за 2n/2, а за 2n/3 операций. Таким образом, безопасность SHA-256 к атакам перебора становится равной не 128-бит, а 85.(3)-бит, что является уже ненадёжным. Алгоритм AES-256 является наиболее безопасным примитивом, потому как даже воспользовавшись алгоритмом Гровера, безопасность схемы уменьшится с 2n до 2n/2, но останется на приемлемом 128-битном уровне.

Переход на постквантовые алгоритмы

Обезопасить хеш-функцию достаточно легко - нужно лишь просто заменить SHA-256 на SHA-384 или SHA-512 из того же семейства, чтобы далее минимальный уровень безопасности стал не меньше 128-бит. С алгоритмом RSA же ситуация более сложная, т.к. его безопасность не может быть улучшена на долгосрочную перспективу простым увеличением длины ключа. Предполагается, что квантовый компьютер начнёт успешно взламывать RSA лишь с той поры, как только количество его стабильных кубитов станет равно 2n+3, где n - длина ключа. Таким образом, сложность взлома RSA будет расти линейно O(n) длине ключа, а не экспонционально O(2n).

  • Хоть в качестве примера я всегда приводил RSA, но данная атака (алгоритмом Шора) может быть распространена на любой другой вид широко применяемых асимметричных алгоритмов, базируемых либо на задаче факторизации (RSA, схема Рабина), либо на задаче дискретного логарифмирования (протокол Диффи-Хеллмана, схема Эль-Гамаля), включая интерпретацию на эллиптических кривых (ECDH, ECDSA, ECIES, ...).

Помыслы о переводе сети Hidden Lake на постквантовую криптографию начались - забавно, но за день до финальной стандартизации квантовоустойчивых криптографических алгоритмов. В этот период времени было несколько концепций того, как продолжить развитие проекта:

  1. Продолжать использовать старый добрый RSA. На первый взгляд это кажется очень странно и недальновидно, но при этом здесь есть логика. Во-первых, код с RSA уже написан и протестирован, во-вторых, даже если квантовые компьютеры будут созданы - они в первую очередь будут взламывать RSA ключи меньшего размера - 1024, 2048 и 3072, в-третьих, основная практическая проблематика, лежащая перед разработчиками квантовых компьютеров, находится в плоскости успешного и долговременного связывания кубитов. Если мы примем за аксиому, что разработка квантовых компьютеров ведётся преимущественно открыто, тогда при первых же успешных взломах RSA у нас будет время перейти на квантовоустойчивые схемы. Данный концепт можно описать просто - «не паниковать раньше времени», ну или «когда ужалит, вот тогда ...»
    Проблема данного подхода даже не в том, что квантовые компьютеры могут разрабатываться преимущественно скрытым образом, как то, что для атаки нужно лишь сохранять шифртексты "сегодня" (когда ещё нет мощных квантовых компьютеров), а использовать их "завтра" (когда квантовые компьютеры с большим количеством кубит и их хорошей стабилизацией будут созданы).

  2. Перейти полностью на симметричную криптографию. Возможно это один из самых противоречивых и одновременно один из самых консервативных способов борьбы с квантовыми компьютерами - просто удалить всю асимметрию. Так как QB-задача не привязана к конкретным алгоритмам шифрования, она может относительно легко руководствоваться лишь симметричными шифрами. В результате такого концепта, общая система фактически регрессирует, вступая в проблему старой классической криптографии о безопасной передаче ключа шифрования. Можно было бы использовать другие программы для передачи симметричных ключей по типу GPG, но и они должны быть квантовоустойчивыми, иначе смысла от перехода на симметричную криптографию никакого нет. Но в таком случае, раз мы должны так или иначе использовать квантовоустойчивые асимметричные алгоритмы, может тогда самолично их имплементировать, чтобы не привязывать дополнительные приложения?

  3. Перейти полноценно на новые постквантовые алгоритмы. Это классический и в перспективе самый правильный способ перехода приложений на новые и более безопасные криптоалгоритмы. При этом, двухэтапная функция шифрования сети Hidden Lake никак не будет изменена в своём абстрактном / формальном представлении. Но у такого подхода также имеются недостатки:
    1) Представленные NIST алгоритмы очень новы для такой консервативной науки как криптография. Потенциально в них могут быть найдены ещё неизвестные ныне уязвимости, которые будут полностью рушить безопасность всей системы. Так произошло с алгоритмом SIKE, который был взломан классическим компьютером в начале августа 2022 года.
    2) Два из трёх стандартизированных алгоритма базируются на теории решёток, где взлом одного может повлечь и взлом другого. При этом, оставшийся третий алгоритм - SPHINCS+ (базируемый на хеш-функциях) способен лишь создавать цифровые подписи, но не шифровать сообщения / не инкапсулировать ключи. Таким образом, в настоящее время не существует стандартизированных альтернатив KEM'а (key encapsulation mechanism), кроме ML-KEM'а (Kyber'а).
    3) Объём / размер асимметричных ключей, а также результатов шифрования / подписания сильно увеличивается. Так например, ключ RSA-3072, обеспечивающий 128-битный уровень безопасности, в закодированном состоянии (PKCS1) занимает 1767 (приватный) и 398 (публичный) байт. Такой же 128-битный уровень безопасности для алгоритмов ML-KEM-512 и ML-DSA-44 занимает 1632 (приватный ML-KEM), 800 (публичный ML-KEM) и 2560 (приватный ML-DSA), 1312 (публичный ML-DSA) байт соответственно. Проблема продолжается в том, что необходимо применять сразу два алгоритма - и шифрования, и подписания. Из-за этого длины ключей суммируются, и теперь необходимо хранить 4192 (приватный ML-KEM+ML-DSA) и 2112 (публичный ML-KEM+ML-DSA) байт. Размер шифрованных (OAEP) и подписанных (PSS) байт для RSA-3072 статичен и равен 384 байт. Для ML-KEM-512 размер инкапсулированного ключа равен 768 байт. Для ML-DSA-44 размер подписи равен 2420 байт. Итого, если необходимо подписать сообщение, а далее его зашифровать - необходимо припасти 3188 байт (ML-KEM+ML-DSA) вместо 768 (RSA-OAEP+RSA-PSS). И всё это я сравнивал с RSA - одним из самых объёмных алгоритмов по выходу и длине ключа (объёмнее только чистые схемы Эль-Гамаля). С алгоритмами эллиптической криптографии - так вообще страшно сравнивать.

Как видно все три варианта не то чтобы идеальны. Если исходить из простоты и надеяться на открытые сведения о развитии квантовых компьютеров, то наиболее подходящим является первый концепт. Если исходить из того, что сведения о развитии квантовых компьютеров в открытом доступе скорее всего старые, а квантовые компьютеры могут взламывать конфиденциальную информацию уже сейчас, даже при условии, что они ещё не изобретены (угроза "Собери сейчас, взломай потом"), то в долгосрочной перспективе лучше конечно выбрать третий вариант. Второй концепт очень специфичен, так как фактически он никак не борется с квантовыми компьютерами, а лишь переносит зону ответственности на сторонние приложения. Хоть система и становится в конечном счёте более "чистой" при таком переносе (в том плане, что система действительно обретает иммунитет к атакам квантового компьютера за счёт отсутствия асимметрии), но при этом очень сильно теряется удобство использования.

При всех имеющихся недостатках третьего концепта, сеть HL всё же перешла на постквантовые алгоритмы ML-KEM-768 и ML-DSA-65 (использовав cloudflare/circl реализацию для языка Go), заменив собой RSA-4096. Я руководствовался тем фактом, что лучше довериться в безопасность новых криптографических алгоритмов и смириться с большой длиной ключа / результатов шифрования+подписания, чем со 100% гарантией раскрытия нынешних и будущих сообщений квантовыми компьютерами.

Выбор ML-KEM-768 и ML-DSA-65 (192-битный уровень защиты) вместо ML-KEM-512 и ML-DSA-44 (128-битный уровень защиты) был сделан с консервативной точки зрения, чего также рекомендуют делать и авторы данных алгоритмов (1, 2). Помимо рекомендации, 192-битный уровень действительно необходим сети Hidden Lake, т.к. каждое отправляемое сообщение обязательно должно использовать оба этих алгоритма с неизменными ключами, чего нельзя сказать о симметричном алгоритме AES-256, ключ которого генерируется под каждое новое сообщение на первом этапе шифрования.

Последствия перехода

Самым негативным последствием перехода на постквантовую криптографию стало уменьшение полезной нагрузки с 6.5KiB до 1.7KiB при неизменном 8KiB сообщении. Функция шифрования была спроектирована таким образом, чтобы не формировать сеансы связи, поэтому сохранять коммуникацию между абонентами становится возможным лишь посредством непосредственной и постоянной передачи инкапсулированного сеансового ключа (генерируемого ML-KEM) и идентификатора (публичного ключа ML-DSA) в самом сообщении.

Другим негативным качеством стало разделение идентификации личности на два асимметричных ключа ML-KEM и ML-DSA, в то время как раньше применялся один ключ RSA, но с разными схемами кодирования OAEP и PSS. Последний случай позволял указывать собеседнику лишь один ключ, сейчас же необходимо указывать два. Ситуация приводит к тому, что меняются интерфейсы шифрования и расшифрования сообщений:

// При RSA
type IClient interface {
	...
	EncryptMessage(asymmetric.IPubKey, []byte) ([]byte, error)
	DecryptMessage([]byte) (asymmetric.IPubKey, []byte, error)
}
// При ML-KEM, ML-DSA
type IClient interface {
	...
	EncryptMessage(asymmetric.IKEMPubKey, []byte) ([]byte, error)
	DecryptMessage([]byte) (asymmetric.IDSAPubKey, []byte, error)
}

Из-за данного изменения, приложения выполняющие маршрутизацию должны уметь соотносить один публичный ключ к другому посредством их связывания к одной личности. Можно конечно вернуть старый интерфейс, но в таком случае: 1) аргумент IPubKey в EncryptMessage станет излишним, т.к. не будет применяться IDSAPubKey, 2) результат IPubKey в DecryptMessage приведёт к увеличению размера сообщения, т.к. потребует сохранять два ключа в шифртексте, вместо одного. По этой причине в консольном мессенджере secpy-chat (базируемом на сервисах HLT, HLE сети Hidden Lake) пришлось изменять логику исполнения из-за изменённого yml файла:

# При RSA
Alice: PubKey{3082020A0282020100A5441C70EF416118C69B0E4465DEAA56050B150AFFCB780A92C70948C47236DEF0EED9B29DAB5FAD714F5D4F3A4317A11B6AEC55790C549E755A2E8BF1E56CBF8CFB4E799E04D75FE9C8CB5132F0060672A50879CEE5A007A96B1E6D8BAAA11D6BC473D1644C47208920299D7C5E9759BBA436209F1807123B2416A1A242E682AACDDD3E6E94C19298EA5DD1F5F29D0F24CFAC894101E8CEA123D9C2E1913D4B2EAFE8BC6EE569CB5CF65481B732818778F0ACCECDC74EDD8B6AA54CB6FFD50F67CFC65090A7D8DB88F3AE37DBB6A7E7ED37C7FE3BE786A33C361ACFE85C730A63C7C67D74E1A060BE6E33A504D3F978DCD0FDB162BFACD8458FB3F6144465D95F9C96F2B44A578ED397668112EE5EAF8544F047CD30B6EBD3CFEA8493698996BF22C720989B9CBB706B6A2DBC9002DAE3300A8EAC92FE9327C1B5E9613322C03F9DBA58E8BC6998810E2F15A24C2ABFA4A58F45F1913685A75C658A3A5570523642CDBB721A79D55812D9F209A33F14BB3145D30F41B8C400DAD856C592A8E8FF8133948C75B8F4081558494CEB20F90405750603D95E2117331DBCD7CDED6F58DA65FE77764D881E0C41155AA37C4E304D8B2946ADC3A896937D799ED1F49BDD655E15292C35CCCCAEB61C8A8D69AA97FC3B0FCCC131B39E184007C84CF7C1F06FF0F26216E9F353F06272C86E6F983E8A061EA7132704091546325D3324D10203010001}
# При ML-KEM, ML-DSA
Alice: [
    2f964ce591c3bb9421bc68886f28063df201f9b361378987435731c18274a889af199098c4d43e3417bea6c20f18d46f9f9c03705a394fa05f59b162fd649538a1c293ab04f610c3e3f355ec09c350838d6e473872727b1197725d4a2bea50888918586d9a140ccc526ba6379c36cb1bb26f32c87843442dce8911f33284839a0c7af1b7fa090c3ae1c061582ba9557645a33df1b6ccd2a212348b8ee3964436c866cea58b58e0196b8583d46202677a303ddc869d687576c8b26364adec19b49a476216e12319a68e7dda8bae5257ddd48b036920d7e44af99b5bc468c2432b1100a672323818e5f0b4a84a5a20111bd6b870ee81b949537efc29859aa4642e6a5b947103fa1033ace95476aa9b888113f6c059249496d4b4113ed4a64c120e3b24ca662549559b592be33106fa7fac915b1072180a259a2a49098b256af99b2f9b8a4bcf1912d0343c91b5295be2723533a139824a8af5c51d787c38690a5f0bc230a047a99911e2fa7d9e9c465ffbc6f151812c08a308837b6df1b71590b6c5b33a1066390f658d02f214afa73b67031279646443528500e2765ec05a6a9184fdc39bee649acca1029f18b18445786110c47c1264c6a1a056e315d4359f0ef89d1d3a5f839c17eb9c9f60f7234439760ab72bd6d661670866451130a7c84893d429c4950105461683f5b891a37ecd318624a178010aa6c54c5cb6f5107a6c495a25b31be16c55e2cb642a6ddac77534c3411f7c4f89f8c619d87d326628c85a5ca1567c336098f9611b8df49906524e36509aa71a8a69fc2e61503d0f786cb37162a06ac97f042ccdd0ca2c45601f220684f5114f767927806d66378d33b26f0b807131891305d53c1b5a6d9b144777db270053bbc6a94b82707d831b58489376b1c8362466121bc77fad5956198bc049c588e7a03644f8ad75f66cb7c3a449aacdf55421c61703ce286a0e980c6ff24d8f958d3fa0a88f5177e90ac938f190ead1c00307cf0578223a97b0fe64794eb55a3512a3d39b80755b4a15b7c67a3c5eb3ca171ecbbd8ef46a9eec0c593349c88655fd9844797b6c7b041188e7832d2981264b5f0bc0a073b3a2b3a48d29d0b8a850c4d1816b894b7fec1a58ccb0a86e971263651821e72ca1bc78d58a1cffc770e51cb1fe76583523255d657d3c6b9352c94b8e044eb94ca165a070ec606cc6883cefb9556662791d213b580a0dbad5ae9032048dacc4b190bf11020d0e065bc5356537405fcd39c1eb8a3867a1b71bf83aa89489f8e98122b20953743649d27c56908ed1e32038b88d0b8237ffe792cf0595f3533905fa9250ea228449023a7845c118860d9a8155136b2b8063cee015a1b23302a83e902068f60030aef8a9e457093f7901dd0547d4b69e9d07467ea1ce06e218598b20cc917b118201d993ab833757f1e8a8367b61ae18551b82708df58fb9e25e1e9a3dfc26a5e59b8a1956a21d524c5ff39ec2c10142d0441a394432c729cd12066ce87636325003c515cb89ce0383aaac42c39c335ab760661ccba871b5717d951143ccc7e9647dfc2120a69762ac1b74f4ac554d96acd47258bc64a190e48aaf816323209b793308310c6dd7fb8b2f0a28598b61303810be5e2b0c7c7ec542145fb9c30a2763ba21173b083cdca43dad20d39a501c01b6,
    912cfef38cc18d3c5b59817dcbe5da1ca954bb8f7ca5f34a099f1811e9013eb3ad1330418f456fd15208deb301c138cb854a43b05cc897d63c86234d972d81327b8fe90407026c40ffdec1e5b1ce455ec1824acb14447345e92a1fd882715ac69b580c292fa4fd1099b8425fd3c6d872876ba5cb6b58595dbbeb3ddea7b6ee23f07ec88e9014f87d3bd860e9dd723c672c2aede20b9ddf4365a63f4a16a093d3bb8830daa3162c37572ffa71e79cc02b79e4a9441cdf3625f837fefc57b2674d0f4db7031b347fa6a223d39de8900cd5e86f80c9a60930c26b7f573ac479a28b1be2278644599c93fb1469becff36bcf7f8595e3f793e22a6caaa56a59187a9602be8ab3b2bfec06114eb417d6cf2dfadc0614a0807c78ee6c52ef492a78869d51a907db2374a86e621a27ee5cbb0e6d71a86897a1b08481ee51bd38811357c9fb3dc7bc1aa8a42a283be27b3c086cd05a2694038997095f276ccbb5aea18e677e3ba17397fd9f2041dc3053e2576315273ef570191ed894609444fd5d28ebc460ec5243dd19ebe3a152281ee35291a4b9fdd40b20705d78782ee2e02a77a3840892ab1b5ca58c030a37cbc99fbe09147b108f27eb2633d1787d69611d86873217b3a18695039825b713d84f0212761ae6034b7142a3f78e89b6341a505f4adf72a894d6d7f8e2096d25c366c3e264acf0691507d8b7cc2e54c3fa615868bd4674e6e8e2508c0c4b979a1f03548cf125db2272e1a51e9a7a5a91de9a978ce4e4ba524e931021344d7808c1144d390b048a7ac573629d2c63b3a99e79afd0e6b3da617e3b455b17264fdd74deacac05307dda5968da2a033229c1459d4cf75a41b5ac57cb8df6fce26ceaef8c56461fe0aca7159390f8fd5ee950b3d947860b0e33fdf03be9e69fe9db562cb6874e1778fda9c12a963b22f70af2520f0636554d9349eb562ef1388b8e24d795434cab7fc86e9ce1994bea8e31e75c7c1fad392333b888f16bc457464cc0080d9d35244c1931abd3e50d88a63502aa8ed5098757be4c55825e5c99d9c7092126b828491a5c0096cf12e18c1725c6b4760ab9bc33e94248089531b4513ce703b44b2790628cf0d8b73b8a38ee5cb7e2bebd4760691ea9d32ed07acb5a37712eccb52e4408b0e6175e2faf42725e348d0c2ff98383a5d8a8eadcf6b88f5331a5c9776d3e7c1370b91d19df6d37076339ca6a4936bf4e507045ecae4cac0ec08fcfe9d3322d908fdfbe107976eefcda2b07151156fa3d630566905614c430c9ac71dbf0827047863b339e6529742b7033828718be748213041abfd61cd9fa1b2075493feab6289f41dc1eefb82f01987e66186566c760708eb8d3a93dc522caee0d1f22b6a0348b088b992febcb2f184fa65164fce2392a6cdfad7794e4f3ba488336c7c06a507675de859603aa998713b367f038b92a11bdde9e524b1aff289c0b3130edb9662e7a74b9f9662de065ddd51123446fe1bfdc39ed82ad76f2967015811916ce45289ac19a176d6fcc96dbb1298a5aff9012db1a7ebeccc2231431f52603f4337bf2cdbf6449bc1a3c7ba620869486b16137bb4065ba398298deffd2c59e0d4631df9ca0c34ac24a7d1af7a8d68eb19337c683e155c2515841d214de944b4acb4ec3dfef399cfb681c4ef0a47e9ffe620a89d12ef87df6e83e7d0f1459eb4046102c5f1da723b4faec9f18e90a06b00d22f67f39cc7935920e27e3c19538b16ae122da420ed60cc095bd2bde8fde39c633aebcab8762865bf12c48e655d7ae961e71ecea6ee6e01a25d5af0dfb105d7d4f21968550227abb2c3905ccf2d708e53a235e8345609e7b9ce64edd20eede936a9d735653d96ad8cdaa480bbc7699ddc2a6e14cc768b910a3b6cade369d8084a835ee75dc238c147e94a6f7076e00b7b6f1c46740883b134268199ba0397b21e7d19c36a7a01450fb0b96539be19649d60479419df46e88ae2d9f7303ad5a3eb4b4b60c6aefd71303f51f37e9d202d6bacefb38be1009d8ac55f7808e419627cc1a3815f85780b065f7181008d0c90c0f9bf544804d9534f5986ba2bc5417f7c8d30e8f59107037e013cbbb4802146daa63d17dc9bef6c108a00701f7467f59b70917ddb3e8fd52ea75eb699e79c063c3efc1158ac678201ef1d6af571cb5ed70e4783d943420609d9db32b2fb6d888d18bfccdaf994cfcfaf13e0af23beed1192ab96156b4ca275adcaeb9f0f9453aa237c98fcc676450d88857eb1918883ea0f3d3b45fbf00ead8464e5ab2281c3aaed499ea6c41713dab00b3bd6ca42a52eb06edfcf7f48a548ed7a6756e8be4b48996e1e383317366716ada742ed880f9fd88384ff51174538d945fa9e5fab65a601a599b3ed2f2631dccc2cb6341e825d3bae35d5b29e1f5debf69ddf321c978322185d191fbbb3bc4f3b2d8cc1effaa3606902cd28de7a0051e0309e539a673c66ccf709a4863c48bf65a3e2d49df9bd9f5b44eb16357e94ef24c46a7e01be36e34162dd29ceeaf5f88b8c17034fac29519565f73b4db6e6c0c97c34d659a387eed796e5096c871d35fdf71d08bd224e5f00d2697b2b342f520be1be68d4a6185f11212a72e579ac148c0b2fc6f253c531cdc7766647326b256356f2a54d62343abc7670d64d9cbcfb29c0074b3ba5d261dafd026a9101f4357ae96a8c29d4e2bce8766906bb11beb45ccec5b6d956ec29b864b6b39e155482c09506f39c3415341ff226c40a02aa7fcb6721364a28c
  ]

О минусах я уже много рассказал, но есть ли плюсы кроме собственно криптостойкости от атак квантовых компьютеров? И на удивление - есть, в сравнении с RSA-4096 алгоритмы ML-KEM-768/ML-DSA-65 очень быстро способны производить вычисления. Так например, по бенчмаркам 100 операций шифрования/подписания RSA-4096 выполнялись за 805.5634ms и расшифрования/проверки за 706.869091ms. В это же время по аналогичным бенчмаркам 1000 операций шифрования/подписания ML-KEM-768/ML-DSA-65 выполняются за 254.339142ms и расшифрования/проверки за 132.305197ms. Разница в 8055/254~=31.7 и в 7069/132~=53.6.

Можно задаться вполне логичным вопросом - а нужна ли такая скорость в сети, где узлы должны только раз в пять секунд генерировать какое-либо сообщение? На удивление - нужна. Положительное качество увеличенной скорости (особенно расшифрования и проверки подписи) положительно сказывается на возможности своевременно расшифровывать принимаемые шифртексты из сети, тем самым позволяя содержать в системе больше пользователей при совершении DoS и DDoS атак. При действующем RSA злоумышленнику ранее требовалось генерировать 5000(мс) / 7.5(мс) / 5(в секунду) ~= 133.4 шифртекста в секунду, чтобы скорость расшифрования узлов не поспевала за их принятием. Сейчас же требуется генерировать 5000(мс) / 0.254(мс) / 5(в секунду) ~= 3937 шифртекстов в секунду, что при наличии пропускного канала в 100мбит/с является невозможным значением, т.к. превышает лимит равный 1600 шифртекстов (по 8KiB) в секунду. Таким образом, узкое звено меняет позицию с медленного расшифрования до предела пропускного канала связи. Чтобы пропускной канал не забивался, в сети Hidden Lake существует механизм доказательства работы, увеличивающий время шифрования каждого сообщения с 0.254мс до ~1.98с.

Заключение

Переход сети Hidden Lake на постквантовую криптографию хоть и добавил мне массу проблем, по типу: увеличения размера ключей, увеличения размера выходов функций шифрования / подписания, изменения интерфейсов шифрования / расшифрования, но я считаю, что это наиболее правильное решение. Текущий расклад вещей таков, что: либо мы рискуем и применяем в своих системах постквантовые криптоалгоритмы, прошедшие стандартизацию NIST, располагая уже сейчас определённым шансом быть невзломанными в будущем, либо принимаем судьбу комфорта и повышаем вероятность взлома наших текущих сообщений в будущем до ста процентов. Это может показаться паранойей, но с учётом существующего пакета Яровой и СОРМ-3, сохраняющим весь поступаемый трафик, проекта PRISM, заключающим союз между АНБ и Microsoft, Apple, Google, с учётом существования явных интересов различных государств в передовом развитии квантовых компьютеров - угроза "Собери сейчас, взломай потом" становится более чем реальна.

Комментарии (8)


  1. MAXH0
    21.10.2024 03:18

    А как в сети с маскировкой пакетов? Потому что сейчас анализ пакетов — это один из векторов атаки, пусть и не на приватность, но на устойчивость сети...


    1. Number571 Автор
      21.10.2024 03:18

      По умолчанию маскировка пакетов отсутствует. Так например, при подключении к готовым ретрансляторам можно достаточно легко определить принадлежность трафика к анонимной сети: 1) сообщения генерируются каждые 5 секунд, 2) размер каждого сообщения равен 8KiB, 3) каждое сообщение отправляется по TCP вида len(c) || c, где c - шифртекст, len - размер сообщения, 4) каждое сообщение ретранслируется на всех участников.

      Но на самом деле не всё так мрачно, т.к вышеописанный паттерн - это лишь один из способов запуска. Период генерации в HL может становиться динамичным (параметр rand_queue_period>0), размер сообщения может быть варьируемо-случайным (параметр rand_message_size_bytes>0), сообщения могут передаваться по другим протоколам, например HTTPS (фича с len - специфика только при сырых TCP соединениях), за счёт использования адаптеров.


      1. MAXH0
        21.10.2024 03:18

        Спасибо за ответ... Но у меня возникает подозрение, что в условиях активного противодействия придется пускать трафик через VPN с маскировкой пакетов. И тогда зачем? Находясь в ситуации, когда любые нестандартные пакеты типа дискорд или ютуб регулярно отваливаются, мне кажется нужно копать именно в этом направлении. Чисто ИМХО. А без этого получается такая красивая теоретическая система в вакууме.


  1. lrrr11
    21.10.2024 03:18

    Два из трёх стандартизированных алгоритма базируются на теории решёток, где взлом одного может повлечь и взлом другого. При этом, оставшийся третий алгоритм - SPHINCS+ (базируемый на хеш-функциях) способен лишь создавать цифровые подписи, но не шифровать сообщения / не инкапсулировать ключи. Таким образом, в настоящее время не существует стандартизированных альтернатив KEM'а (key encapsulation mechanism), кроме ML-KEM'а (Kyber'а).

    ну вот поэтому в NIST сейчас и объявили дополнительный раунд, чтобы стандартизировать что-нибудь не на решетках (либо на решетках, но принципиально более лучшее)

    В целом все это тлен, стойкость никакого алгоритма шифрования не доказана и не может быть доказана, т.к. это задача из серии "докажи что ты не верблюд". Даже если там что-нибудь сведут к NP-сложной задаче и докажут что P!=NP - никто не гарантирует, что не найдутся какие-нибудь 0.1% частных случаев с эффективным эвристическим алгоритмом решения.


    1. MAXH0
      21.10.2024 03:18

      Исходя из этого, ИМХО, второй вариант с симметричными ключами становится более надежным. Просто потому, что они древнее и больше найдено уязвимостей и их решений. Возникает вопрос в безопасном обмете шифро-блокнотами. И тут если не брать флешконет голубиной (или ослиной) почтой, можно использовать сложные ассиметричные схемы в расчете на то, что все не будут расшифровывать, так как дорого.


  1. pnaydanovgoo
    21.10.2024 03:18

    Интересно, как бы мог проходить процесс перехода на новую криптографию в запущеной сети (я так понял HL - это же концепт?), когда кто-то обновился до новой версии, а кто-то нет. И что выбрать: делать вечную обратную совместимость с RSA или принудительно заставлять делать переход на постквантовую криптографию? Просто если часть участников сети продолжат использовать RSA, то и от взлома они не защищены.


    1. Number571 Автор
      21.10.2024 03:18

      Вопрос действительно интересный, т.к. основная проблема перехода - это потеря идентификации узлов. Если это система по типу криптовалют, где всё держится на подобного рода идентификации - необходимым условием становится связывание ключей, где ключ RSA подписывает ключ ML-DSA, а ML-DSA - ключ RSA. Соответственно в логике криптовалют / блокчейна должны будут храниться два ключа с последующей возможностью их валидации. Если RSA ещё не взломан, он вполне себе может подтверждать идентификацию участника через ML-DSA какое-то время. Этого времени должно быть достаточно ровно настолько, чтобы оставшиеся узлы смогли перейти на подтверждённый ML-DSA ключ, а RSA ключ воспринять как Deprecated. Таким образом, предполагается, что до создания мощного квантового компьютера состояние Deprecated сможет перейти в состояние Forbidden, а все действия, что происходили с RSA ключом в виде хеша будут сохранены в состоянии под ML-DSA подписью.

      С анонимными сетями ситуация немного упрощённее, т.к. не требуется хранить состояние, плюс к этому не все анонимные сети в равной степени будут сложнопереносимы. Как пример, для сети Tor переход на постквантовые алгоритмы будет более простым, чем для I2P, т.к. бОльшая часть коммуникаций связана у него всё же с открытым Интернетом, а не внутренними Hidden Services. Что касается Hidden Lake, то тут ситуация ещё проще, потому как: 1) у HL нет какой-то одной глобальной сети, в отличие от Tor или I2P, вследствие чего одна сеть может работать на RSA, другая - на ML-DSA, 2) HL работает с малыми группами узлов, а потому обновить их будет чисто количественно проще, 3) HL не настолько популярна как Tor, I2P, поэтому радикальные обновления можно делать более смело.

      Что касается Hidden Lake, как концепта - год назад сеть таковой действительно являлась, сейчас уже скорее нет, чем да, т.к.: 1) сеть вполне успешно функционирует, ретрансляторы запущены и распределяют / сохраняют шифртексты, 2) исследовательские работы написаны, рассмотрены пределы сети, её достоинства и уязвимости, 3) основная часть кода, связанная с анонимностью и безопасностью, покрыта тестами более чем на 98% (пакет go-peer).