Поиск в базе данных с параметрами ECIES

Proposal 154
Closed
Author zzz
Created 2020-03-23
Last Updated 2021-01-08
Target Version 0.9.46
Implemented In 0.9.46

Примечание

ECIES к ElG реализовано в 0.9.46, и этап предложения закрыт. См. I2NP для официальной спецификации. На это предложение можно ссылаться для получения фоновой информации. ECIES к ECIES с включенными ключами реализовано с версии 0.9.48. Раздел ECIES-к-ECIES (производные ключи) может быть вновь открыт или включен в будущие предложения.

Обзор

Определения

  • AEAD: ChaCha20/Poly1305
  • DLM: Сообщение поиска в базе данных I2NP
  • DSM: Сообщение хранения в базе данных I2NP
  • DSRM: Сообщение ответа поиска в базе данных I2NP
  • ECIES: ECIES-X25519-AEAD-Ratchet (предложение 144)
  • ElG: ElGamal
  • ENCRYPT(k, n, payload, ad): как определено в ECIES
  • LS: Leaseset
  • lookup: I2NP DLM
  • reply: I2NP DSM или DSRM

Резюме

При отправке DLM для LS на floodfill, DLM обычно указывает, что ответ должен быть с тегом, зашифрован AES и отправлен по туннелю к месту назначения. Поддержка ответов зашифрованных AES была добавлена в 0.9.7.

Ответы зашифрованные AES были определены в 0.9.7, чтобы минимизировать большие криптографические накладные расходы ElG, и потому что они повторно использовали возможности тегов/AES в ElGamal/AES+SessionTags. Однако, ответы, зашифрованные AES, могут быть изменены на IBEP, так как они не имеют аутентификации, и ответы не имеют свойства прямой секретности.

С пунктами назначения ECIES, цель предложения 144 состоит в том, чтобы пункты назначения больше не поддерживали 32-байтные теги и расшифровку AES. Специфика намеренно не была включена в это предложение.

Это предложение документирует новую опцию в DLM для запроса ответов зашифрованных ECIES.

Цели

  • Новые флаги для DLM, когда запрашивается зашифрованный ответ по туннелю к пункту назначения ECIES
  • Для ответа, добавить прямую секретность и аутентификацию отправителя, устойчивых к компрометации ключа запросчика (пункта назначения).
  • Сохранение анонимности запросчика
  • Минимизация криптографической нагрузки

Не цели

  • Без изменения шифрования или свойств безопасности поиска (DLM). Поиск имеет прямую секретность только для компрометации ключа запросчика. Шифрование осуществляется статическим ключом floodfill.
  • Нет проблем с прямой секретностью или аутентификацией отправителя, устойчивых к компрометации ключа ответчика (floodfill). Floodfill является публичной базой данных и будет отвечать на запросы от кого угодно.
  • Нет проектирования маршрутизаторов ECIES в этом предложении. Куда идет публичный ключ X25519 маршрутизатора TBD.

Альтернативы

В отсутствие определенного способа шифрования ответов на пункты назначения ECIES, есть несколько альтернатив:

  1. Не запрашивать зашифрованные ответы. Ответы будут незашифрованными. Текущая реализация Java I2P использует этот подход.

  2. Добавить поддержку 32-байтных тегов и ответов зашифрованных AES на пункты назначения только ECIES, и запрашивать ответы зашифрованные AES как обычно. Текущая реализация i2pd использует этот подход.

  3. Запрашивать ответы зашифрованные AES как обычно, но направлять их обратно через исследовательские туннели на маршрутизатор. Текущая реализация Java I2P использует этот подход в некоторых случаях.

  4. Для двойных пунктов назначения ElG и ECIES, запрашивать ответы зашифрованные AES как обычно. Текущая реализация Java I2P использует этот подход. i2pd еще не реализовала двойные криптографические пункты назначения.

Дизайн

  • Новый формат DLM добавит бит в поле флагов для указания ответов зашифрованных ECIES. Ответы зашифрованные ECIES будут использовать формат Existing Session сообщения ECIES, с препозиционированным тегом и ChaCha/Poly полезной нагрузкой и MAC.

  • Определить два варианта. Один для маршрутизаторов ElG, где операция DH невозможна, и один для будущих маршрутизаторов ECIES, где операция DH возможна и может обеспечить дополнительную безопасность. Для дальнейшего изучения.

DH невозможен для ответов от маршрутизаторов ElG, потому что они не публикуют публичный ключ X25519.

Спецификация

В спецификации I2NP DLM (DatabaseLookup) внести следующие изменения.

Добавить бит флага 4 “ECIESFlag” для новых опций шифрования.

flags ::
       bit 4: ECIESFlag
               before release 0.9.46 ignored
               as of release 0.9.46:
               0  => send unencrypted or ElGamal reply
               1  => send ChaCha/Poly encrypted reply using enclosed key
                     (whether tag is enclosed depends on bit 1)

Бит флага 4 используется в комбинации с битом 1 для определения режима шифрования ответа. Бит флага 4 должен быть установлен только при отправке маршрутизаторам с версией 0.9.46 или выше.

В таблице ниже “DH н/д” означает, что ответ не зашифрован. “DH нет” означает, что ключи ответа включены в запрос. “DH да” означает, что ключи ответа генерируются из операции DH.

Флаги битов 4,1Откуда н.Куда м.ОтветDH?Примечания
0 0ЛюбойЛюбойнетн/дтекущий
0 1ElGElGAESнеттекущий
0 1ECIESElGAESнетi2pd обх.
1 0ECIESElGAEADнетэто предл.
1 0ECIESECIESAEADнет0.9.49
1 1ECIESECIESAEADдабудущее

ElG к ElG

Пункт назначения ElG отправляет поиск на маршрутизатор ElG.

Незначительные изменения в спецификации для проверки нового бита 4. Нет изменений в существующем бинарном формате.

Генерация ключа запросчика (уточнение):

reply_key :: CSRNG(32) 32 байт случайных данных
  reply_tags :: Каждый - CSRNG(32) 32 байт случайных данных

Формат сообщения (добавить проверку на ECIESFlag):

reply_key ::
       32 байт `SessionKey` big-endian
       включен только если encryptionFlag == 1 И ECIESFlag == 0, начиная с релиза 0.9.7

  tags ::
       1 байт `Integer`
       допустимый диапазон: 1-32 (обычно 1)
       количество тегов ответа, которые следуют
       включен только если encryptionFlag == 1 И ECIESFlag == 0, начиная с релиза 0.9.7

  reply_tags ::
       один или более 32-байтных `SessionTag` (обычно один)
       включен только если encryptionFlag == 1 И ECIESFlag == 0, начиная с релиза 0.9.7

ECIES к ElG

Пункт назначения ECIES отправляет поиск на маршрутизатор ElG. Поддерживается с версии 0.9.46.

Поля reply_key и reply_tags переопределены для ответа зашифрованного ECIES.

Генерация ключа запросчика:

reply_key :: CSRNG(32) 32 байт случайных данных
  reply_tags :: Каждый - CSRNG(8) 8 байт случайных данных

Формат сообщения: Переопределить поля reply_key и reply_tags следующим образом:

reply_key ::
       32 байт ECIES `SessionKey` big-endian
       включен только если encryptionFlag == 0 И ECIESFlag == 1, начиная с релиза 0.9.46

  tags ::
       1 байт `Integer`
       обязательное значение: 1
       количество тегов ответа, которые следуют
       включен только если encryptionFlag == 0 И ECIESFlag == 1, начиная с релиза 0.9.46

  reply_tags ::
       8 байт ECIES `SessionTag`
       включен только если encryptionFlag == 0 И ECIESFlag == 1, начиная с релиза 0.9.46

Ответ - это сообщение ECIES Existing Session, как определено в ECIES.

tag :: 8 байт reply_tag

  k :: 32 байт session key
     это reply_key.

  n :: 0

  ad :: 8 байт reply_tag

  payload :: Открытые данные, DSM или DSRM.

  ciphertext = ENCRYPT(k, n, payload, ad)

ECIES к ECIES (0.9.49)

Пункт назначения или маршрутизатор ECIES отправляет поиск на маршрутизатор ECIES, с пакетными ключами ответа. Поддерживается с версии 0.9.49.

Маршрутизаторы ECIES были введены в версии 0.9.48, см. Prop156. Начиная с 0.9.49, пункты назначения и маршрутизаторы ECIES могут использовать такой же формат, как в разделе “ECIES к ElG” выше, с включенными ключами ответа в запросе. Поиск будет использовать “одноразовый формат” в ECIES так как запросчик анонимен.

Для нового метода с производными ключами, см. следующий раздел.

ECIES к ECIES (будущее)

Пункт назначения или маршрутизатор ECIES отправляет поиск на маршрутизатор ECIES, и ключи ответа генерируются из DH. Не полностью определено или поддерживается, реализация TBD.

Поиск будет использовать “одноразовый формат” в ECIES так как запросчик анонимен.

Переопределить поле reply_key следующим образом. Связанных тегов нет. Теги будут сгенерированы в KDF ниже.

Этот раздел не завершен и требует дальнейшего изучения.

reply_key ::
       32 байт X25519 эфемерный `PublicKey` запросчика, little-endian
       включен только если encryptionFlag == 1 И ECIESFlag == 1, начиная с релиза 0.9.TBD

Ответ - это сообщение ECIES Existing Session, как определено в ECIES. См. ECIES для всех определений.

// Эфемерные ключи X25519 Алисы
  // aesk = Эфемерный приватный ключ Алисы
  aesk = GENERATE_PRIVATE()
  // aepk = Эфемерный публичный ключ Алисы
  aepk = DERIVE_PUBLIC(aesk)
  // Статические ключи X25519 Боба
  // bsk = Приватный статический ключ Боба
  bsk = GENERATE_PRIVATE()
  // bpk = Публичный статический ключ Боба
  // bpk является частью RouterIdentity, или опубликован в RouterInfo (TBD)
  bpk = DERIVE_PUBLIC(bsk)

  // (DH()
  //[chainKey, k] = MixKey(sharedSecret)
  // chainKey из ???
  sharedSecret = DH(aesk, bpk) = DH(bsk, aepk)
  keydata = HKDF(chainKey, sharedSecret, "ECIES-DSM-Reply1", 32)
  chainKey = keydata[0:31]

  1) rootKey = chainKey из секции полезной нагрузки
  2) k из KDF новой сессии или split()

  // KDF_RK(rk, dh_out)
  keydata = HKDF(rootKey, k, "KDFDHRatchetStep", 64)

  // Output 1: не используется
  unused = keydata[0:31]
  // Output 2: Цепной ключ для инициализации новых
  // сеансовых тегов и симметричных ключевых храповиков
  // для передачи от Алисы к Бобу
  ck = keydata[32:63]

  // сеансовый тег и цепные ключи симметричного ключа
  keydata = HKDF(ck, ZEROLEN, "TagAndKeyGenKeys", 64)
  sessTag_ck = keydata[0:31]
  symmKey_ck = keydata[32:63]

  tag :: 8 байт тег, сгенерированный от RATCHET_TAG() в [ECIES](/docs/specs/ecies/)

  k :: 32 байт ключ, сгенерированный от RATCHET_KEY() в [ECIES](/docs/specs/ecies/)

  n :: Индекс тега. Обычно 0.

  ad :: 8 байт тег

  payload :: Открытые данные, DSM или DSRM.

  ciphertext = ENCRYPT(k, n, payload, ad)

Формат ответа

Это существующее сеансовое сообщение, такое же как в ECIES, скопировано ниже для справки.

+----+----+----+----+----+----+----+----+
  |       Session Tag                     |
  +----+----+----+----+----+----+----+----+
  |                                       |
  +            Payload Section            +
  |       Зашифрованные данные ChaCha20   |
  ~                                       ~
  |                                       |
  +                                       +
  |                                       |
  +----+----+----+----+----+----+----+----+
  |  Poly1305 Код проверки подлинности    |
  +              (MAC)                    +
  |             16 байтов                 |
  +----+----+----+----+----+----+----+----+

  Session Tag :: 8 байтов, открытым текстом

  Зашифрованные данные Payload Section :: оставшиеся данные минус 16 байтов

  MAC :: Код проверки подлинности Poly1305, 16 байтов

Обоснование

Параметры шифрования ответа в поисковом запросе, впервые введенные в 0.9.7, немного нарушают уровень. Это сделано из соображений эффективности. Но также потому, что запрос анонимный.

Мы могли бы сделать формат запроса более универсальным, как с полем типа шифрования, но это, вероятно, больше хлопот, чем стоит.

Вышеупомянутое предложение является самым простым и минимизирует изменения в формате запроса.

Заметки

Поиски в базе данных и записи в базу данных на маршрутизаторы ElG должны быть зашифрованы ElGamal/AESSessionTag как обычно.

Проблемы

Требуется дальнейший анализ безопасности двух вариантов ответов ECIES.

Миграция

Вопросы обратной совместимости отсутствуют. Маршрутизаторы, указывающие версию 0.9.46 или выше в своих RouterInfo, должны поддерживать эту функцию. Маршрутизаторы не должны отправлять DatabaseLookup с новыми флагами на маршрутизаторы с версией ниже 0.9.46. Если сообщение DatabaseLookup с установленным битом 4 и неустановленным битом 1 ошибочно отправлено маршрутизатору без поддержки, он, вероятно, проигнорирует предоставленный ключ и тег, и отправит ответ незашифрованным.