이 페이지는 Cloud Translation API를 통해 번역되었습니다.

일관성

Tink는 모든 프로그래밍 언어에서 '동일하게' 작동해야 합니다. 이 개념은 간단하지 않지만 가장 중요한 것은 다음과 같습니다.

일관성을 유지하기 위해 Tink는 교차 언어 GitHub 저장소에서 찾을 수 있는 교차 언어 테스트를 사용합니다. 이러한 테스트는 다양한 언어의 일관성과 상호 운용성을 확인합니다.

그러나 일관성 정의는 예상만큼 간단하지 않습니다. 따라서 이 페이지에서는 실무에 대한 정의를 제공합니다. Tink는 기본적으로 두 가지 유형의 일관성을 제공합니다

평가 일관성: 주어진 키 세트¹의 경우 프리미티브 생성이 두 언어에서 성공하면 동일하게 작동합니다.
생성 일관성: 지원되는 키 유형 목록에 설명된 대로 언어가 키 세트의 모든 키 유형을 지원하는 경우 언어에서 프리미티브 생성이 성공합니다.

평가 일관성

생성 프로세스의 일관성보다 평가의 일관성이 더 중요합니다. 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라는 객체를 나타냅니다. ↩

일관성

관련 정보

평가 일관성

생성 일관성