이 페이지에서는 키 및 기본 출력에 대한 Tink 와이어 형식을 설명합니다. 이 이 문서는 다른 언어를 추가하고자 하는 암호학자를 대상으로 합니다. 유선 연결을 원하는 다른 상위 수준의 암호화 라이브러리 관리 및 관리 담당자 호환 모드일 수 있습니다. 모든 연령대를 대상으로 하지 않습니다.
키 세트 직렬화
Tink는 Google protobuf를 사용하여 키 세트를 직렬화합니다.
- 직렬화된 바이너리 키 세트는 tink.proto. 키의 KeyData 값 속성은 직렬화된 proto를 제공합니다.
- JSON 직렬화된 키 세트는 JSON 형식으로 직렬화된 키 세트 프로토입니다. KeyData 값은 여전히 바이너리 직렬화된 proto입니다.
- 암호화된 키 세트는 tink.proto. 암호화된 바이너리 직렬화된 키 세트를 포함합니다. 선택적으로 몇 가지 암호화되지 않은 KeysetInfo 메타데이터가 있습니다.
Tink 출력 프리픽스
대부분의 Tink 프리미티브는 다음으로 구성된 5바이트 출력 접두사를 지원합니다.
- 1바이트 버전:
0x01 - 4바이트 키 힌트: 사용된 키의 키 ID입니다.
일부 기존 키는 버전 바이트 0x00도 지원할 수 있습니다.
이 프리픽스는 인증되지 않았으며 보안을 위해 사용할 수 없습니다. 있습니다. Tink는 이를 복호화 또는 확인 속도를 높이기 위한 힌트로 사용합니다.
AEAD
일반적으로 Tink는 AEAD 암호문의 형식을 다음과 같이 지정합니다.
prefix || IV || ciphertext || tag
(해당 RFC에서 달리 지정되지 않은 경우) prefix 필드가 비어 있음
또는 5바이트 Tink 출력 프리픽스를 포함합니다.
AES-CTR-HMAC
AES-CTR-HMAC의 경우 Tink는 연결된 데이터 (AD)를 사용하여 다음과 같이 MAC를 계산합니다.
AD || IV || ciphertext || bitlen(AD)
여기서 bitlen(AD)는 64비트 big-endian으로 표현되는 AD의 길이(비트)입니다.
부호 없는 정수입니다. 이 HMAC 체계는 AES-CBC-HMAC의
Mcgrew.
결정론적 AEAD
Tink는 AES-SIV를 위해 RFC 5297을 구현하여 합성 초기화 벡터 (SIV)가 있습니다. 프리미티브는 5바이트 Tink 출력 접두사를 추가할 수 있습니다.
RFC 5297은 관련 데이터 목록을 지원하지만 Tink는 하나의 관련 데이터(RFC 5297의 요소 하나가 있는 목록에 상응) 빈 관련 데이터는 빈 요소가 하나인 목록입니다. 목록.
스트리밍 AEAD
봉투 암호화
봉투 암호화는 다음을 사용하여 데이터 암호화 키(DEK)로 데이터를 암호화합니다.
Tink의 AEAD 프리미티브 암호화는 다음과 같이 작동합니다.
- 지정된 키 템플릿 (또는 키 매개변수)을 사용하여 새
DEK가 생성됩니다. DEK는 바이트 문자열로 직렬화됩니다. 직렬화 형식으로 키 유형 proto의 프로토콜 버퍼 직렬화입니다. 예를 들어 이것은 다음 위치에 정의된 직렬화된AesGcmKey프로토콜 버퍼 메시지 키 유형 AES GCM의 DEK의 경우 aes_gcm.proto 직렬화하는 방법은 프로토콜 버퍼 직렬화를 참고하세요. 프로토콜 버퍼입니다.- 직렬화된
DEK는 외부 제공업체 (예: GCP)에 의해 암호화됩니다.encrypted DEK로 변환합니다. DEK는 연결된 데이터가 있는 일반 텍스트를ciphertext입니다. 따라서ciphertext는 AEAD 프리미티브와 형식이 정확히 동일합니다.DEK에 해당합니다.
봉투 암호화의 출력 형식은 다음과 같습니다.
encrypted DEK length || encrypted DEK || ciphertext
encrypted DEK length는 4바이트로 encrypted DEK의 길이를 저장합니다.
32비트 big-endian 정수로 표현해야 합니다.
MAC
Tink는 해당 RFC를 따릅니다. 프리미티브는 5바이트 Tink 출력을 추가할 수 있음 접두어를 추가합니다.
PRF 설정됨
Tink는 해당 RFC를 따릅니다. PRF 세트의 경우 키 유형이 다릅니다. 출력 길이를 포함하지 않음으로써 동일한 알고리즘의 MAC 키 유형으로부터 추출됩니다. PRF Set 키는 Tink 출력 프리픽스를 추가하지 않습니다. 이렇게 하면 출력이 실제로 PRF
하이브리드 암호화
Tink 하이브리드 암호화의 일반적인 전송 형식은 다음과 같습니다.
prefix || encapsulated_key || encrypted_data
prefix는 비어 있거나 5바이트 Tink 출력 프리픽스입니다. 각 키 유형에는 다음이 포함됩니다.
파싱하려는 바이트 수와 이러한 바이트를 파싱하는 방법에 대한 정보를
encapsulated_key
HPKE (하이브리드 공개 키 암호화)
Tink는 RFC 9180에 정의된 HPKE 표준을 따릅니다. HPKE 암호화 기술에는 다음과 같은 세 가지 프리미티브가 있습니다.
- 키 캡슐화 메커니즘 (KEM)
- 키 파생 함수 (KDF)
- 연결된 데이터로 인증 암호화 (AEAD)
HPKE 표준은 RFC 9180, 섹션
10을 참조하세요. Tink의 HPKE 구현은 다음을 사용합니다.
encapsulated_key 및 encrypted_data 값.
encapsulated_key- 발신자의 직렬화된 공개 키
enc(으)로 정의됨: RFC 9180, 섹션 4.1- 사용된 특정 HPKE KEM에 따라 결정되는 형식
encrypted_data- 암호 및 태그 (예:
ciphertext || tagIV 제외) ct(으)로 정의됨: RFC 9180, 섹션 4- 사용된 특정 HPKE AEAD에 따라 결정되는 형식
- 암호 및 태그 (예:
X25519 디피-헬만 기반 KEM
X25519 DHKEM의 경우 enc 값은 발신자의 32바이트 Diffie-Hellman 공개입니다.
키를 누릅니다.
ECIES-AEAD-HKDF
Tink의 ECIES-AEAD-HKDF 구현의 경우 encapsulated_key는 출력입니다.
키 캡슐화 메커니즘 (KEM)의 역할을 하며 encrypted_data는 출력
DEM (데이터 캡슐화 메커니즘)의
KEM
키 유형에 따라 Tink는 압축된 타원 곡선과 비압축 타원 곡선을 사용합니다.
RFC 8422/ANSI.X9-62.2005 인코딩 표준을 따릅니다. 대상
0x04 바이트 뒤에 x 및 y가 옵니다.
좌표입니다. 압축된 좌표의 경우 0x02 바이트
또는 0x03이고 x 좌표가 고정 크기 정수로 사용됩니다. X25519의 경우
RFC 7748 정의가 사용됩니다 (고정 크기 정수로서의 x 좌표).
DEM
encrypted_data의 경우 Tink는 AEAD와 동일한 형식을 사용합니다. 여기에는
있습니다.
키 파생
먼저 공유 지점의 x 좌표 x_ss를 계산합니다. 이
그러면 AEAD가 다음과 같이 설정됩니다.
HKDF(ikm = encapsulated_key || x_ss, salt = salt_of_key, info = context_info, length = dem_key_size)
여기서 encapsulated_key는 바이트 단위의 전체 KEM 출력입니다.
디지털 서명
Tink는 해당 RFC를 따릅니다. 프리미티브는 5바이트 Tink 출력을 추가할 수 있음 접두어를 추가합니다.
ECDSA
키의 EcdsaSignatureEncoding 필드에 따라
ECDSA 서명 형식은 IEEE P1363 또는 ASN.1 DER입니다.
IEEE P1363 서명 형식은 r || s이며, 여기서 r 및 s는 다음과 같습니다.
0으로 패딩되고 크기(바이트 단위)가 곡선의 순서와 동일합니다. 대상
예를 들어 NIST P-256 곡선의 경우 r 및 s는 32바이트까지 0으로 패딩됩니다.
DER 서명은 ASN.1를 사용하여 인코딩됩니다.
ECDSA-Sig-Value :: = SEQUENCE { r INTEGER, s INTEGER }
특히 인코딩은 다음과 같습니다.
0x30 || totalLength || 0x02 || r's length || r || 0x02 || s's length || s
Tink는 서명 확인 권장사항을 따르며 DER로 인코딩된 ECDSA 서명 (대체 BER로 인코딩된 서명은 유효하지 않음)
이는 종종 영향을 받는 시그니처 가변성 공격을 방지하는 데 도움이 됩니다. 암호화폐 시스템을 다룹니다.