ในขณะที่ NTT ตรวจสอบสิ่งนี้ ฉันกำลังโพสต์สิ่งนี้เป็น "วิธีแก้ปัญหา":
โดยการตรวจสอบการทำงาน
เป็นโมฆะ camellia_setup256 (const char * คีย์ที่ไม่ได้ลงนาม, u32 * คีย์ย่อย)
เป็นที่ชัดเจนว่าการเข้าถึง 'คีย์ย่อย' ของเวกเตอร์เอาต์พุตทั้งหมดนั้นดำเนินการโดยใช้มาโคร
#define CamelliaSubkeyL(INDEX) (คีย์ย่อย[(INDEX)*2])
#define CamelliaSubkeyR(INDEX) (คีย์ย่อย[(INDEX)*2 + 1])
ไม่มีที่ไหนเลยในฟังก์ชันที่มีการอ้างอิงถึงดัชนี 1 และ 33 ที่จะพบ ดัชนีเหล่านี้จะเขียนถึงตำแหน่งคำที่ 2, 3, 66 และ 67 ซึ่งเป็นคำทั้ง 4 คำที่ไม่ได้เขียนไว้ในแบบทดสอบ
พอร์ต OpenSSL ของ Camellia cipher (Apache License 2.0) ไม่มีปัญหานี้: การประกอบ และ ค มีอยู่.
อัปเดต:
ฉันได้เปรียบเทียบสองพอร์ตข้างต้นกับรหัสจาก NTT ที่เชื่อมโยงในคำถามดังนี้:
- สร้างคีย์สุ่ม 256 บิต
- สร้างบล็อกสุ่ม 16 ไบต์
- ด้วยการนำไปใช้งาน 3 รายการเข้ารหัสบล็อกเพื่อเปรียบเทียบข้อความเข้ารหัส
สรุป: แม้จะมีคำที่ไม่ได้ใช้ใน keyTable สำหรับการนำ NTT ไปใช้งาน แต่ในคู่คีย์/บล็อกทั้งหมดหลายล้านคู่ที่ทดสอบ ข้อความไซเฟอร์เท็กซ์ทั้งหมดที่เกิดจากการนำไปใช้งาน 3 รายการก็ตรงกัน
แก้ไข:
เนื่องจากไม่มีผลกับการเข้ารหัส/ถอดรหัส การแก้ไขจะลดขนาดคีย์ตารางจาก 68 เป็น 64 คำเท่านั้นเนื่องจากโค้ดนั้นสะอาดมากและการเข้าถึงทั้งหมดดำเนินการด้วยมาโครสองตัวด้านบน จึงจำเป็นต้องเปลี่ยนเพียง 16 บรรทัด (ทดสอบด้วยคีย์ 256 บิตเท่านั้น):
- ค้นหามาโครทั้งหมดที่เข้าถึงดัชนี 24 และเปลี่ยนเป็น 1
- ค้นหามาโครทั้งหมดที่เข้าถึงดัชนี 32 และเปลี่ยนเป็น 24
ฉันได้ทดสอบสิ่งนี้ในกระบวนการที่อธิบายไว้ข้างต้น