Tink는 모든 프로그래밍 언어에서 '동일하게' 작동해야 합니다.
이 개념은 간단하지 않지만 가장 중요한 것은 다음과 같습니다.
일관성을 유지하기 위해 Tink는 교차 언어 GitHub 저장소에서 찾을 수 있는 교차 언어 테스트를 사용합니다.
이러한 테스트는 다양한 언어의 일관성과 상호 운용성을 확인합니다.
그러나 일관성 정의는 예상만큼 간단하지 않습니다.
따라서 이 페이지에서는 실무에 대한 정의를 제공합니다. Tink는 기본적으로
두 가지 유형의 일관성을 제공합니다
평가 일관성: 주어진 키 세트1의 경우 프리미티브 생성이 두 언어에서 성공하면 동일하게 작동합니다.
생성 일관성:지원되는 키 유형 목록에 설명된 대로 언어가 키 세트의 모든 키 유형을 지원하는 경우 언어에서 프리미티브 생성이 성공합니다.
관련 정보
개략적으로 Tink는 다음과 같은 API를 제공합니다.
키 세트 조작: Tink는 새 키를 키 세트에 추가하고 키 세트에서 키를 삭제하며 키 세트의 기본 키를 변경하는 API를 제공합니다.
키 세트 직렬화: Tink는 키 세트를 일련의 바이트로 직렬화하고 반대로 일련의 바이트에서 키 세트를 파싱하는 API를 제공합니다.
기본 생성: Tink는 키 세트에서 프리미티브의 인터페이스를 만드는 API를 제공합니다. 예를 들어 자바의 키 세트에서 Aead 객체를 만들려면 사용자가 keysetHandle.getPrimitive(Aead.class, config)를 호출합니다.
기본 사용: 기본 생성 단계에서 생성된 인터페이스는 암호화 작업을 수행하는 API를 제공합니다.
이러한 API에 관해 다음과 같은 두 가지 중요한 질문을 던져 볼 수 있습니다.
생성: 특정 직렬화 키 세트, 언어 및 프리미티브에 대해 이 키 세트에서 해당 언어로 프리미티브를 만들 수 있나요?
평가: 주어진 키 세트에서 특정 언어로 프리미티브를 만들 수 있는 경우 프리미티브 객체는 어떻게 동작하나요?
Tink는 키 세트를 파싱할 때 일관성을 제공하지 않는다는 점에 유의해야 합니다. 예를 들어 Tink C++를
CHACHA20-POLY1305 AEAD 작업이 Tink에 구현되지 않았더라도 CHACHA20-POLY1305 키가 포함된 키 세트를 성공적으로 파싱합니다.
길이가 1바이트인 키로 키 세트를 성공적으로 파싱하며 이 경우 모든 암호화 작업에서 실패합니다.
이러한 동작은 마이너 버전에서 변경될 수 있습니다.
평가 일관성
생성 프로세스의 일관성보다 평가의 일관성이 더 중요합니다. Java의 AEAD가 C++에서 AEAD 암호화를 복호화할 수 없는 경우 사용자에게 심각한 문제가 발생합니다.
일반적으로 Tink는 프리미티브에 명확한 방식으로 일관성을 유지하는 것을 목표로 합니다. 예를 들어 C++ 바이너리가 public_key_sign->Sign(data)로 서명을 계산하면 상응하는 Java 확인 호출 publicKeyVerify.verify(signature, data)가 성공할 것으로 예상됩니다.
하지만 여기에도 몇 가지 주의 사항이 있습니다. 예를 들어 자바에서 aead.Encrypt의 반환 유형은 byte[]입니다.
자바 언어 사양 (JLS) §10.7에 따라 배열 길이는 int 유형이며, §JLS 4.2.1에 따라 최대 2147483647일 수 있습니다. 따라서 Java에서 길이가 2147483647인 배열 암호화는 실패합니다. 암호화에 약간의 오버헤드가 있어 출력이 너무 길어집니다. 그럼에도 불구하고, 다른 언어에서는 이러한 입력에 대해 암호화가 성공할 수 있습니다.
따라서 Tink는 평가 일관성을 제공합니다. 특정 키 세트의 경우 프리미티브 생성이 두 언어에서 성공하면 동일하게 동작합니다.
예외적인 상황에서는 일부 작업이 실패할 수 있습니다.
생성 일관성
모든 키 세트에 대해 프리미티브 생성이 항상 성공하는 것은 아닙니다. 예를 들어 Tink에서는 키 자료의 길이가 128비트인 경우 사용자가 AesSivKey를 만들도록 허용하지 않습니다.
그럼에도 Tink는 다음과 같이 일관성을 제공합니다. 두 언어가 모두 키 유형을 지원하는 경우 프리미티브를 만들 수 있는 키 집합이 일치합니다. 물론 언어에서 키 유형을 지원하지 않으면 원시 객체를 만들 수 없습니다.
생성 일관성은 평가 일관성보다 덜 중요합니다. 이 규칙에는 평가 일관성보다 예외가 더 많습니다.
이러한 제한사항은 지원되는 키 유형 목록에 설명되어 있습니다.
예를 들어 키 유형의 경우 ECIES Tink는 키 계약에 사용할 타원 곡선을 선택할 수 있지만 Java는 X25519를 지원하지 않습니다. 따라서 Java에서 X25519를 사용하여 키를 만들 수 없습니다.
이 문서에서는 대부분의 언어에서 Keyset라는 용어를 사용하여 KeysetHandle라는 객체를 나타냅니다. ↩
[null,null,["최종 업데이트: 2025-07-25(UTC)"],[[["\u003cp\u003eTink aims for cross-language consistency, ensuring the same behavior for a given keyset if primitive creation succeeds in multiple languages.\u003c/p\u003e\n"],["\u003cp\u003eTink defines two types of consistency: Evaluation Consistency (primitives behave the same across languages) and Creation Consistency (primitive creation success aligns with supported key types).\u003c/p\u003e\n"],["\u003cp\u003eWhile Tink strives for consistency, exceptions exist due to language limitations or specific key type support, which are documented for transparency.\u003c/p\u003e\n"],["\u003cp\u003eTink prioritizes Evaluation Consistency, as mismatched encryption/decryption between languages would pose significant issues.\u003c/p\u003e\n"],["\u003cp\u003eKeyset parsing consistency is not guaranteed, with behaviors subject to change across minor versions.\u003c/p\u003e\n"]]],["Tink ensures consistent cryptographic behavior across languages through evaluation and creation consistency. Evaluation consistency guarantees that if a primitive is created from a keyset in multiple languages, it will function identically. Creation consistency ensures that if two languages support a specific key type, primitive creation will succeed or fail for the same set of keys. Tink uses cross-language tests to maintain these consistencies and documents limitations in supported key types.\n"],null,["# Consistency\n\nIt's important that Tink behaves \"the same\" in all programming languages.\nThis concept is not straightforward, but most crucially:\n| **Key Point:** Tink provides evaluation consistency: For a given keyset, if primitive creation succeeds in two languages, the primitive behaves the same.\n\nTo maintain consistency, Tink uses cross-language tests which\ncan be found in the [cross-language GitHub\nrepository](https://github.com/tink-crypto/tink-cross-lang-tests).\nThese tests verify the consistency and interoperability of different languages.\n\nHowever, defining consistency is not as straightforward as one would expect.\nHence, this page provides our working definition. Basically, Tink provides\ntwo types of consistency:\n\n- **[Evaluation consistency:](#evaluation_consistency)** For a given keyset^[1](#fn1)^, if creation of the primitive succeeds in two languages, they behave the same.\n- **[Creation consistency:](#creation_consistency)** Creation of a primitive succeeds in a language if the language supports all key types in a keyset, as documented in [our list of supported key types](/tink/supported-key-types).\n\nContext\n-------\n\nOn a high level, Tink provides the following APIs:\n\n- **Keyset manipulation:** Tink provides APIs to add new keys to a keyset,\n remove keys from a keyset, and change the primary key in a keyset.\n\n- **Keyset serialization:** Tink provides APIs to serialize a keyset to\n a sequence of bytes, and conversely parse a keyset from a sequence of bytes.\n\n- **Primitive creation:** Tink provides an API to create an interface for\n a primitive from a keyset. For example, to create an `Aead` object from a\n keyset in Java, the user calls `keysetHandle.getPrimitive(Aead.class, config)`.\n\n- **Primitive usage:** The interface produced in the primitive creation step\n provides an API to perform cryptographic operations.\n\nThere are two important questions to ask about these APIs:\n\n- **Creation:**\n For a given serialized keyset, language, and primitive,\n is it possible to create the primitive from this keyset in the language?\n\n- **Evaluation:**\n If a primitive can be created in some language from a given\n keyset, how does the primitive object behave?\n\nIt is important to note that Tink does not provide consistency when parsing a\nkeyset. For example, it is possible that Tink C++\n\n- successfully parses keysets containing CHACHA20-POLY1305 keys, even though CHACHA20-POLY1305 AEAD operations are not implemented in Tink;\n- successfully parses keysets with keys that have a length of 1-byte, which will fail in all cryptographic operations.\n\nThese behaviors may change in minor versions.\n\nEvaluation consistency\n----------------------\n\nConsistency of evaluation is more important than any consistency in the creation\nprocess: if an AEAD in Java cannot decrypt the encryption of the AEAD in C++,\nusers have a serious problem.\n\nIn general, Tink aims to be consistent in the obvious way for primitives. For\nexample, if a C++ binary computes a signature\nwith `public_key_sign-\u003eSign(data)`, the corresponding Java verification\ncall `publicKeyVerify.verify(signature, data)` is expected to succeed.\n\nHowever, even here there are some caveats. For example,\nthe return type of `aead.Encrypt` in Java is a `byte[]`.\nPer Java Language Specification (JLS) §10.7, the length of an array is of\ntype `int` which per §JLS 4.2.1 can be a maximum of 2147483647. Hence,\nencryption of an array with a length of 2147483647 fails in Java: encryption\nhas some overhead, meaning\nthe output would be too long. Nevertheless, in other languages encryption\nis allowed to succeed for such inputs.\n\nHence, Tink provides evaluation consistency:\nFor a given keyset, if creation of the primitive succeeds in\ntwo languages, they behave the same.\n\nThe exception is that some operations may fail in some exceptional\ncircumstances.\n\nCreation consistency\n--------------------\n\nCreation of primitives does not always succeed for all keysets. For example,\nTink does not allow users to create an AesSivKey if the key material has a\nlength of 128 bits.\n\nNevertheless, Tink provides consistency as follows: if two languages both\nsupport a key type, the set of keys for which the primitive can be created\ncoincides. Of course, if a language does not support a key type, then no\nprimitive object can be created.\n\nCreation consistency is less important than evaluation consistency, and\nthere are more exceptions to this rule than for evaluation consistency.\nThese limitations are documented on\n[our list of supported key types](/tink/supported-key-types).\nFor example, for key type ECIES Tink offers a choice of which elliptic curve\nto use for key agreement, but Java does not support X25519. Hence,\ncreation of a key using X25519 in Java fails. \n\n*** ** * ** ***\n\n1. In this document, we use the term `Keyset` to denote the object called\n `KeysetHandle` in most languages. [↩](#fnref1)"]]
