Spójność

Ważne jest, aby Tink działał „tak samo” we wszystkich językach programowania. To pojęcie nie jest proste, ale najważniejsze jest to, że:

Aby zachować spójność, Tink używa testów międzyjęzykowych, które można znaleźć w repozytorium GitHub. Te testy sprawdzają spójność i współdziałanie różnych języków.

Jednak zdefiniowanie spójności nie jest tak proste, jak mogłoby się wydawać. Dlatego na tej stronie podajemy naszą definicję roboczą. Tink zapewnia 2 typy spójności:

Kontekst

Ogólnie Tink udostępnia te interfejsy API:

  • Manipulowanie zestawem kluczy: Tink udostępnia interfejsy API do dodawania nowych kluczy do zestawu kluczy, usuwania kluczy z zestawu kluczy i zmiany klucza podstawowego w zestawie kluczy.

  • Serializacja zbioru kluczy: Tink udostępnia interfejsy API do serializacji zbioru kluczy do sekwencji bajtów i odwrotnie, do analizowania zbioru kluczy z sekwencji bajtów.

  • Tworzenie elementów podstawowych: Tink udostępnia interfejs API do tworzenia interfejsu elementu podstawowego ze zbioru kluczy. Na przykład, aby utworzyć obiekt Aead ze zbioru kluczy w języku Java, użytkownik wywołuje keysetHandle.getPrimitive(config, Aead.class).

  • Użycie elementu podstawowego: interfejs utworzony na etapie tworzenia elementu podstawowego udostępnia interfejs API do wykonywania operacji kryptograficznych.

W przypadku tych interfejsów API należy zadać 2 ważne pytania:

  • Tworzenie: czy w przypadku danego zserializowanego zbioru kluczy, języka i elementu podstawowego można utworzyć element podstawowy z tego zbioru kluczy w danym języku?

  • Ocena: jeśli element podstawowy można utworzyć w danym języku z danego zestawu kluczy, jak zachowuje się obiekt elementu podstawowego?

Warto zauważyć, że Tink nie zapewnia spójności podczas analizowania zbioru kluczy. Możliwe jest na przykład, że Tink C++

  • prawidłowo analizuje zbiory kluczy zawierające klucze CHACHA20-POLY1305, mimo że operacje AEAD CHACHA20-POLY1305 nie są zaimplementowane w Tink;
  • prawidłowo analizuje zbiory kluczy z kluczami o długości 1 bajta, co nie powiedzie się we wszystkich operacjach kryptograficznych.

Te zachowania mogą się zmieniać w wersjach podrzędnych.

Spójność ocen

Spójność oceny jest ważniejsza niż spójność procesu tworzenia: jeśli AEAD w Javie nie może odszyfrować szyfrowania AEAD w C++, użytkownicy mają poważny problem.

Ogólnie rzecz biorąc, Tink dąży do zachowania spójności w oczywisty sposób w przypadku elementów podstawowych. Jeśli na przykład plik binarny C++ oblicza podpis za pomocą public_key_sign->Sign(data), odpowiednie wywołanie weryfikacji Java publicKeyVerify.verify(signature, data) powinno się powieść.

Jednak nawet w tym przypadku istnieją pewne zastrzeżenia. Na przykład zwracany typ metody aead.Encrypt w języku Java to byte[]. Zgodnie ze specyfikacją języka Java (JLS) §10.7 długość tablicy jest typu int, który zgodnie z §JLS 4.2.1 może wynosić maksymalnie 2147483647. Dlatego szyfrowanie tablicy o długości 2147483647 nie powiedzie się w języku Java: szyfrowanie wiąże się z pewnym narzutem, co oznacza, że dane wyjściowe byłyby zbyt długie. Jednak w innych językach szyfrowanie takich danych wejściowych jest dozwolone.

Dlatego Tink zapewnia spójność oceny: jeśli w przypadku danego zbioru kluczy utworzenie elementu podstawowego powiedzie się w 2 językach, będą one działać tak samo.

Wyjątkiem jest to, że niektóre operacje mogą się nie powieść w pewnych wyjątkowych okolicznościach.

Regularne tworzenie treści

Tworzenie elementów podstawowych nie zawsze się udaje w przypadku wszystkich zestawów kluczy. Na przykład Tink nie pozwala użytkownikom na utworzenie klucza AesSivKey, jeśli materiał klucza ma długość 128 bitów.

Tink zapewnia jednak spójność w następujący sposób: jeśli 2 języki obsługują dany typ klucza, zbiór kluczy, dla których można utworzyć obiekt podstawowy, pokrywa się. Oczywiście, jeśli język nie obsługuje danego typu klucza, nie można utworzyć obiektu podstawowego.

Spójność tworzenia jest mniej ważna niż spójność oceny i jest więcej wyjątków od tej reguły niż w przypadku spójności oceny. Te ograniczenia są opisane na liście obsługiwanych typów kluczy. Na przykład w przypadku klucza typu ECIES Tink umożliwia wybór krzywej eliptycznej do uzgadniania kluczy, ale Java nie obsługuje X25519. Dlatego tworzenie klucza przy użyciu X25519 w języku Java nie powiedzie się.

  1. W tym dokumencie używamy terminu Keyset na określenie obiektu, który w większości języków nazywa się KeysetHandle. ↩