รูปแบบสาย Tink

หน้านี้อธิบายรูปแบบการเขียนโค้ดของ Tink สำหรับคีย์และเอาต์พุตพื้นฐาน เอกสารประกอบนี้มีไว้สําหรับนักวิทยาการเข้ารหัสที่ต้องการเพิ่มภาษาอื่นๆ ลงใน Tink และผู้ดูแลไลบรารีการเข้ารหัสระดับสูงอื่นๆ ที่ต้องการโหมดที่เข้ากันได้กับ Wire ไม่ได้มีไว้สำหรับผู้ชมทั่วไป

การเรียงลำดับชุดคีย์

Tink ใช้ Google protobuf เพื่อจัดรูปแบบชุดคีย์

• ชุดคีย์ที่แปลงเป็นไบนารีเป็นโปรโตคอลชุดคีย์ที่แปลงเป็นไบนารีซึ่งกำหนดไว้ใน tink.proto พร็อพเพอร์ตี้ค่า KeyData ของคีย์คือโปรโตคอลที่แปลงเป็นอนุกรมของประเภทคีย์ที่เกี่ยวข้อง
• ชุดคีย์ที่แปลงเป็น JSON คือโปรโตคอลชุดคีย์ที่แปลงเป็นรูปแบบ JSON โปรดทราบว่าค่า KeyData ยังคงเป็นโปรโตคอลที่แปลงเป็นรูปแบบ Binary
• ชุดคีย์ที่เข้ารหัสคือโปรโต EncryptedKeyset ที่แปลงเป็นอนุกรม ซึ่งกำหนดไว้ใน tink.proto ไฟล์นี้มีชุดคีย์ที่ซีเรียลไบนารีที่เข้ารหัส และข้อมูลเมตา KeysetInfo บางส่วนที่ไม่ได้เข้ารหัส (ไม่บังคับ)

คำนำหน้าเอาต์พุต Tink

พรอมิเตอ Tink ส่วนใหญ่รองรับคำนำหน้าเอาต์พุต 5 ไบต์ที่ประกอบด้วยข้อมูลต่อไปนี้

• เวอร์ชัน 1 ไบต์: 0x01
• คำแนะนำคีย์ 4 ไบต์: นี่คือรหัสคีย์ของคีย์ที่ใช้

คีย์เดิมบางรายการอาจรองรับไบต์เวอร์ชัน 0x00 ด้วย

โปรดทราบว่าคำนำหน้านี้ไม่ได้ตรวจสอบสิทธิ์และไม่สามารถเชื่อถือเพื่อวัตถุประสงค์ด้านความปลอดภัย Tink จะใช้ข้อมูลนี้เป็นตัวช่วยในการถอดรหัสหรือการยืนยันให้เร็วขึ้น

AEAD

โดยทั่วไป Tink จะจัดรูปแบบข้อความที่เข้ารหัส AEAD ดังนี้

prefix || IV || ciphertext || tag

เว้นแต่จะระบุไว้เป็นอย่างอื่นใน RFC ที่เกี่ยวข้อง prefix ว่างเปล่าหรือเป็นคำนำหน้าเอาต์พุต Tink 5 ไบต์

AES-CTR-HMAC

สำหรับ AES-CTR-HMAC นั้น Tink จะคํานวณ MAC ด้วยข้อมูลที่เชื่อมโยง (AD) ดังนี้

AD || IV || ciphertext || bitlen(AD)

โดยที่ bitlen(AD) คือความยาวของ AD เป็นบิตที่แสดงเป็นจำนวนเต็มแบบไม่ระบุเครื่องหมาย Big-endian 64 บิต รูปแบบ HMAC นี้เป็นไปตามฉบับร่างสำหรับ AES-CBC-HMAC จาก Mcgrew

AEAD แบบกำหนด

Tink ใช้ RFC 5297 สำหรับ AES-SIV โดยวางเวกเตอร์การเริ่มต้น (SIV) สังเคราะห์ไว้ที่จุดเริ่มต้นของข้อความที่เข้ารหัส พรอมต์อาจเพิ่มคำนำหน้าเอาต์พุต Tink 5 ไบต์

แม้ว่า RFC 5297 จะรองรับรายการข้อมูลที่เชื่อมโยง แต่ Tink รองรับเฉพาะข้อมูลที่เชื่อมโยงเพียงรายการเดียว ซึ่งสอดคล้องกับรายการที่มีองค์ประกอบเดียวใน RFC 5297 ข้อมูลที่เชื่อมโยงที่ว่างเปล่าคือรายการที่มีองค์ประกอบว่างเปล่า 1 รายการ ไม่ใช่รายการว่างเปล่า

AEAD สตรีมมิง

โปรดดู AES-CTR HMAC และ AES-GCM-HKDF

การเข้ารหัสอีเมล

การเข้ารหัสแบบซองจดหมายจะเข้ารหัสข้อมูลด้วยคีย์การเข้ารหัสข้อมูล DEK โดยใช้พรอมิเมิ AEAD ของ Tink การเข้ารหัสจะทำงานดังนี้

• ระบบจะสร้าง DEK ใหม่โดยใช้เทมเพลตคีย์ (หรือพารามิเตอร์คีย์) ที่ระบุ
• DEK จะได้รับการแปลงเป็นสตริงไบต์ รูปแบบการจัดรูปแบบเป็นรูปแบบการจัดรูปแบบ Protocol Buffer ของโปรโตคอลประเภทคีย์ ตัวอย่างเช่น ข้อความบัฟเฟอร์โปรโตคอล AesGcmKey ที่ซีเรียลไลซ์ซึ่งกำหนดไว้ใน aes_gcm.proto สำหรับ DEK ของคีย์ประเภท AES GCM ดูวิธีจัดรูปแบบบัฟเฟอร์โปรโตคอลได้ที่การจัดรูปแบบบัฟเฟอร์โปรโตคอล
• DEK ที่แปลงเป็นอนุกรมจะได้รับการเข้ารหัสโดยผู้ให้บริการภายนอก (เช่น GCP) เป็น encrypted DEK
• DEK ใช้เพื่อเข้ารหัสข้อความธรรมดาที่มีข้อมูลที่เกี่ยวข้องเป็น ciphertext ดังนั้น ciphertext จึงมีรูปแบบเหมือนกับองค์ประกอบพื้นฐาน AEAD ทั้งหมดที่สอดคล้องกับ DEK

รูปแบบเอาต์พุตของการเข้ารหัสโฟลเดอร์เอกสารมีดังนี้

encrypted DEK length || encrypted DEK || ciphertext

encrypted DEK length มีความยาว 4 ไบต์ โดยจัดเก็บความยาวของ encrypted DEK เป็นจำนวนเต็มแบบ Big Endian 32 บิต

MAC

Tink ปฏิบัติตาม RFC ที่เกี่ยวข้อง พรอมิเตออาจเพิ่มคำนำหน้าเอาต์พุต Tink 5 ไบต์ลงในแท็ก

ชุด PRF

Tink ปฏิบัติตาม RFC ที่เกี่ยวข้อง โปรดทราบว่าสำหรับชุด PRF ประเภทคีย์จะแตกต่างจากประเภทคีย์ MAC ของอัลกอริทึมเดียวกันตรงที่ไม่รวมความยาวเอาต์พุต คีย์ชุด PRF จะไม่เพิ่มคำนำหน้าเอาต์พุต Tink วิธีนี้ช่วยให้มั่นใจว่าเอาต์พุตเป็น PRF จริง

การเข้ารหัสแบบผสม

รูปแบบทั่วไปของสายสำหรับการเข้ารหัสแบบผสมของ Tink มีดังนี้

prefix || encapsulated_key || encrypted_data

prefix ว่างเปล่าหรือเป็นคำนำหน้าเอาต์พุต Tink 5 ไบต์ คีย์แต่ละประเภทจะมีข้อมูลเกี่ยวกับจำนวนไบต์ที่จะแยกวิเคราะห์ และวิธีแยกวิเคราะห์ไบต์เหล่านั้นจากencapsulated_key

HPKE (การเข้ารหัสคีย์สาธารณะแบบผสม)

Tink เป็นไปตามมาตรฐาน HPKE ที่ระบุไว้ใน RFC 9180 ชุดการเข้ารหัส HPKE ประกอบด้วยองค์ประกอบพื้นฐาน 3 รายการต่อไปนี้

• กลไกการห่อหุ้มคีย์ (KEM)
• ฟังก์ชันการสร้างคีย์ (KDF)
• การเข้ารหัสที่ตรวจสอบสิทธิ์แล้วพร้อมข้อมูลที่เกี่ยวข้อง (AEAD)

มาตรฐาน HPKE ไม่ได้กำหนดรูปแบบการเดินสายทั่วไปใน RFC 9180 ส่วนที่ 10 การติดตั้งใช้งาน HPKE ของ Tink ใช้ค่า encapsulated_key และ encrypted_data ต่อไปนี้

• encapsulated_key
  • คีย์สาธารณะที่แปลงเป็นอนุกรมของผู้ส่ง
  • หมายถึง enc ใน RFC 9180, ส่วนที่ 4.1
  • รูปแบบที่กําหนดโดย KEM ของ HPKE ที่เฉพาะเจาะจงที่ใช้
• encrypted_data
  • ข้อความที่เข้ารหัสและแท็ก (เช่น ciphertext || tag ที่ไม่มี IV)
  • หมายถึง ct ในRFC 9180 ส่วนที่ 4
  • รูปแบบที่กําหนดโดย AEAD ของ HPKE ที่เฉพาะเจาะจงที่ใช้

KEM อิงตาม Diffie-Hellman ของ X25519

สำหรับ DHKEM ของ X25519 ค่า enc คือคีย์สาธารณะ Diffie-Hellman 32 ไบต์ของผู้ส่ง

ECIES-AEAD-HKDF

สำหรับการใช้งาน ECIES-AEAD-HKDF ของ Tink 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 ซึ่งรวมถึงการระบุ IV

การสร้างคีย์

ก่อนอื่น ระบบจะคํานวณพิกัด 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 ที่เกี่ยวข้อง พรอมิเอตอาจเพิ่มคำนำหน้าเอาต์พุต Tink 5 ไบต์ลงในแท็กที่สร้างขึ้น

ECDSA

รูปแบบลายเซ็น ECDSA จะเป็น IEEE P1363 หรือ ASN.1 DER ทั้งนี้ขึ้นอยู่กับช่อง EcdsaSignatureEncoding ในคีย์

รูปแบบลายเซ็น IEEE P1363 คือ r || s โดยที่ r และ s มีการเติม 0 ตรงตำแหน่งท้ายและมีขนาดเป็นไบต์เท่ากับลําดับของเส้นโค้ง เช่น สำหรับเส้นโค้ง NIST P-256 ระบบจะเติม 0 ต่อท้าย r และ s เป็น 32 ไบต์

ลายเซ็น DER ที่เข้ารหัสโดยใช้ ASN.1

ECDSA-Sig-Value :: = SEQUENCE { r INTEGER, s INTEGER }

โดยการเข้ารหัสมีดังนี้

0x30 || totalLength || 0x02 || r's length || r || 0x02 || s's length || s

Tink ปฏิบัติตามแนวทางปฏิบัติแนะนำสำหรับการยืนยันลายเซ็นโดยยอมรับเฉพาะลายเซ็น ECDSA ที่เข้ารหัส DER (ลายเซ็นที่เข้ารหัส BER รูปแบบอื่นจะใช้ไม่ได้)

ซึ่งจะช่วยป้องกันการโจมตีแบบปรับเปลี่ยนลายเซ็นได้ ซึ่งมักส่งผลกระทบต่อระบบคริปโตเคอเรนซี