รูปแบบสาย Tink

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

การเรียงอันดับคีย์เซ็ต

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

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

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

Tink Primes ส่วนใหญ่รองรับคำนำหน้าเอาต์พุตขนาด 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 จะรองรับรายการข้อมูลที่เกี่ยวข้องเท่านั้น ข้อมูลที่เชื่อมโยง 1 รายการ ซึ่งสอดคล้องกับรายการที่มีองค์ประกอบเดียวใน RFC 5297 ข้อมูลที่เกี่ยวข้องที่ว่างเปล่าคือรายการที่มีองค์ประกอบว่าง 1 รายการ และไม่ว่างเปล่า รายการ

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 Set จะไม่เพิ่มคำนำหน้าเอาต์พุต Tink ซึ่งช่วยให้แน่ใจว่าเอาต์พุต PRF

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

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

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 คือเอาต์พุต ของกลไกการห่อหุ้มข้อมูล (Data Encapsulation Mechanism (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

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

รูปแบบลายเซ็น IEEE P1363 คือ r || s โดยที่ r และ s คือ ไม่มีการเพิ่มใดๆ และมีขนาดไบต์เท่ากับลำดับของเส้นโค้ง สำหรับ เช่น สำหรับเส้นโค้ง 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 แบบอื่นไม่ถูกต้อง)

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