ความสม่ำเสมอ

สิ่งสำคัญคือ Tink ต้องมีลักษณะการทำงาน "เหมือนกัน" ในทุกภาษาโปรแกรม แนวคิดนี้ก็ไม่ได้ตรงไปตรงมา แต่สิ่งที่สำคัญที่สุดคือ

เพื่อคงความสอดคล้องกัน Tink ใช้การทดสอบข้ามภาษาซึ่งมีอยู่ในที่เก็บ GitHub ข้ามภาษา การทดสอบเหล่านี้จะยืนยันความสอดคล้องและความสามารถในการทำงานร่วมกันของภาษาต่างๆ

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

บริบท

Tink มี API ต่อไปนี้ในระดับสูง

  • การจัดการคีย์เซ็ต: Tink จะจัดเตรียม API เพื่อเพิ่มคีย์ใหม่ลงในชุดคีย์ นำคีย์ออกจากชุดคีย์ และเปลี่ยนคีย์หลักในชุดคีย์

  • การทำให้เป็นอนุกรมของคีย์เซ็ต: Tink จะให้บริการ API เพื่อเรียงลำดับชุดคีย์เป็นลำดับไบต์ และแยกวิเคราะห์ชุดคีย์จากชุดไบต์ตามลำดับ

  • การสร้างแบบพื้นฐาน: Tink มี API สำหรับสร้างอินเทอร์เฟซสำหรับคีย์ชุดแบบเดิม เช่น หากต้องการสร้างออบเจ็กต์ Aead จากชุดคีย์ใน Java ผู้ใช้จะเรียก keysetHandle.getPrimitive(Aead.class, config)

  • การใช้งานเบื้องต้น: อินเทอร์เฟซที่สร้างขึ้นในขั้นตอนการสร้างพื้นฐานจะมี API สำหรับดำเนินการเข้ารหัส

มีคำถามสำคัญ 2 ข้อที่ควรถามเกี่ยวกับ API เหล่านี้

  • การสร้าง: สำหรับชุดคีย์แบบอนุกรม ภาษา และชุดคีย์พื้นฐาน เป็นไปได้ไหมที่จะสร้างคีย์ชุดนี้ในภาษาดังกล่าว

  • การประเมิน: หากสามารถสร้างค่าดั้งเดิมในบางภาษาได้จากชุดคีย์ที่กำหนด วัตถุพื้นฐานจะทำงานอย่างไร

สิ่งสำคัญที่ต้องทราบคือ Tink ไม่ให้ความสม่ำเสมอเมื่อแยกวิเคราะห์คีย์เซ็ต ตัวอย่างเช่น อาจเป็นไปได้ว่า Tink C++

  • แยกวิเคราะห์คีย์เซ็ตที่มีคีย์ CHACHA20-POLY1305 สำเร็จ แม้ว่าจะไม่มีการนำการดำเนินการ CHACHA20-POLY1305 AEAD ใน Tink ก็ตาม
  • แยกวิเคราะห์ชุดคีย์ด้วยคีย์ที่มีความยาว 1 ไบต์ได้สำเร็จ ซึ่งจะล้มเหลวในการดำเนินการเข้ารหัสทั้งหมด

ลักษณะการทำงานเหล่านี้อาจมีการเปลี่ยนแปลงในเวอร์ชันย่อย

ความสม่ำเสมอในการประเมิน

ความสม่ำเสมอในการประเมินผลมีความสำคัญมากกว่าความสม่ำเสมอในกระบวนการสร้าง หาก AEAD ใน Java ถอดรหัสการเข้ารหัส AEAD ใน C++ ไม่ได้ แสดงว่าผู้ใช้มีปัญหาร้ายแรง

โดยทั่วไป Tink มุ่งหวังให้มีความสม่ำเสมอในลักษณะที่เห็นได้ชัดสำหรับพื้นฐาน เช่น หากไบนารี C++ คำนวณลายเซ็นด้วย public_key_sign->Sign(data) การเรียก publicKeyVerify.verify(signature, data) สำหรับการยืนยัน Java ที่เกี่ยวข้องจะประสบความสำเร็จ

อย่างไรก็ตาม มีข้อควรระวังอยู่บ้าง เช่น ประเภทการแสดงผล aead.Encrypt ใน Java คือ byte[] ตาม Java Language Specification (JLS) §10.7 ความยาวของอาร์เรย์คือประเภท int ซึ่งต่อ §JLS 4.2.1 จะต้องไม่เกิน 2147483647 ดังนั้น การเข้ารหัสอาร์เรย์ที่มีความยาว 2147483647 จะไม่สำเร็จใน Java การเข้ารหัสมีโอเวอร์เฮดบางส่วน ซึ่งหมายความว่าเอาต์พุตจะยาวเกินไป อย่างไรก็ตาม การเข้ารหัสในภาษาอื่นๆ อนุญาตให้ป้อนข้อมูลดังกล่าวได้สำเร็จ

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

โดยมีข้อยกเว้นว่าการดำเนินการบางอย่างอาจล้มเหลวได้ในบางสถานการณ์

ความสม่ำเสมอในการสร้าง

การสร้างชุดคีย์พื้นฐานอาจไม่สำเร็จเสมอไปสำหรับชุดคีย์ทั้งหมด เช่น Tink ไม่อนุญาตให้ผู้ใช้สร้าง AesSivKey หากเนื้อหาคีย์มีความยาว 128 บิต

อย่างไรก็ตาม Tink ให้ความสอดคล้องกันดังนี้ หากทั้ง 2 ภาษารองรับประเภทคีย์ ชุดของคีย์ที่สามารถสร้างแบบพื้นฐานได้เหมือนกัน แน่นอนว่า หากภาษาไม่รองรับประเภทคีย์ คุณจะไม่สามารถสร้างออบเจ็กต์พื้นฐานได้

ความสม่ำเสมอในการสร้างสรรค์สำคัญน้อยกว่าความสม่ำเสมอในการประเมิน และมีข้อยกเว้นสำหรับกฎข้อนี้มากกว่าความสอดคล้องในการประเมินผล ข้อจำกัดเหล่านี้ระบุไว้ในรายการประเภทคีย์ที่รองรับ ตัวอย่างเช่น สำหรับประเภทคีย์ ECIES Tink จะเสนอตัวเลือกว่าเส้นโค้งวงรีใดที่ใช้สำหรับข้อตกลงคีย์ แต่ Java ไม่รองรับ X25519 ดังนั้น การสร้างคีย์โดยใช้ X25519 ใน Java จะล้มเหลว

  1. ในเอกสารนี้ เราใช้คำว่า Keyset เพื่อแสดงถึงออบเจ็กต์ที่เรียกว่า KeysetHandle ในภาษาส่วนใหญ่↩