Format przewodu Tink

Na tej stronie opisano format przewodu Tink dla kluczy i podstawowych danych wyjściowych. jest przeznaczona dla kryptografii, którzy chcą dodać więcej języków Tink i opiekunowie innych wysokopoziomowych bibliotek kryptograficznych, którzy szukają przewodów trybu zgodności. Nie jest przeznaczona dla wszystkich odbiorców.

Serializacja zestawu kluczy

Tink używa protokołu Google do zserializacji swoich zbiorów kluczy.

• Plik binarny zserializowany to proto zserializowanego zbioru kluczy zdefiniowane w tink.proto. Właściwość wartości klucza jest zserializowany odpowiedniego typu klucza.
• Zserializowany zbiór kluczy JSON to zserializowany zestaw kluczy w formacie JSON. Pamiętaj, że wartość KeyData to nadal binarny zserializowany protokół.
• Zaszyfrowany zbiór kluczy to zserializowany protokół EncryptedKeyst zdefiniowany w tink.proto. Zawiera zaszyfrowany zserializowany zestaw kluczy binarnych i opcjonalnie niektóre niezaszyfrowane metadane KeysetInfo.

Prefiks danych wyjściowych Tink

Większość podstawowych elementów Tink obsługuje 5-bajtowy prefiks danych wyjściowych składający się z:

• Wersja 1-bajtowa: 0x01
• 4-bajtowa wskazówka do klucza: to jest identyfikator używanego klucza.

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

Pamiętaj, że ten prefiks nie jest uwierzytelniony i nie można na nim polegać ze względów bezpieczeństwa w celach informacyjnych. Tink wykorzystuje go jako wskazówkę, która pozwala przyspieszyć odszyfrowywanie lub weryfikację.

AEAD

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

prefix || IV || ciphertext || tag

o ile nie określono inaczej w odpowiednim dokumencie RFC. Pole prefix jest puste lub 5-bajtowy prefiks danych wyjściowych 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ść reklamy w bitach przedstawiona jako 64-bitowy big-endian. liczba całkowita bez znaku. Ten schemat HMAC jest zgodny z wersją roboczą AES-CBC-HMAC od Mcgrew.

Deterministyczny AEAD

Tink stosuje standard RFC 5297 dla AES-SIV, umieszczając kod syntetyczny wektora inicjującego (SIV) na początku tekstu zaszyfrowanego. Obiekt podstawowy może dodać 5-bajtowy prefiks danych wyjściowych Tink.

Choć RFC 5297 obsługuje listę powiązanych danych, Tink obsługuje tylko ściśle 1 powiązane dane, które odpowiada liście z jednym elementem zgodnie ze standardem RFC 5297. Puste powiązane dane to lista zawierająca 1 pusty element z listy.

Strumieniowe przesyłanie AEAD

Patrz: AES-CTR HMAC i AES-GCM-HKDF

Szyfrowanie danych koperty

Szyfrowanie w kopercie szyfruje dane kluczem szyfrowania danych DEK przy użyciu Podstawowe funkcje AEAD Tink. Szyfrowanie działa w ten sposób:

• Na podstawie danego szablonu klucza (lub kluczowych parametrów) zostanie wygenerowany nowy DEK.
• Pole DEK jest zserializowane w ciągu bajtów. Format serializacji serializacja bufora protokołu o typie klucza proto. Jest to na przykład zserializowany komunikat bufora protokołu AesGcmKey zdefiniowany w aes_gcm.proto dla klucza DEK typu AES GCM. Sposób serializowania znajdziesz w sekcji o serializacji bufora protokołu. bufor protokołu.
• Zserializowany plik DEK jest szyfrowany przez dostawcę zewnętrznego (na przykład GCP), w encrypted DEK.
• Interfejs DEK służy do szyfrowania zwykłego tekstu z powiązanymi danymi w ciphertext Zatem ciphertext ma dokładnie ten sam format co obiekt podstawowy AEAD odpowiadający 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-bitowa liczba całkowita bigendian.

MAC

Tink jest zgodny z odpowiednimi RFC. Elementy podstawowe mogą dodawać 5-bajtowe dane wyjściowe Tink do tagu.

Zbiór PRF

Tink jest zgodny z odpowiednimi RFC. Należy pamiętać, że dla zestawu PRF typ klucza różni się z typu klucza MAC tego samego algorytmu, nie uwzględniając długości wyjściowej. Klucze zestawu PRF nigdy nie dodają prefiksu danych wyjściowych Tink. Dzięki temu dane wyjściowe będą PRF.

Szyfrowanie hybrydowe

Ogólny format przewodu w szyfrowaniu hybrydowym Tink jest następujący:

prefix || encapsulated_key || encrypted_data

Pole prefix jest puste lub zawiera 5-bajtowy prefiks danych wyjściowych Tink. Każdy typ klucza zawiera (liczba bajtów do przeanalizowania i sposobu ich analizy) encapsulated_key

HPKE (hybrydowe szyfrowanie klucza publicznego)

Tink jest zgodny ze standardem HPKE zdefiniowanym w RFC 9180. Zestaw szyfrów 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 przewodu w sekcji RFC 9180, w sekcji 10. Implementacja HPKE w Tink wykorzystuje ten encapsulated_key i encrypted_data.

• encapsulated_key
  • Zserializowany klucz publiczny nadawcy
  • Zdefiniowano jako enc w RFC 9180, sekcja 4.1
  • Format określony przez konkretny użyty kod HPKE KEM
• encrypted_data
  • szyfrowany tekst i tag (np. ciphertext || tag bez IV)
  • Zdefiniowano jako ct w RFC 9180, sekcja 4
  • Format określany na podstawie konkretnego używanego rozwiązania HPKE AEAD

X25519 KEM z siedzibą w Diffie-Hellmanem

W przypadku jednostek DHKEM X25519 wartość enc to 32-bajtowa wartość publiczna nadawcy .

ECIES-AEAD-HKDF

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

KEM

W zależności od typu klucza Tink używa skompresowanej i nieskompresowanej krzywej eliptycznej zgodnie ze standardami kodowania RFC 8422/ANSI.X9-62.2005. Dla: nieskompresowanych punktów, po bajcie 0x04 występuje x i y jako liczby całkowite o stałym rozmiarze. W przypadku skompresowanych współrzędnych bajt 0x02 lub 0x03 i współrzędna x jako liczbę całkowitą o stałym rozmiarze. W przypadku usługi 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ślając IV.

Derywacja klucza

Najpierw obliczana jest współrzędna X x_ss wspólnego punktu. Klucz dla funkcji AEAD zostanie ustawione 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 bajtach.

Podpisy cyfrowe

Tink jest zgodny z odpowiednimi RFC. Elementy podstawowe mogą dodawać 5-bajtowe dane wyjściowe Tink do wygenerowanego tagu.

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 to z dopełnieniem zero i mieć ten sam rozmiar w bajtach co kolejność krzywej. Dla: na przykład w przypadku krzywej NIST P-256 wartości r i s są uzupełnione o 0 do 32 bajtów.

Podpis DER jest kodowany za pomocą algorytmu ASN.1:

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

Jest to przede wszystkim 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 zakodowane przy użyciu BER są nieprawidłowe).

Pomaga to zapobiegać atakom charakterystycznym dla plastyczności, które często obejmują w systemach kryptowalut.