รูปแบบสาย Tink

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

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

Tink ใช้ Google protobuf เพื่อเรียงชุดคีย์

• ชุดคีย์ซีเรียลแบบไบนารีคือ Keyset Pro แบบอนุกรมที่กำหนดใน tink.proto คุณสมบัติค่า KeyData ของคีย์คือโปรโตแบบอนุกรมของประเภทคีย์ที่เกี่ยวข้อง
• ชุดคีย์ที่อนุกรมของ JSON คือ Keyset Proto ที่ต่อเนื่องในรูปแบบ JSON โปรดทราบว่าค่า KeyData ยังคงเป็น Proto ที่อนุกรมแบบไบนารี
• ชุดคีย์ที่เข้ารหัสคือโปรโตคอล EncryptedKeyst ที่เรียงลำดับตามที่กำหนดไว้ใน tink.proto ชุดคีย์เซ็ตประกอบด้วยชุดคีย์อนุกรมแบบไบนารีที่เข้ารหัส และข้อมูลเมตา KeysetInfo บางอย่างที่ไม่เข้ารหัส

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

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

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

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

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

AEAD

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

prefix || IV || ciphertext || tag

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

CTR สำหรับ AES

สำหรับ 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 ข้อมูลที่เกี่ยวข้องที่ว่างเปล่าคือรายการที่มีเอลิเมนต์ที่ว่างเปล่าเพียงรายการเดียว ไม่ใช่รายการที่ว่างเปล่า

AEAD สตรีมมิง

ดู HMAC ของ AES-CTR และ AES-GCM-HKDF

การเข้ารหัสเอนเวโลป

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

• ระบบจะสร้าง DEK ใหม่โดยใช้เทมเพลตคีย์ที่ระบุ (หรือพารามิเตอร์คีย์)
• DEK ได้รับการกำหนดให้เป็นอนุกรมเป็นสตริงไบต์ รูปแบบการทำให้เป็นอนุกรม การเรียงอันดับบัฟเฟอร์โปรโตคอลของโปรโตคอลประเภทคีย์ ตัวอย่างเช่น นี่คือข้อความบัฟเฟอร์โปรโตคอล 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 ด้วยจำนวนเต็มขนาดใหญ่ 32 บิต

MAC

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

ตั้งค่า PRF

Tink เป็นไปตาม RFC ที่เกี่ยวข้อง โปรดทราบว่าสำหรับ PRF Set นั้น ประเภทคีย์จะต่างจากประเภทคีย์ 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
  • รูปแบบที่กำหนดโดย HPKE KEM ที่ใช้
• encrypted_data
  • ข้อความเข้ารหัสและแท็ก (เช่น ciphertext || tag โดยไม่มี IV)
  • กำหนดเป็น ct ใน RFC 9180 ส่วนที่ 4
  • รูปแบบที่กำหนดโดย HPKE AEAD ที่ใช้

X25519 KEM จาก Diffie-Hellman

สำหรับ X25519 DHKEM ค่า 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 r และ s จะมีการเพิ่มค่า 0 ลงใน 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 อื่นๆ ใช้ไม่ได้)

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