Score:2

CTR ทับซ้อนกับ IV แบบสุ่ม

ธง cn

ปัญหา:

ฉันกังวลเล็กน้อยเกี่ยวกับการนับซ้ำในโหมด CTR เมื่อใช้ IV แบบสุ่ม

  • หากคุณแบ่ง (เช่น half IV, half counter) จะเพิ่มโอกาสของ IV เดียวกัน (ซึ่งมีขนาดเล็กกว่า) และจำกัดความยาวของข้อความ (หากน้อยกว่าครึ่งหนึ่ง)
  • หากคุณเริ่มต้นด้วย IV เต็มบล็อก ตัวนับอาจทับซ้อนกัน

ฉันอยากได้ตัวนับบล็อก IV เต็มและครึ่งบล็อกโดยไม่ทับซ้อนกัน

วิธีแก้ปัญหาที่เสนอ:

แทนที่จะใช้ IV แบบสุ่มเป็น nonce ในตัวนับ เราสร้างคีย์ใหม่โดยเข้ารหัส IV ด้วยคีย์ เราใช้คีย์ใหม่นั้นในการเข้ารหัส ตัวนับเริ่มต้นด้วยศูนย์ครึ่งหนึ่งและครึ่งหนึ่งของ IV หรือด้วยมาสเตอร์คีย์ครึ่งหนึ่ง เพื่อทำ การโจมตีหลายเป้าหมาย ยากขึ้น

สมมติว่าคีย์, IV, รหัสบล็อกมีขนาดเท่ากันทั้งหมด

$k_{data} = E_{k_{master}}(IV)$

$keystream_i = E_{k_{data}}(ครึ่ง(IV) || counter_i)$

สิ่งนี้ดีขึ้น / แย่ลงหรือไม่?

ฉันกังวลว่าสิ่งนี้จะทำให้คีย์อ่อนลง ชุดค่าผสมของคีย์และ IV ที่แตกต่างกันจะให้คีย์ใหม่เหมือนกัน แต่โดยพื้นฐานแล้วมันเหมือนกับฟังก์ชันการหาค่าคีย์อย่างง่ายด้วยเกลือสิ่งนี้ควรอนุญาตให้ทุกข้อความได้รับการผูกมัดวันเกิด

kelalaka avatar
in flag
มีตัวนับแนวทาง/LFSR [NIST 800-38-a](https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-38a.pdf) และ [AES CTR: Random IV](https: //crypto.stackexchange.com/q/87064/18298)
cn flag
วิธีแรกนั้นสมบูรณ์แบบ แต่ใช้ไม่ได้จริง วิธีที่สองด้วยการสุ่ม IV นั้นจำกัดจำนวนข้อความหรือความยาวของข้อความตามที่กล่าวไว้
Maarten Bodewes avatar
in flag
ฉันคิดว่าเป็นการดีที่สุดที่จะคิดว่าโครงสร้างของคุณเป็น KBKDF ในกรณีนั้น คำถามจะกลายเป็น: KDF นั้นปลอดภัยแค่ไหน? แต่มีหลายอย่างที่ไม่ชัดเจนสำหรับฉัน หากคุณเขียน $k = E_k(IV)$ คุณหมายความว่า $k$ จะถูกแทนที่หรือไม่ ในกรณีนั้น คุณได้สร้าง stateful protocol โดยปกติคุณจะมี $k_{master}$ และหลาย $k_{data}$ นอกจากนี้ เราควรถือว่า AES 128 บิตเสมอหรือไม่ การเข้ารหัสบล็อกเดียวจะไม่สร้างคีย์ 192 หรือ 256 บิต
cn flag
คีย์ถูกแทนที่สำหรับข้อความเท่านั้น มันไม่เปลี่ยนมาสเตอร์คีย์ ฉันคิดว่าคีย์นั้นมีขนาดเท่ากับรหัสบล็อก
Maarten Bodewes avatar
in flag
ฉันไม่รู้ว่าจู่ๆ $half(k_{master})$ มาจากไหน แต่โดยทั่วไปแล้วคุณจะไม่ใส่ข้อมูลสำคัญในคีย์สตรีมของคุณ ถ้าฉันจำไม่ผิด ในตอนแรกคุณจะมีตัวนับตามศูนย์
cn flag
ฉันพูดถึงมันเป็นตัวเลือก นี่คือการทำให้การโจมตีหลายเป้าหมายยากขึ้น อาจเป็น $half(IV)$ ก็ได้ แต่ฉันคิดว่า $k_{master}$ ดีกว่าเพราะเป็นความลับ
cn flag
ในความคิดที่สอง ฉันคิดว่า $half(IV)$ จะปลอดภัยกว่า มีโอกาสน้อยที่จะทำซ้ำ
Score:-1
ธง mc

หากคุณสามารถพูดได้ว่ามีการจำกัดจำนวนข้อมูลที่เข้ารหัสในสตรีมเดียว คุณสามารถแยก IV ออกเป็นส่วนสุ่มและส่วนคู่ (เช่น สุ่ม 64 บิต สร้างขึ้นหนึ่งครั้งต่อสตรีม) และส่วนนับ ( เริ่มต้นที่ 0) คุณสามารถแยกมันได้ตามที่คุณต้องการ คุณเพียงแค่ต้องกังวลเกี่ยวกับปัญหาวันเกิดสำหรับขนาดสุ่ม

หรือเพียงแค่ใช้คีย์ที่แตกต่างกันสำหรับแต่ละสตรีมและเริ่มนับที่ 0 ไม่ต้องกังวลว่าจะทับซ้อนกันในสถานการณ์นั้น

cn flag
ใช่ แต่ในกรณีนั้นด้วย IV สุ่ม 64 บิตนั้นค่อนข้างเล็ก ตามที่อธิบายไว้ที่นี่: https://crypto.stackexchange.com/questions/1849/why-should-i-avoid-using-a-randomized-iv-for-ctr-mode
cn flag
คุณคิดว่าโซลูชันที่ฉันเสนอ (ได้รับคีย์จากการสุ่ม IV) นั้นดีเท่ากับการใช้คีย์ที่แตกต่างกันสำหรับแต่ละสตรีมหรือไม่
Swashbuckler avatar
mc flag
@LightBit หากคุณพบปัญหาที่พวกเขากำลังพูดถึง แสดงว่าคุณมีปัญหาอื่นที่ใหญ่กว่าอยู่แล้ว มีการวิจัยที่ชี้ให้เห็นว่าโหมด CTR ค่อนข้างรั่ว และคุณควรเข้ารหัสข้อมูลด้วย ONE KEY มากที่สุดเท่าที่คุณทำในโหมด CBC ซึ่งสำหรับฉันคือประมาณ 64 GB (ขึ้นอยู่กับระยะเวลาที่คุณต้องการเก็บข้อมูล) นั่นเป็นวิธีที่ข้อมูลน้อยกว่าที่พวกเขากำลังพิจารณา
Swashbuckler avatar
mc flag
สำหรับการได้รับคีย์จากการสุ่ม IV ฉันจะไม่ IV ไม่ใช่ความลับ กุญแจต้องเป็นความลับ หากคุณใช้กระบวนการคงที่ในการรับคีย์จาก IV ผู้โจมตีสามารถทำซ้ำขั้นตอนนั้นและรับคีย์ได้
cn flag
ในการรับรหัสจาก IV ฉันจะเข้ารหัสด้วยรหัสหลัก รหัสที่ได้รับดังนั้นจะเป็นความลับ

โพสต์คำตอบ

คนส่วนใหญ่ไม่เข้าใจว่าการถามคำถามมากมายจะปลดล็อกการเรียนรู้และปรับปรุงความสัมพันธ์ระหว่างบุคคล ตัวอย่างเช่น ในการศึกษาของ Alison แม้ว่าผู้คนจะจำได้อย่างแม่นยำว่ามีคำถามกี่ข้อที่ถูกถามในการสนทนา แต่พวกเขาไม่เข้าใจความเชื่อมโยงระหว่างคำถามและความชอบ จากการศึกษาทั้ง 4 เรื่องที่ผู้เข้าร่วมมีส่วนร่วมในการสนทนาด้วยตนเองหรืออ่านบันทึกการสนทนาของผู้อื่น ผู้คนมักไม่ตระหนักว่าการถามคำถามจะมีอิทธิพลหรือมีอิทธิพลต่อระดับมิตรภาพระหว่างผู้สนทนา