Trang này mô tả định dạng truyền dữ liệu của Tink cho các khoá và đầu ra nguyên thuỷ. Tài liệu này dành cho những nhà mật mã học muốn thêm các ngôn ngữ khác vào Tink và những người duy trì các thư viện mật mã cấp cao khác muốn có một chế độ tương thích với dây. Nội dung này không dành cho khán giả nói chung.
Chuyển đổi tuần tự bộ khoá
Tink sử dụng Google protobuf để chuyển đổi tuần tự các keyset.
- Keyset được chuyển đổi tuần tự nhị phân là một Keyset proto được chuyển đổi tuần tự được xác định trong tink.proto. Thuộc tính giá trị KeyData của một khoá là một giao thức được chuyển đổi tuần tự của loại khoá tương ứng.
- Một keyset được chuyển đổi tuần tự thành JSON là một Keyset proto được chuyển đổi tuần tự ở định dạng JSON. Xin lưu ý rằng giá trị KeyData vẫn là một giao thức được tuần tự hoá nhị phân.
- Bộ khoá được mã hoá là một proto EncryptedKeyset được chuyển đổi tuần tự, được xác định trong tink.proto. Tệp này chứa một keyset được mã hoá ở dạng nhị phân và không bắt buộc phải có một số siêu dữ liệu KeysetInfo chưa mã hoá.
Tiền tố đầu ra của Tink
Hầu hết các thành phần cơ bản của Tink đều hỗ trợ tiền tố đầu ra gồm 5 byte:
- Phiên bản 1 byte:
0x01 - Gợi ý về khoá 4 byte: Đây là mã nhận dạng khoá của khoá được dùng.
Một số khoá cũ cũng có thể hỗ trợ byte phiên bản 0x00.
Xin lưu ý rằng tiền tố này chưa được xác thực và không thể dựa vào cho mục đích bảo mật. Tink sử dụng khoá này làm gợi ý để tăng tốc quá trình giải mã hoặc xác minh.
AEAD
Nhìn chung, Tink định dạng văn bản mã hoá AEAD như sau:
prefix || IV || ciphertext || tag
trừ phi có quy định khác trong RFC tương ứng. prefix có thể là một tiền tố đầu ra Tink có độ dài 5 byte hoặc không có nội dung.
AES-CTR-HMAC
Đối với AES-CTR-HMAC, Tink tính toán MAC bằng dữ liệu được liên kết (AD) như sau:
AD || IV || ciphertext || bitlen(AD)
trong đó bitlen(AD) là độ dài của AD tính bằng bit, được biểu thị dưới dạng số nguyên 64 bit chưa ký có thứ tự từ lớn đến bé. Lược đồ HMAC này tuân theo bản nháp cho AES-CBC-HMAC của Mcgrew.
AEAD xác định
Tink triển khai RFC 5297 cho AES-SIV, đặt vectơ khởi tạo tổng hợp (SIV) ở đầu văn bản mã hoá. Nguyên thuỷ có thể thêm tiền tố đầu ra Tink gồm 5 byte.
Mặc dù RFC 5297 hỗ trợ một danh sách dữ liệu được liên kết, nhưng Tink chỉ hỗ trợ chính xác một dữ liệu được liên kết, tương ứng với một danh sách có một phần tử trong RFC 5297. Dữ liệu được liên kết trống là một danh sách có một phần tử trống, chứ không phải là một danh sách trống.
AEAD truyền trực tuyến
Hãy xem AES-CTR HMAC và AES-GCM-HKDF.
Mã hoá phong bì
Phương thức mã hoá phong bì mã hoá dữ liệu bằng khoá mã hoá dữ liệu DEK bằng các nguyên tắc AEAD của Tink. Quy trình mã hoá diễn ra như sau:
- Một
DEKmới được tạo bằng cách sử dụng một mẫu khoá (hoặc tham số khoá) nhất định. DEKđược chuyển đổi tuần tự thành một chuỗi byte. Định dạng chuyển đổi tuần tự là quá trình chuyển đổi tuần tự vùng đệm giao thức của proto loại khoá. Ví dụ: đây là thông báo vùng đệm giao thứcAesGcmKeyđược chuyển đổi tuần tự được xác định trong aes_gcm.proto cho DEK của loại khoá AES GCM. Hãy xem chuyển đổi tuần tự vùng đệm giao thức để biết cách chuyển đổi tuần tự vùng đệm giao thức.DEKđược chuyển đổi tuần tự sẽ được một nhà cung cấp bên ngoài (ví dụ: GCP) mã hoá thànhencrypted DEK.DEKđược dùng để mã hoá văn bản thuần tuý bằng dữ liệu được liên kết thànhciphertext. Vì vậy,ciphertextcó định dạng giống hệt như nguyên thuỷ AEAD tương ứng vớiDEK.
Định dạng đầu ra của phương thức mã hoá phong bì như sau:
encrypted DEK length || encrypted DEK || ciphertext
encrypted DEK length có kích thước 4 byte, lưu trữ độ dài của encrypted DEK dưới dạng số nguyên 32 bit có thứ tự byte lớn.
MAC
Tink tuân theo các RFC tương ứng. Các thành phần cơ bản có thể thêm tiền tố đầu ra Tink 5 byte vào thẻ.
PRF set
Tink tuân theo các RFC tương ứng. Xin lưu ý rằng đối với PRF Set, loại khoá sẽ khác với loại khoá MAC của cùng một thuật toán bằng cách không bao gồm độ dài đầu ra. Khoá PRF Set không bao giờ thêm tiền tố đầu ra Tink. Điều này đảm bảo đầu ra thực sự là một PRF.
Mã hoá kết hợp
Sau đây là định dạng chung của Tink cho mã hoá kết hợp:
prefix || encapsulated_key || encrypted_data
prefix có thể là một tiền tố đầu ra Tink có độ dài 5 byte hoặc không có gì. Mỗi loại khoá chứa thông tin về số lượng byte cần phân tích cú pháp và cách phân tích cú pháp các byte đó từ encapsulated_key.
HPKE (Mã hoá khoá công khai kết hợp)
Tink tuân theo tiêu chuẩn HPKE được xác định trong RFC 9180. Một bộ mật mã HPKE bao gồm 3 nguyên tắc sau.
- Cơ chế đóng gói khoá (KEM)
- Hàm dẫn xuất khoá (KDF)
- Mã hoá đã xác thực bằng dữ liệu liên kết (AEAD)
Tiêu chuẩn HPKE không xác định định dạng chung cho dữ liệu truyền qua mạng trong RFC 9180, Phần 10. Quá trình triển khai HPKE của Tink sử dụng các giá trị encapsulated_key và encrypted_data sau đây.
encapsulated_key- Khoá công khai được chuyển đổi tuần tự của người gửi
- Được xác định là
enctrong RFC 9180, Phần 4.1 - Định dạng do KEM HPKE cụ thể được dùng xác định
encrypted_data- Văn bản mã hoá và thẻ (tức là
ciphertext || tagmà không có IV) - Được xác định là
cttrong RFC 9180, Phần 4 - Định dạng do AEAD HPKE cụ thể được dùng xác định
- Văn bản mã hoá và thẻ (tức là
KEM dựa trên Diffie-Hellman X25519
Đối với DHKEM X25519, giá trị enc là khoá công khai Diffie-Hellman 32 byte của người gửi.
ECIES-AEAD-HKDF
Đối với việc triển khai ECIES-AEAD-HKDF của Tink, encapsulated_key là đầu ra của Cơ chế đóng gói khoá (KEM) và encrypted_data là đầu ra của Cơ chế đóng gói dữ liệu (DEM).
KEM
Tuỳ thuộc vào loại khoá, Tink sử dụng các điểm đường cong elip được nén và không nén, tuân theo các tiêu chuẩn mã hoá RFC 8422/ANSI.X9-62.2005. Đối với các điểm chưa nén, byte 0x04 sẽ theo sau là toạ độ x và y dưới dạng số nguyên có kích thước cố định. Đối với các toạ độ được nén, byte 0x02 hoặc 0x03 và toạ độ x dưới dạng số nguyên có kích thước cố định sẽ được dùng. Đối với X25519, định nghĩa RFC 7748 được dùng (toạ độ x là số nguyên có kích thước cố định).
DEM
Đối với encrypted_data, Tink sử dụng cùng một định dạng như AEAD. Việc này bao gồm cả việc chỉ định một IV.
Phái sinh khoá
Trước tiên, toạ độ x x_ss của điểm được chia sẻ sẽ được tính toán. Sau đó, khoá cho AEAD được đặt thành:
HKDF(ikm = encapsulated_key || x_ss, salt = salt_of_key, info = context_info, length = dem_key_size)
trong đó encapsulated_key là đầu ra KEM đầy đủ dưới dạng byte.
Chữ ký số
Tink tuân theo các RFC tương ứng. Các thành phần cơ bản có thể thêm tiền tố đầu ra Tink 5 byte vào thẻ được tạo.
ECDSA
Tuỳ thuộc vào trường EcdsaSignatureEncoding trong khoá, định dạng của chữ ký ECDSA là IEEE P1363 hoặc ASN.1 DER.
Định dạng của chữ ký IEEE P1363 là r || s, trong đó r và s được đệm bằng số 0 và có cùng kích thước tính bằng byte như thứ tự của đường cong. Ví dụ: đối với đường cong NIST P-256, r và s được thêm số 0 vào đầu để có 32 byte.
Chữ ký DER được mã hoá bằng ASN.1:
ECDSA-Sig-Value :: = SEQUENCE { r INTEGER, s INTEGER }
Cụ thể, mã hoá này là:
0x30 || totalLength || 0x02 || r's length || r || 0x02 || s's length || s
Tink tuân theo các phương pháp hay nhất để xác minh chữ ký, bằng cách chỉ chấp nhận chữ ký ECDSA được mã hoá DER (các chữ ký được mã hoá BER thay thế là không hợp lệ).
Điều này giúp ngăn chặn các cuộc tấn công giả mạo chữ ký, thường ảnh hưởng đến các hệ thống tiền mã hoá.
Giá trị băm trước Mu ML-DSA bên ngoài
Nguyên hàm Prehash chuyển một thông báo thành giá trị prehash, sau đó nguyên hàm SignPrehash sẽ ký giá trị này. Đối với ML-DSA ở chế độ External Mu, như mô tả trong RFC 9881, giá trị tiền băm là 69 byte với bố cục sau:
0xff || key_id (4 bytes, big-endian) || mu (64 bytes)
mulà đại diện cho thông báo ML-DSA, được tính làSHAKE256(tr || 0x00 || 0x00 || message, 64), trong đótrlà hàm băm 64 byte của khoá công khai,0x00đầu tiên là dấu phân cách miền FIPS 204 cho ML-DSA thuần tuý và0x00thứ hai là độ dài của chuỗi ngữ cảnh (trống). Vìtrđược lấy từ khoá công khai, nênmuđược liên kết bằng mật mã với khoá đó – mặc dù việc kiểm tra mối liên kết đòi hỏi phải có thông báo ban đầu.- Tiền tố 5 byte là khung Tink, không thuộc
mu. Thao tác này liên kết giá trị tiền băm với một khoá cụ thể, để SignPrehash biết khoá nào cần ký và có thể từ chối giá trị tiền băm mà không có khoá. Tiền tố là siêu dữ liệu thuần tuý và không liên kết gì về mặt mật mã: bất kỳ ai cũng có thể viết lại tiền tố này.
Hoạt động ký sẽ từ chối mọi dữ liệu đầu vào không chính xác là 69 byte, không bắt đầu bằng 0xff hoặc có mã khoá không khớp với khoá đã bật trong bộ khoá.