Этот перевод был создан с помощью машинного обучения и может быть не на 100% точным. Просмотреть английскую версию

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

Формат адреса Base 32 для зашифрованных LS2 leaseSet'ов

Обзор

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

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

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

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

Архитектура

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

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

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

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

flag (1 byte)
    bit 0: 0 for one-byte sigtypes, 1 for two-byte sigtypes
    bit 1: 0 for no secret, 1 if secret is required
    bit 2: 0 for no per-client auth, 1 if client private key is required
    bits 7-3: Unused, set to 0

public key sigtype (1 or 2 bytes as indicated in flags)
    If 1 byte, the upper byte is assumed zero

blinded key sigtype (1 or 2 bytes as indicated in flags)
    If 1 byte, the upper byte is assumed zero

public key
    Number of bytes as implied by sigtype

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

Construct the binary data as above.
Treat checksum as little-endian.
Calculate checksum = CRC-32(data[3:end])
data[0] ^= (byte) checksum
data[1] ^= (byte) (checksum >> 8)
data[2] ^= (byte) (checksum >> 16)

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

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

Декодирование и верификация

strip the ".b32.i2p" from the hostname
data = Base32.decode(hostname)
Calculate checksum = CRC-32(data[3:end])
Treat checksum as little-endian.
flags = data[0] ^ (byte) checksum
if 1 byte sigtypes:
    pubkey sigtype = data[1] ^ (byte) (checksum >> 8)
    blinded sigtype = data[2] ^ (byte) (checksum >> 16)
else (2 byte sigtypes):
    pubkey sigtype = data[1] ^ ((byte) (checksum >> 8)) || data[2] ^ ((byte) (checksum >> 16))
    blinded sigtype = data[3] || data[4]
parse the remainder based on the flags to get the public key

Биты секретного и приватного ключей

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

Кеширование

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

Примечания

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

Ссылки

Was this page helpful?