Format przewodu Tink

Na tej stronie opisano format przewodu Tink na potrzeby kluczy i podstawowych danych wyjściowych. Dokumentacja jest przeznaczona dla kryptografów, którzy chcą dodać do Tink dodatkowe języki, oraz dla właścicieli innych zaawansowanych bibliotek kryptograficznych, którzy potrzebują trybu zgodnego z przewodem. Nie jest przeznaczona dla wszystkich odbiorców.

Serializacja zestawu kluczy

Tink wykorzystuje protobuf Google do serializowania swoich zestawów kluczy.

  • Zserializowany binarny zestaw kluczy to zserializowany proto zbioru kluczy zdefiniowany w tink.proto. Właściwość wartości KeyData klucza to zserializowany proto odpowiedniego typu klucza.
  • Zserializowany zestaw kluczy JSON to zserializowany zestaw kluczy w formacie JSON. Wartość KeyData to nadal binarny zserializowany proto.
  • Zaszyfrowany zestaw kluczy to zserializowany protokół EncryptedKeyst zdefiniowany w tink.proto. Zawiera zaszyfrowany binarny zserializowany zestaw kluczy i opcjonalnie niektóre niezaszyfrowane metadane KeysetInfo.

Prefiks wyjściowy Tink

Większość elementów podstawowych Tink obsługuje 5-bajtowy prefiks danych wyjściowych, który składa się z:

  • Wersja jednobajtowa: 0x01
  • Wskazówka dotycząca klucza z 4 bajtami: to identyfikator używanego klucza.

Niektóre starsze klucze mogą również obsługiwać bajty wersji 0x00.

Pamiętaj, że ten prefiks nie jest uwierzytelniony i nie może być wykorzystywany do celów związanych z bezpieczeństwem. Tink wykorzystuje je jako wskazówkę, aby przyspieszyć odszyfrowywanie lub weryfikację.

program AEAD,

Ogólnie Tink formatuje tekst szyfrowany AEAD jako:

prefix || IV || ciphertext || tag

chyba że w odpowiednim dokumencie RFC określono inaczej. Pole prefix jest puste lub zawiera 5-bajtowy prefiks danych wyjściowych Tink.

AES-CTR-HMAC

W przypadku AES-CTR-HMAC Tink oblicza adres MAC z powiązanymi danymi (AD) w następujący sposób:

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

gdzie bitlen(AD) to długość usługi AD w bitach wyrażona w 64-bitowej bez znaku w postaci 64-bitowej liczby całkowitej. Ten schemat HMAC jest zgodny z wersją roboczą formatu AES-CBC-HMAC z Mcgrew.

Deterministyczne AEAD

W przypadku AES-SIV Tink implementuje RFC 5297, umieszczając syntetyczny wektor inicjujący (SIV) na początku tekstu szyfrowania. Element podstawowy może dodać 5-bajtowy prefiks danych wyjściowych Tink.

Chociaż standard RFC 5297 obsługuje listę powiązanych danych, Tink obsługuje tylko dokładnie 1 powiązaną dane, która odpowiada liście w dokumencie RFC 5297 z jednym elementem. Puste powiązane dane to lista z jednym pustym elementem, a nie pusta lista.

Strumieniowe przesyłanie AEAD

Zobacz AES-CTR HMAC i AES-GCM-HKDF.

Szyfrowanie danych w danych koperty

Szyfrowanie danych w danych koperty szyfruje dane kluczem szyfrującym dane DEK, wykorzystując podstawowe elementy Tink AEAD. Szyfrowanie działa w ten sposób:

  • Na podstawie danego szablonu klucza (lub kluczowych parametrów) generowany jest nowy element DEK.
  • Element DEK jest zserializowany do ciągu bajtowego. Format serializacji oparty na zserializacji bufora protokołu dla protokołu typu klucza proto. Jest to na przykład zserializowany komunikat bufora protokołu AesGcmKey zdefiniowany w pliku aes_gcm.proto dla klucza DEK typu klucza AES GCM. Informacje o tym, jak zserializować bufor protokołu, znajdziesz w sekcji o serializacji bufora protokołu.
  • Zserializowany DEK jest szyfrowany przez dostawcę zewnętrznego (np. GCP) w encrypted DEK.
  • Pole DEK służy do szyfrowania zwykłego tekstu wraz z powiązanymi danymi w usłudze ciphertext. Zatem ciphertext ma dokładnie taki sam format jak element podstawowy AEAD, który odpowiada DEK.

Format wyjściowy szyfrowania danych koperty jest następujący:

encrypted DEK length || encrypted DEK || ciphertext

encrypted DEK length ma 4 bajty i przechowuje długość encrypted DEK jako 32-bitową liczbę całkowitą big-endian.

MAC

Tink jest zgodny z odpowiednimi dokumentami RFC. Elementy podstawowe mogą dodać do tagu 5-bajtowy prefiks wyjściowy Tink.

Zestaw PRF

Tink jest zgodny z odpowiednimi dokumentami RFC. Pamiętaj, że typ klucza PRF różni się od typu klucza MAC tego samego algorytmu tym, że nie ma długości wyjściowej. Klucze zestawu PRF nigdy nie dodają prefiksu danych wyjściowych Tink. Dzięki temu wynik będzie faktyczny PRF.

Szyfrowanie hybrydowe

Ogólny format przewodów w przypadku szyfrowania hybrydowego Tink wygląda tak:

prefix || encapsulated_key || encrypted_data

Pole prefix jest puste lub zawiera 5-bajtowy prefiks danych wyjściowych Tink. Każdy typ klucza zawiera informacje o liczbie bajtów do przeanalizowania oraz o sposobie ich analizowania z encapsulated_key.

HPKE (hybrydowe szyfrowanie klucza publicznego)

Tink jest zgodny ze standardem HPKE zdefiniowanym w RFC 9180. Pakiet szyfrowania HPKE zawiera 3 poniższe podstawowe elementy.

  • Mechanizm hermetyzacji klucza (KEM)
  • Funkcja derywacji klucza (KDF)
  • Uwierzytelnione szyfrowanie z powiązanymi danymi (AEAD)

Standard HPKE nie definiuje ogólnego formatu przewodów w RFC 9180, sekcja 10. Implementacja HPKE Tink używa poniższych wartości encapsulated_key i encrypted_data.

  • encapsulated_key
    • Zserializowany klucz publiczny nadawcy
    • Zdefiniowana jako enc w RFC 9180, sekcja 4.1
    • Format określany przez konkretny użyty HPKE KEM
  • encrypted_data
    • Tekst szyfrowany i tag (np. ciphertext || tag bez IV)
    • Zdefiniowana jako ct w RFC 9180, sekcja 4
    • Format określany na podstawie konkretnego używanego modelu HPKE AEAD
KEM oparty na technologii Diffiego-Hellmana X25519

W przypadku kluczy DHKEM X25519 wartość enc to 32-bajtowy publiczny klucz Diffiego-Hellmana nadawcy.

ECIES-AEAD-HKDF

W przypadku implementacji ECIES-AEAD-HKDF programu Tink encapsulated_key jest danymi wyjściowymi mechanizmu hermetycznego (KEM), a encrypted_data to dane wyjściowe tego mechanizmu.

KEM

W zależności od typu klucza Tink używa skompresowanych i nieskompresowanych punktów krzywych eliptycznych zgodnie ze standardami kodowania RFC 8422/ANSI.X9-62.2005. W przypadku nieskompresowanych punktów po bajcie 0x04 znajdują się współrzędne x i y w postaci liczb całkowitych o stałym rozmiarze. W przypadku skompresowanych współrzędnych używany jest bajt 0x02 lub 0x03 i współrzędna x jako liczba całkowita o stałym rozmiarze. W przypadku X25519 używana jest definicja RFC 7748 (współrzędna x jako liczba całkowita o stałym rozmiarze).

DEM

W przypadku encrypted_data Tink używa tego samego formatu co AEAD. Obejmuje to IV.

Derywacja klucza

Najpierw obliczana jest współrzędna x x_ss udostępnianego punktu. Klucz AEAD zostaje ustawiony na:

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

gdzie encapsulated_key to pełne dane wyjściowe KEM w postaci bajtów.

Podpisy cyfrowe

Tink jest zgodny z odpowiednimi dokumentami RFC. Elementy podstawowe mogą dodać do generowanego tagu 5-bajtowy prefiks wyjściowy Tink.

ECDSA

W zależności od pola EcdsaSignatureEncoding w kluczu format podpisu ECDSA to IEEE P1363 lub ASN.1 DER.

Format podpisu IEEE P1363 to r || s, gdzie r i s są dopełnione zerem i mają taki sam rozmiar w bajtach jak kolejność krzywej. Na przykład w przypadku krzywej NIST P-256 wartości r i s są dopełnione do 32 bajtów.

Podpis DER jest kodowany za pomocą ASN.1:

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

Przede wszystkim chodzi o kodowanie:

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

Tink stosuje sprawdzone metody weryfikacji podpisu, akceptując tylko podpisy ECDSA z kodowaniem DER (alternatywne podpisy z kodowaniem BER są nieprawidłowe).

Pomaga to zapobiegać atakom na ciągłość znaków, które często mają wpływ na systemy kryptowalut.