B32 для зашифрованных LS2

Proposal 149
Closed
Author zzz
Created 2019-03-13
Last Updated 2020-08-05
Target Version 0.9.40
Implemented In 0.9.40

Примечание

В сети идет развертывание и тестирование. Возможны незначительные изменения. Смотрите SPEC для официальной спецификации.

Обзор

Стандартные адреса Base 32 (“b32”) содержат хеш от места назначения. Это не работает для зашифрованных ls2 (предложение 123).

Вы не можете использовать традиционный адрес base 32 для зашифрованного LS2 (предложение 123), поскольку он содержит только хеш от пункта назначения. Он не предоставляет незаслепленный открытый ключ. Клиенты должны знать открытый ключ пункта назначения, тип подписи, тип подписи для заслепления и необязательный секретный или приватный ключ, чтобы получить и расшифровать leaseset. Таким образом, одного адреса base 32 недостаточно. Клиенту необходимо или полное назначение (которое содержит открытый ключ), или сам открытый ключ. Если у клиента есть полное назначение в адресной книге, и книга поддерживает обратный поиск по хешу, то открытый ключ может быть получен.

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

В этом предложении документируется новый формат b32 для таких адресов. Хотя в обсуждениях мы упоминаем этот новый формат как адрес “b33”, фактический новый формат сохраняет обычный суффикс “.b32.i2p”.

Цели

  • Включить как незаслепленные, так и заслепленные типы подписей для поддержки будущих схем заслепления
  • Поддержка открытых ключей размером более 32 байт
  • Обеспечить, чтобы символы b32 были все или в основном случайными, особенно в начале (не хочется, чтобы все адреса начинались с одинаковых символов)
  • Должно легко разбираемое
  • Указать, что требуется секрет заслепления и/или ключ для клиента
  • Добавить контрольную сумму для обнаружения опечаток
  • Минимизировать длину, поддерживать длину метки DNS менее 63 символов для обычного использования
  • Продолжать использовать base 32 для нечувствительности к регистру
  • Сохранить обычный суффикс “.b32.i2p”.

Не цели

  • Не поддерживать “частные” ссылки, которые включают секрет заслепления и/или клиентские ключи; это было бы небезопасно.

Дизайн

  • Новый формат будет содержать незаслепленный открытый ключ, незаслепленный тип подписи, и заслепленный тип подписи.
  • По желанию содержать секрет и/или приватный ключ, только для частных ссылок
  • Использовать существующий суффикс “.b32.i2p”, но с большей длиной.
  • Добавить контрольную сумму.
  • Адреса для зашифрованных leaseset идентифицируются 56 и более кодированными символами (35 и более декодированных байтов), по сравнению с 52 символами (32 байта) для традиционных адресов base 32.

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

Создание и кодирование

Составьте имя хоста из {56+ символов}.b32.i2p (35+ символов в двоичном формате) следующим образом:

флаг (1 байт)
    бит 0: 0 для одно-байтовых типов подписи, 1 для двух-байтовых типов подписи
    бит 1: 0 если нет секрета, 1 если секрет требуется
    бит 2: 0 если нет аутентификации клиента,
           1 если требуется приватный ключ клиента
    биты 7-3: Не используется, установить в 0

  тип подписи открытого ключа (1 или 2 байта как указано во флагах)
    Если 1 байт, предположительно старший байт равен нулю

  тип подписи заслепленного ключа (1 или 2 байта как указано во флагах)
    Если 1 байт, предположительно старший байт равен нулю

  открытый ключ
    Количество байтов, как указано в типе подписи

Постобработка и контрольная сумма:

Соберите двоичные данные, как указано выше.
  Рассматривать контрольную сумму как little-endian.
  Вычислить контрольную сумму = CRC-32(data[3:end])
  data[0] ^= (byte) контрольная сумма
  data[1] ^= (byte) (контрольная сумма >> 8)
  data[2] ^= (byte) (контрольная сумма >> 16)

  hostname = Base32.encode(data) || ".b32.i2p"

Любые неиспользуемые биты в конце b32 должны быть равны 0. Для стандартного 56-символьного (35-байтового) адреса не предусмотрено неиспользуемых битов.

Декодирование и Проверка

убрать ".b32.i2p" из имени хоста
  data = Base32.decode(hostname)
  Вычислить контрольную сумму = CRC-32(data[3:end])
  Рассматривать контрольную сумму как little-endian.
  flags = data[0] ^ (byte) контрольная сумма
  если одно-байтовые типы подписи:
    тип подписи открытого ключа = data[1] ^ (byte) (контрольная сумма >> 8)
    тип подписи заслепленного ключа = data[2] ^ (byte) (контрольная сумма >> 16)
  иначе (двух-байтовые типы подписи) :
    тип подписи открытого ключа = data[1] ^ ((byte) (контрольная сумма >> 8)) || data[2] ^ ((byte) (контрольная сумма >> 16))
    тип подписи заслепленного ключа = data[3] || data[4]
  анализировать остаток на основе флагов для получения открытого ключа

Секрет и Биты Приватного Ключа

Секрет и биты приватного ключа используются для указания клиентам, прокси или другим клиентским программам, что секрет и/или приватный ключ потребуется для расшифровки leaseset. Конкретные реализации могут запросить пользователя о предоставлении необходимых данных или отклонить попытки подключения, если необходимые данные отсутствуют.

Обоснование

  • XOR первых 3 байтов с хешем позволяет обеспечить ограниченные возможности проверки контрольной суммы, и гарантирует, что все символы base32 в начале будут случайными. Допустимо только несколько комбинаций флагов и типов подписей, поэтому любая опечатка, скорее всего, создаст недопустимую комбинацию и будет отклонена.
  • В обычном случае (одно-байтовые типы подписей, нет секрета, нет аутентификации клиента), имя хоста будет {56 символов}.b32.i2p, декодируется в 35 байтов, как и в Tor.
  • Контрольная сумма в 2 байта у Tor имеет 1/64K вероятность ложного отрицательного результата. У нас с 3 байтами, за вычетом нескольких игнорируемых байтов, вероятность приближается к 1 на миллион, так как большинство комбинаций флагов/типов подписей недействительны.
  • Adler-32 плохой выбор для небольших входных данных и для обнаружения небольших изменений . Используется CRC-32 вместо этого. CRC-32 быстрое и широко доступное.

Кэширование

Хотя за пределами данного предложения, маршрутизаторы и/или клиенты должны запоминать и кэшировать (вероятно, постоянно) соответствие открытого ключа назначению, и наоборот.

Примечания

  • Различайте старые и новые форматы по длине. Старые адреса b32 всегда {52 символа}.b32.i2p. Новые - {56+ символов}.b32.i2p
  • Обсуждение в Tor: https://lists.torproject.org/pipermail/tor-dev/2017-January/011816.html
  • Не ожидается, что двух-байтовые типы подписей когда-либо появятся, у нас только до 13. Нет необходимости реализовывать сейчас.
  • Новый формат может быть использован в jump-ссылках (и на jump-серверах), при желании, так же как и b32.

Проблемы

  • Любой секрет, приватный ключ или открытый ключ более 32 байт превысит максимальную длину метки DNS в 63 символа. Браузерам, вероятно, все равно.

Миграция

Нет проблем с обратной совместимостью. Более длинные адреса b32 не удастся преобразовать в 32-байтовые хеши в старом программном обеспечении.