การสุ่มและการรับรองความถูกต้องของเอาต์พุตค่าสั้น (48 บิต)

ฉันต้องการใช้ไคลเอนต์ที่สร้างค่า 48 บิตแบบสุ่มและส่งเป็นข้อความออกอากาศ เราถือว่ายังมีผู้รับที่ถูกต้องได้รับค่าเหล่านั้น (ดังนั้นจึงมีการตรวจสอบสิทธิ์ล่วงหน้าบางประเภทที่เกิดขึ้นแล้ว แต่ก็ไม่สำคัญในที่นี้ นอกจากนี้ เรายังสามารถถือว่าไคลเอ็นต์/ผู้รับใช้คีย์ร่วมร่วมกัน $K$). เนื่องจากข้อความเหล่านี้เป็นข้อความออกอากาศ จึงหมายความว่าทุกคนสามารถสกัดกั้นค่าเหล่านั้นได้ ฉันต้องการให้ค่าเหล่านั้นมีสองคุณสมบัติ:

1. ผู้โจมตีคาดเดาค่าสุ่มถัดไปในลำดับได้ยาก
2. ผู้รับควรสามารถตรวจสอบได้ว่าค่าเหล่านี้มาจากไคลเอนต์เฉพาะ

ฉันกำลังคิดโครงร่างง่ายๆ ที่ทำสิ่งต่อไปนี้:

ลูกค้า

1. $t$ = AES-CTR($K$, nonce||ตัวนับ, Random_plaintext)â

2. $r = t â K$ (เก็บ 48 บิตสุดท้าย)

3. ออกอากาศ $t, r$

ฉันใช้ AES-CTR เพื่อสร้างสตริงการค้นหาแบบสุ่มชั่วคราว $t$ จากนั้น XOR ด้วยคีย์อีกครั้งเพื่อสร้างค่าสุ่มของฉันจากนั้นฉันก็เก็บ 48 บิตสุดท้ายและออกอากาศทั้งคู่ $t$ และ $r$. จากนั้นผู้รับสามารถ:

เครื่องรับ

1. $r' = t â K$ (เก็บ 48 บิตสุดท้าย)
2. ตรวจสอบ $r' == อาร์$

หากการตรวจสอบสำเร็จ เขาจะรับรองความถูกต้องของลูกค้าเพราะมีเพียงเขาเท่านั้นที่รู้รหัสเดียวกัน $K$. นอกจากนี้ ค่าที่เป็นผลลัพธ์ของ AES-CTR ควรเป็นค่าที่ค่อนข้างสุ่ม หมายความว่าเป็นการยากที่จะคาดเดาค่าถัดไป

แผนนี้บรรลุความต้องการของฉันหรือไม่? การตัดทอน 48 บิตสุดท้ายมีความเสี่ยงด้านความปลอดภัยหรือไม่?

แผนนี้บรรลุความต้องการของฉันหรือไม่? การตัดทอน 48 บิตสุดท้ายมีความเสี่ยงด้านความปลอดภัยหรือไม่?

แผนการถูกทำลายโดยศัตรูที่แฝงอยู่ซึ่งได้รับคู่เดียว $(t,r)$. สังเกตว่าสามารถกู้คืนคีย์ 48 บิตสุดท้ายเป็น $K[:48] = t \oบวก r$. ดังนั้นตอนนี้ผู้โจมตีสามารถส่งโดยพลการ $(t^*, r^*)$ ค่าที่ผู้รับจะยอมรับได้ จำได้ว่าผู้ตรวจสอบทำสิ่งต่อไปนี้

$r' = t' \oบวก K$ (เก็บเฉพาะ 48 บิตสุดท้าย); ตรวจสอบ $r = r'$

เราเห็นว่าไม่จำเป็นต้องมีความรู้เกี่ยวกับคีย์ที่เหลือ

นอกจากนี้ ค่า 48 บิตยังมีการป้องกันการชนกันต่ำ แต่นั่นอาจใช้ได้สำหรับแอปพลิเคชันของคุณ...

เล่นซ้ำ: การโจมตีที่ตรงไปตรงมามากขึ้นคือการเล่นซ้ำของทั้งคู่ $(ร, เสื้อ)$. คำอธิบายไม่ได้บอกว่าผู้รับตรวจสอบสิ่งนี้อย่างไร

ทางออกที่เป็นไปได้: จากคำอธิบายเบื้องต้น ดูเหมือนว่าเครื่องรับมีข้อจำกัดในการพูดเชิงคำนวณพอสมควร และพวกเขาสามารถคำนวณได้เฉพาะ xors เท่านั้นและไม่ใช่ AES-CTR เป็นต้น ซึ่งจะเป็นเรื่องแปลกดังต่อไปนี้

ดังนั้นจึงมีการตรวจสอบสิทธิ์ล่วงหน้าบางประเภทที่ได้เกิดขึ้นแล้ว แต่ที่นี่ไม่ได้มีความสำคัญ

อย่างไรก็ตาม วิธีแก้ไขที่เป็นไปได้คือใช้ฟังก์ชันสุ่มหลอกสองตัว หากเครื่องรับสามารถทำได้มากกว่า xors (สงสัยจะปลอดภัย...). เริ่มแรกให้ขยาย $K$ เข้าไปข้างใน $K_1, K_2, K_3$ มีความยาวพอเหมาะ

ผู้ส่งดำเนินการดังต่อไปนี้

1. $r=$ AES-CTR$(K_1, ตัวนับ)$ (เก็บ 48 บิตสุดท้าย)
2. ส่ง $เคาน์เตอร์, r, \tau = HMAC(K_2, ตัวนับ,r)$

ผู้รับดำเนินการดังต่อไปนี้

1. เมื่อได้รับ $r, \tau$, ตรวจสอบ $\tau$
2. เคาน์เตอร์ตรวจสอบเพิ่มขึ้น
3. ทำซ้ำ $r$.

ข้อสังเกตบางประการ:

• การแพร่ภาพที่นี่ไม่จำเป็นด้วยซ้ำหากผู้ส่งและผู้รับเป็นคนที่ใช้นาฬิการ่วมกัน
• ทางเลือกมีปัญหาเล็กน้อยเมื่อพูดถึงความทนทานในกรณีของการรีบูตดังที่ Paul ระบุไว้ในความคิดเห็น