Обзор
Это предложение добавляет новый тип подписи, использующий BLAKE2b-512 с персонализированными строками и солями, для замены SHA-512. Это исключит три класса возможных атак.
Мотивация
В ходе обсуждений и разработки NTCP2 (предложение 111) и LS2 (предложение 123), мы кратко рассмотрели различные возможные атаки и способы их предотвращения. Три из этих атак — это атаки расширения длины, межпротокольные атаки и идентификация дублирующихся сообщений.
Для NTCP2 и LS2 мы решили, что эти атаки не имели прямого отношения к рассматриваемым предложениям, и любые решения противоречили цели минимизации новых примитивов. Также мы определили, что скорость хеш-функций в этих протоколах не являлась важным фактором в наших решениях. Поэтому мы в основном отложили решение до отдельного предложения. Хотя мы добавили некоторые функции персонализации в спецификацию LS2, мы не потребовали каких-либо новых хеш-функций.
Многие проекты, такие как ZCash, используют хеш-функции и алгоритмы подписи, основанные на новых алгоритмах, которые не уязвимы к следующим атакам.
Length Extension Attacks
SHA-256 и SHA-512 уязвимы к атакам расширения длины (Length Extension Attacks, LEA). Это происходит, когда подписываются фактические данные, а не хеш данных. В большинстве протоколов I2P (streaming, datagrams, netdb и других) подписываются фактические данные. Одним исключением являются файлы SU3, где подписывается хеш. Другим исключением являются подписанные датаграммы для DSA (тип подписи 0) только, где подписывается хеш. Для других типов подписей датаграмм подписываются данные.
Cross-Protocol Attacks
Подписанные данные в протоколах I2P могут быть уязвимы к межпротокольным атакам (Cross-Protocol Attacks, CPA) из-за отсутствия разделения доменов. Это позволяет злоумышленнику использовать данные, полученные в одном контексте (например, подписанная датаграмма), и представить их как корректные подписанные данные в другом контексте (например, потоковая передача или сетевая база данных). Хотя маловероятно, что подписанные данные из одного контекста будут обработаны как корректные данные в другом контексте, сложно или невозможно проанализировать все ситуации, чтобы знать наверняка. Кроме того, в некоторых контекстах злоумышленник может заставить жертву подписать специально созданные данные, которые могут оказаться корректными данными в другом контексте. Опять же, сложно или невозможно проанализировать все ситуации, чтобы знать наверняка.
Атаки расширения длины
Протоколы I2P могут быть уязвимы к атаке Duplicate Message Identification (DMI). Это может позволить злоумышленнику определить, что два подписанных сообщения имеют одинаковое содержимое, даже если эти сообщения и их подписи зашифрованы. Хотя это маловероятно из-за методов шифрования, используемых в I2P, сложно или невозможно проанализировать все ситуации, чтобы знать наверняка. Используя хеш-функцию, которая предоставляет метод для добавления случайной соли, все подписи будут разными даже при подписании одних и тех же данных. Хотя Red25519, как определено в предложении 123, добавляет случайную соль к хеш-функции, это не решает проблему для незашифрованных lease sets.
Атаки с использованием разных протоколов
Хотя это и не является основной мотивацией для данного предложения, SHA-512 работает относительно медленно, и доступны более быстрые хеш-функции.
Goals
- Предотвращать вышеуказанные атаки
- Минимизировать использование новых криптографических примитивов
- Использовать проверенные, стандартные криптографические примитивы
- Использовать стандартные кривые
- Использовать более быстрые примитивы, если они доступны
Design
Модифицировать существующий тип подписи RedDSA_SHA512_Ed25519 для использования BLAKE2b-512 вместо SHA-512. Добавить уникальные строки персонализации для каждого случая использования. Новый тип подписи может использоваться как для обычных, так и для слепых leaseSet’ов.
Justification
- BLAKE2b не уязвим к LEA.
- BLAKE2b предоставляет стандартный способ добавления строк персонализации для разделения доменов
- BLAKE2b предоставляет стандартный способ добавления случайной соли для предотвращения DMI.
- BLAKE2b быстрее SHA-256 и SHA-512 (и MD5) на современном оборудовании, согласно спецификации BLAKE2.
- Ed25519 по-прежнему наш самый быстрый тип подписи, намного быстрее ECDSA, по крайней мере в Java.
- Ed25519 требует 512-битную криптографическую хеш-функцию. Он не указывает SHA-512. BLAKE2b точно так же подходит для хеш-функции.
- BLAKE2b широко доступен в библиотеках для многих языков программирования, таких как Noise.
Specification
Используйте BLAKE2b-512 без ключа, как указано в спецификации BLAKE2, с солью и персонализацией. Все использования подписей BLAKE2b будут использовать 16-символьную строку персонализации.
При использовании в подписании RedDSA_BLAKE2b_Ed25519 разрешается случайная соль, однако она не является необходимой, поскольку алгоритм подписи добавляет 80 байт случайных данных (см. предложение 123). При желании, при хешировании данных для вычисления r, установите новую 16-байтную случайную соль BLAKE2b для каждой подписи. При вычислении S сбросьте соль на значение по умолчанию из всех нулей.
При использовании в верификации RedDSA_BLAKE2b_Ed25519 не используйте случайную соль, используйте значение по умолчанию из всех нулей.
Возможности salt и персонализации не указаны в RFC 7693; используйте эти возможности согласно спецификации в спецификации BLAKE2.
Идентификация дублированных сообщений
Для RedDSA_BLAKE2b_Ed25519 замените хэш-функцию SHA-512 в RedDSA_SHA512_Ed25519 (тип подписи 11, как определено в предложении 123) на BLAKE2b-512. Никаких других изменений.
Нам не нужна замена для EdDSA_SHA512_Ed25519ph (тип подписи 8) для su3 файлов, поскольку предварительно хешированная версия EdDSA не уязвима для LEA. EdDSA_SHA512_Ed25519 (тип подписи 7) не поддерживается для su3 файлов.
| Type | Type Code | Since | Usage |
|---|---|---|---|
| RedDSA_BLAKE2b_Ed25519 | 12 | TBD | For Router Identities, Destinations and encrypted leasesets only; never used for Router Identities |
Скорость
Следующее относится к новому типу подписи.
| Data Type | Length |
|---|---|
| Hash | 64 |
| Private Key | 32 |
| Public Key | 32 |
| Signature | 64 |
Personalizations
Для обеспечения разделения доменов при различных использованиях подписей мы будем использовать функцию персонализации BLAKE2b.
Все применения подписей BLAKE2b будут использовать 16-символьную строку персонализации. Любые новые применения должны быть добавлены в таблицу здесь с уникальной персонализацией.
Процедуры рукопожатия NTCP 1 и SSU, используемые ниже, предназначены для подписанных данных, определенных в самом рукопожатии. Подписанные RouterInfo в сообщениях DatabaseStore будут использовать персонализацию NetDb Entry, точно так же, как если бы они хранились в NetDB.
| Usage | 16 Byte Personalization |
|---|---|
| I2CP SessionConfig | “I2CP_SessionConf” |
| NetDB Entries (RI, LS, LS2) | “network_database” |
| NTCP 1 handshake | “NTCP_1_handshake” |
| Signed Datagrams | “sign_datagramI2P” |
| Streaming | “streaming_i2psig” |
| SSU handshake | “SSUHandshakeSign” |
| SU3 Files | n/a, not supported |
| Unit tests | “test1234test5678” |
Цели
Дизайн
- Альтернатива 1: Предложение 146; Обеспечивает устойчивость к LEA
- Альтернатива 2: Ed25519ctx в RFC 8032; Обеспечивает устойчивость к LEA и персонализацию. Стандартизовано, но кто-нибудь это использует? См. RFC 8032 и это обсуждение.
- Полезно ли нам “ключевое” хеширование?
Обоснование
То же самое, что и при развертывании предыдущих типов подписей.
Мы планируем изменить новые router’ы с типа 7 на тип 12 по умолчанию. Мы планируем в конечном итоге перевести существующие router’ы с типа 7 на тип 12, используя процесс “rekeying”, который применялся после внедрения типа 7. Мы планируем изменить новые назначения с типа 7 на тип 12 по умолчанию. Мы планируем изменить новые зашифрованные назначения с типа 11 на тип 13 по умолчанию.
Мы будем поддерживать блайндинг с типов 7, 11 и 12 на тип 12. Мы не будем поддерживать блайндинг с типа 12 на тип 11.
Новые router-ы могут начать использовать новый тип подписи по умолчанию через несколько месяцев. Новые точки назначения могут начать использовать новый тип подписи по умолчанию примерно через год.
Для минимальной версии router 0.9.TBD, роутеры должны обеспечить:
- Не сохранять (или не распространять flood-запросами) RI или LS с новым типом подписи на роутеры с версией меньше 0.9.TBD.
- При проверке netdb store не загружать RI или LS с новым типом подписи с роутеров с версией меньше 0.9.TBD.
- Роутеры с новым типом подписи в их RI могут не подключаться к роутерам с версией меньше 0.9.TBD, ни через NTCP, ни через NTCP2, ни через SSU.
- Streaming-соединения и подписанные датаграммы не будут работать с роутерами с версией меньше 0.9.TBD, но узнать это заранее невозможно, поэтому новый тип подписи не следует использовать по умолчанию в течение нескольких месяцев или лет после выпуска версии 0.9.TBD.