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

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

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

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

บริบท

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

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

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

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

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

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

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

  • การประเมิน: หากสามารถสร้างพรีมิทิฟในบางภาษาจากคีย์เซ็ตที่ระบุได้ ออบเจ็กต์พรีมิทิฟจะมีลักษณะการทำงานอย่างไร

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

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

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

ความสอดคล้องของการประเมิน

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

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

อย่างไรก็ตาม แม้แต่ในกรณีนี้ก็ยังมีข้อควรระวังบางประการ ตัวอย่างเช่น ประเภทการแสดงผลของ aead.Encrypt ใน Java คือ byte[] ตามข้อกำหนดภาษา Java (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 ในภาษาต่างๆ ส่วนใหญ่ ↩