Формат провода Тинк

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

Сериализация набора ключей

Tink использует Google protobuf для сериализации своих наборов ключей.

  • Двоичный сериализованный набор ключей — это сериализованный прототип набора ключей, определенный в Tink.proto . Свойство значения KeyData ключа представляет собой сериализованный прототип соответствующего типа ключа.
  • Сериализованный набор ключей JSON — это прототип набора ключей, сериализованный в формате JSON . Обратите внимание, что значение KeyData по-прежнему является двоичным сериализованным прототипом.
  • Зашифрованный набор ключей — это сериализованный прототип EncryptedKeyst, определенный в Tink.proto . Он содержит зашифрованный двоичный сериализованный набор ключей и, при необходимости, некоторые незашифрованные метаданные KeysetInfo.

Префикс вывода Tink

Большинство примитивов Tink поддерживают 5-байтовый выходной префикс, состоящий из:

  • 1-байтовая версия: 0x01
  • Подсказка по ключу длиной 4 байта: это идентификатор используемого ключа.

Некоторые устаревшие ключи также могут поддерживать байт версии 0x00 .

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

АЕАД

В общем, Tink форматирует зашифрованные тексты AEAD как:

prefix || IV || ciphertext || tag

если иное не указано в соответствующем RFC. prefix либо пуст, либо представляет собой 5-байтовый выходной префикс Tink.

AES-CTR-HMAC

Для AES-CTR-HMAC Tink вычисляет MAC со связанными данными (AD) следующим образом:

AD || IV || ciphertext || bitlen(AD)

где bitlen(AD) — длина AD в битах, представленная как 64-битное беззнаковое целое число с прямым порядком байтов. Эта схема HMAC соответствует проекту AES-CBC-HMAC от Mcgrew .

Детерминированный AEAD

Tink реализует RFC 5297 для AES-SIV, помещая синтетический вектор инициализации (SIV) в начало зашифрованного текста. Примитив может добавить 5-байтовый выходной префикс Tink.

В то время как RFC 5297 поддерживает список связанных данных, Tink поддерживает только один связанный данные, который соответствует списку с одним элементом в RFC 5297. Пустые связанные данные — это список с одним пустым элементом, а не пустой список.

Потоковое AEAD

См. AES-CTR HMAC и AES-GCM-HKDF .

Шифрование конверта

Шифрование конверта шифрует данные с помощью ключа шифрования данных DEK с использованием примитивов AEAD Tink. Шифрование работает следующим образом:

  • Новый DEK генерируется с использованием заданного ключевого шаблона (или ключевых параметров).
  • DEK сериализуется в строку байтов. Формат сериализации — сериализация буфера протокола типа ключа proto. Например, это сериализованное сообщение буфера протокола AesGcmKey , определенное в aes_gcm.proto для DEK с типом ключа AES GCM. См. сериализацию буфера протокола , чтобы узнать, как сериализовать буфер протокола.
  • Сериализованный DEK шифруется внешним поставщиком (например, GCP) в encrypted DEK .
  • DEK используется для шифрования открытого текста с соответствующими данными в ciphertext . Таким образом, ciphertext имеет тот же формат, что и примитив AEAD, соответствующий DEK .

Выходной формат шифрования конверта следующий:

encrypted DEK length || encrypted DEK || ciphertext

encrypted DEK length составляет 4 байта, при этом длина encrypted DEK сохраняется в виде 32-битного целого числа с прямым порядком байтов.

MAC

Tink следует соответствующим RFC. Примитивы могут добавлять к тегу 5-байтовый префикс вывода Tink.

набор PRF

Tink следует соответствующим RFC. Обратите внимание, что для набора PRF тип ключа отличается от типа ключа MAC того же алгоритма тем, что не включает длину вывода. Клавиши набора PRF никогда не добавляют префикс вывода Tink. Это гарантирует, что выходной сигнал на самом деле является PRF.

Гибридное шифрование

Общий формат гибридного шифрования Tink следующий:

prefix || encapsulated_key || encrypted_data

prefix либо пуст, либо представляет собой 5-байтовый выходной префикс Tink. Каждый тип ключа содержит информацию о том, сколько байтов нужно проанализировать и как проанализировать эти байты из encapsulated_key .

HPKE (гибридное шифрование с открытым ключом)

Tink следует стандарту HPKE, определенному в RFC 9180 . Набор шифров HPKE включает следующие три примитива.

  • Механизм инкапсуляции ключей (KEM)
  • Функция деривации ключей (KDF)
  • Аутентифицированное шифрование со связанными данными (AEAD)

Стандарт HPKE не определяет общий формат проводов в RFC 9180, раздел 10 . Реализация HPKE от Tink использует следующие значения encapsulated_key и encrypted_data .

  • encapsulated_key
    • Сериализованный открытый ключ отправителя
    • Определено как enc в RFC 9180, раздел 4.1.
    • Формат определяется конкретным используемым HPKE KEM.
  • encrypted_data
    • Зашифрованный текст и тег (т. е. ciphertext || tag без IV)
    • Определено как ct в RFC 9180, раздел 4.
    • Формат определяется конкретным используемым HPKE AEAD.
X25519 КЭМ на базе Диффи-Хеллмана

Для X25519 DHKEM значение enc представляет собой 32-байтовый открытый ключ Диффи-Хеллмана отправителя.

ECIES-AEAD-HKDF

Для реализации ECIES-AEAD-HKDF от Tink encapsulated_key — это выходные данные механизма инкапсуляции ключей (KEM), а encrypted_data — это выходные данные механизма инкапсуляции данных (DEM).

КЕМ

В зависимости от типа ключа Tink использует сжатые и несжатые точки эллиптической кривой, следуя стандартам кодирования RFC 8422 / ANSI.X9-62.2005 . Для несжатых точек за байтом 0x04 следуют координаты x и y как целые числа фиксированного размера. Для сжатых координат используется байт 0x02 или 0x03 и координата x как целое число фиксированного размера. Для X25519 используется определение RFC 7748 (координата x как целое число фиксированного размера).

немецкая марка

Для encrypted_data Tink использует тот же формат, что и AEAD. Это включает в себя указание IV.

Ключевое происхождение

Сначала вычисляется координата x x_ss общей точки. Затем ключ для AEAD устанавливается на:

HKDF(ikm = encapsulated_key || x_ss, salt = salt_of_key, info = context_info, length = dem_key_size)

где encapsulated_key — это полный вывод KEM в байтах.

Цифровые подписи

Tink следует соответствующим RFC. Примитивы могут добавлять к генерируемому тегу 5-байтовый префикс вывода Tink.

ECDSA

В зависимости от поля EcdsaSignatureEncoding в ключе формат подписи ECDSA — либо IEEE P1363 , либо ASN.1 DER .

Формат подписи IEEE P1363 : r || s , где r и s дополнены нулями и имеют тот же размер в байтах, что и порядок кривой. Например, для кривой NIST P-256 r и s дополняются нулями до 32 байтов.

Подпись DER кодируется с использованием ASN.1 :

ECDSA-Sig-Value :: = SEQUENCE { r INTEGER, s INTEGER }

В частности, кодировка:

0x30 || totalLength || 0x02 || r's length || r || 0x02 || s's length || s

Tink следует лучшим практикам проверки подписей, принимая только подписи ECDSA в кодировке DER (альтернативные подписи в кодировке BER недействительны).

Это помогает предотвратить атаки на гибкость сигнатур, которые часто затрагивают криптовалютные системы .