Format przewodu Tink

Ta strona opisuje format transmisji danych w Tink w przypadku kluczy i prostych danych wyjściowych. Dokumentacja jest przeznaczona dla kryptografów, którzy chcą dodać dodatkowe języki do Tink, oraz dla opiekunów innych bibliotek kryptograficznych wysokiego poziomu, którzy chcą korzystać z trybu zgodnego z protokołem. Nie jest przeznaczona dla wszystkich odbiorców.

Serializacja zbioru kluczy

Tink używa protokołu Google protobuf do serializacji zestawów kluczy.

• Binarny klucz zaszyfrowany to zaszyfrowany prototyp Keyset zdefiniowany w pliku tink.proto. Właściwość wartości KeyData klucza to serializowany prototyp odpowiedniego typu klucza.
• Zserializowany w formacie JSON klucz to prototyp klucza serializowany w formacie JSON. Pamiętaj, że wartość KeyData to nadal binarny serializowany proto.
• Zaszyfrowany zestaw kluczy to serializowany prototyp EncryptedKeyset zdefiniowany w pliku tink.proto. Zawiera zaszyfrowany binarny klucz zaszyfrowany i opcjonalnie niektóre nieszyfrowane metadane KeysetInfo.

Prefiks wyników Tink

Większość prymitywów Tink obsługuje prefiks wyjściowy o długości 5 bajtów, który składa się z:

• Wersja 1 bajta: 0x01
• 4 bajty podpowiedzi klucza: identyfikator klucza używanego w ramach klucza.

Niektóre starsze klucze mogą też obsługiwać bajt wersji 0x00.

Pamiętaj, że ten prefiks nie jest uwierzytelniony i nie można polegać na nim w celu zapewnienia bezpieczeństwa. Tink używa go jako wskazówki, aby przyspieszyć odszyfrowywanie lub weryfikację.

AEAD

Ogólnie Tink formatuje szyfrogramy AEAD w ten sposób:

prefix || IV || ciphertext || tag

chyba że inaczej określono w odpowiednim dokumencie RFC. prefix jest pusty lub jest 5-bajtowym prefiksem wyjściowym Tink.

AES-CTR-HMAC

W przypadku AES-CTR-HMAC Tink oblicza MAC z powiązanymi danymi (AD) w ten sposób:

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

gdzie bitlen(AD) to długość AD w bitach reprezentowana jako 64-bitowa liczba całkowita w formacie big-endian. Ten schemat HMAC jest zgodny z projektem algorytmu AES-CBC-HMAC autorstwa Mcgrewa.

Deterministyczne AEAD

Tink implementuje RFC 5297 dla AES-SIV, umieszczając syntetyczny wektor inicjalizacji (SIV) na początku szyfrogramu. Pierwotny typ danych może dodać 5-bajtowy prefiks wyjściowy Tink.

Standard RFC 5297 obsługuje listę powiązanych danych, ale Tink obsługuje tylko dokładnie 1 powiązane dane, co odpowiada liście z 1 elementem w standardzie RFC 5297. Pustymi powiązanymi danymi jest lista z jednym pustym elementem, a nie pusta lista.

Streaming AEAD

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

Szyfrowanie załączników

Szyfrowanie kopertowe szyfruje dane za pomocą klucza szyfrującego dane DEK przy użyciu prymitywnych funkcji AEAD z Tink. Szyfrowanie działa w ten sposób:

• Na podstawie danego szablonu klucza (lub parametrów klucza) zostanie wygenerowany nowy klucz DEK.
• Obiekt DEK jest serializowany w postaci ciągu bajtów. Format serializacji protokołu bufora prototypu typu klucza. Poniżej przedstawiono na przykład zakodowaną w buforze wiadomość AesGcmKey zdefiniowaną w pliku aes_gcm.proto dla DEK typu klucza AES GCM. Aby dowiedzieć się, jak zastosować serializację bufora protokołu, zapoznaj się z artykułem Serializacja bufora protokołu.
• Serializowany obiekt DEK jest szyfrowany przez zewnętrznego dostawcę (np. GCP) w postaci obiektu encrypted DEK.
• Klucz DEK służy do szyfrowania tekstu zwykłego z powiązanymi danymi w kluczu ciphertext. Wartość ciphertext ma dokładnie taki sam format jak element typu AEAD odpowiadający wartości DEK.

Format wyjściowy szyfrowania kopert:

encrypted DEK length || encrypted DEK || ciphertext

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

MAC

Tink stosuje odpowiednie standardy RFC. Elementy proste mogą dodawać do tagu 5-bajtowy prefiks wyjścia Tink.

Zestaw PRF

Tink stosuje odpowiednie standardy RFC. Pamiętaj, że w przypadku zbioru PRF typ klucza różni się od typu klucza MAC tego samego algorytmu, ponieważ nie zawiera długości danych wyjściowych. Klucze zestawu PRF nigdy nie dodają prefiksu danych wyjściowych Tink. Dzięki temu możesz mieć pewność, że dane wyjściowe to rzeczywiście token dostępu do danych.

Szyfrowanie hybrydowe

Ogólny format transmisji dla hybrydowego szyfrowania Tink:

prefix || encapsulated_key || encrypted_data

prefix jest pusty lub jest 5-bajtowym prefiksem wyjściowym Tink. Każdy typ klucza zawiera informacje o tym, ile bajtów należy przeanalizować i jak przeanalizować te bajty z encapsulated_key.

HPKE (hybrydowe szyfrowanie kluczem publicznym)

Tink stosuje standard HPKE określony w specyfikacji RFC 9180. Zestaw szyfrowania HPKE zawiera te 3 elementy:

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

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

• encapsulated_key
  • Seryjowany klucz publiczny nadawcy
  • Zdefiniowany jako enc w RFC 9180, sekcja 4.1
  • Format zależy od konkretnego użytego klucza publicznego HPKE.
• encrypted_data
  • tekst szyfrowany i tag (np. ciphertext || tag bez IV)
  • Zdefiniowana jako ct w RFC 9180, sekcja 4
  • Format określony przez konkretny używany certyfikat AEAD HPKE

KEM oparty na Diffie-Hellmanie X25519

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

ECIES-AEAD-HKDF

W przypadku implementacji ECIES-AEAD-HKDF firmy Tink encapsulated_key to dane wyjściowe mechanizmu szyfrowania klucza (KEM), a encrypted_data to dane wyjściowe mechanizmu szyfrowania danych (DEM).

KEM

W zależności od typu klucza Tink używa skompresowanych i nieskompresowanych punktów krzywej eliptycznej zgodnie ze standardami kodowania RFC 8422/ANSI.X9-62.2005. W przypadku nieskompresowanych punktów po bajcie 0x04 podana jest współrzędna x i współrzędna y jako liczby całkowite o stałym rozmiarze. W przypadku skompresowanych współrzędnych używa się bajtu 0x02 lub 0x03 oraz współrzędnej x jako liczby całkowitej 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 m.in. określenie IV.

Wyprowadzenie klucza

Najpierw obliczana jest współrzędna X x_ss wspólnego punktu. Klucz dla sekcji HEAD ma wtedy wartość:

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

gdzie encapsulated_key to pełny wynik KEM w bajtach.

podpisy cyfrowe,

Tink stosuje odpowiednie standardy RFC. Elementy proste mogą dodawać do generowanego tagu 5-bajtowy prefiks wyjścia Tink.

ECDSA

W zależności od pola EcdsaSignatureEncoding w kluczu podpis ECDSA może mieć format IEEE P1363 lub ASN.1 DER.

Format podpisu IEEE P1363 to r || s, gdzie r i s są wypełnione zerami i mają taki sam rozmiar w bajtach jak rząd krzywej. Na przykład w przypadku krzywej NIST P-256 wartości r i s są uzupełniane zerami do 32 bajtów.

Podpis DER jest kodowany za pomocą ASN.1:

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

W szczególności kodowanie jest:

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

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

Pomaga to zapobiegać atakom polegającym na manipulowaniu sygnaturą, które często dotyczą systemów kryptowalut.