Score:1

เป็นไปได้ไหมที่จะหลีกเลี่ยงข้อความธรรมดา IV ใน AES

ธง ke

สถานการณ์

ใช้ AES 256 กับโหมด CBC (การตรวจสอบสิทธิ์ทำแยกกัน ละเว้นที่นี่)

เป้าหมาย (อธิบายเพิ่มเติมในภายหลัง)

เพื่อหลีกเลี่ยงการส่ง IV ที่ไม่ได้เข้ารหัส

แต่เนื่องจากการดำเนินการนี้ดำเนินการโดยใช้ .NET ซึ่งฟังก์ชันบังคับให้เราใช้ IV เราจึงไม่สามารถเพิ่ม 16 ไบต์แบบสุ่มขึ้นมาก่อนแล้วทิ้ง 16 ไบต์แรกหลังการถอดรหัส

แผนการ

เติม 16 ไบต์แบบสุ่ม ("IV1") และนอกจากนั้นให้ใช้ 16 ไบต์โดยมีค่าเป็นศูนย์เป็น IV ("IV0") จากนั้นส่งข้อความไซเฟอร์เท็กซ์โดยไม่มี 16 ไบต์แรก

การถอดรหัสจะทำโดยผู้รับก่อนกำหนดว่าบล็อกแรกของอะไร ไซเฟอร์เท็กซ์ จะเป็น (สำหรับคีย์ AES นั้น สำหรับข้อความใดๆ) โดยการเข้ารหัสบางอย่างในลักษณะดังกล่าวข้างต้น (ซึ่งจะต้องทำเพียงครั้งเดียวต่อคีย์) และรับ 16 ไบต์แรกของข้อความไซเฟอร์ที่เป็นผลลัพธ์

จากนั้นพวกเขาเติมไบต์เหล่านั้นต่อท้ายข้อความที่ครอบตัดเพื่อรับข้อความเข้ารหัสดั้งเดิมที่ไม่ได้ครอบตัดแล้วถอดรหัสด้วย IV ("IV0") จำนวน 16 ไบต์ที่มีค่าเป็นศูนย์ (เช่น พวกเขาใช้ฟังก์ชันการถอดรหัสของ .NET โดยป้อน IV ที่จำเป็นซึ่งก็คือศูนย์ 16 ตัวเหล่านั้น)

จากนั้นพวกเขาจะละทิ้ง 16 ไบต์แรกของผลลัพธ์ (ซึ่งได้รับจาก .NET หลังจาก .NET ละทิ้ง 16 ไบต์แรกซึ่งเป็น IV) เนื่องจากเป็น 16 ไบต์สุ่มที่เพิ่มเข้ามา ("IV1").

แต่ทำไม?

การสื่อสาร IV ในรูปแบบข้อความล้วนทำให้ผู้โจมตีที่ดุร้ายมีข้อได้เปรียบ - พวกเขาสามารถถอดรหัสได้เพียงบล็อกเดียว (16 ไบต์) และเปรียบเทียบกับ IV เพื่อตรวจสอบว่าคีย์นั้นถูกต้องหรือไม่ (บางทีอาจมีช่องทางการโจมตีมากกว่านี้ซึ่งฉันไม่รู้)

ดังนั้นคำถามของฉันคือ

แผนนี้ดูเหมือนจะดีหรือมีข้อผิดพลาดอยู่บ้าง?

Marc Ilunga avatar
tr flag
คำถามที่เป็นอยู่ดูเหมือนจะยากที่จะตอบอย่างถูกต้อง บางทีการปรับปรุงอาจเป็นการเพิ่มความจริงที่ว่าคีย์ไม่ได้สุ่ม แต่ได้มาจากพื้นที่เอนโทรปีต่ำตามที่คุณกล่าวถึงในความคิดเห็นของคุณในคำตอบแรกคืออะไร
Maarten Bodewes avatar
in flag
โดยปกติแล้ว IV **คือ** นำหน้าข้อความอย่างไรก็ตาม IV ไม่ได้ทำให้ผู้โจมตีได้เปรียบไปกว่าบล็อกไซเฟอร์เท็กซ์อื่นๆ เนื่องจากมันทำหน้าที่เป็นเวกเตอร์สำหรับบล็อกถัดไป สิ่งนี้ถ่ายทอดโดย [คำตอบของ Fractalice](https://crypto.stackexchange.com/a/96314/1172) สำหรับการเข้ารหัสใด ๆ เราถือว่าผู้โจมตีสามารถรู้ (บางส่วน) ของข้อความธรรมดาได้ ด้วยเหตุนี้ การซ่อน IV จึงไม่ได้สร้างความแตกต่างใดๆ แต่จะถือว่าเปิดเผยต่อสาธารณะ
ke flag
@MaartenBodewes `โดยปกติแล้ว IV จะนำหน้าข้อความ ` - คำสำคัญที่นี่คือ "ปกติ" หากเป็นกรณีนี้ใน CBC และไม่มีการทำ IV อีกต่อไป - ประเด็นของฉันในคำถามจะเป็นจริง เช่น. การสื่อสาร IV ในรูปแบบข้อความธรรมดาจะทำให้ผู้โจมตีได้เปรียบในการบังคับคีย์อย่างดุร้าย เนื่องจาก IV เป็น XORd ที่มีข้อความธรรมดาก่อนการเข้ารหัส - นั่นไม่ใช่กรณี ตามที่ความคิดเห็นของ Fractalice บอกเป็นนัย
Maarten Bodewes avatar
in flag
คุณยังคงเข้าใจผิด IV ถูกส่ง **และ** เป็น XOR'ed ด้วยข้อความธรรมดาก่อนการเข้ารหัส ดังนั้นจึงถือว่าใช้ได้สำหรับฝ่ายตรงข้าม การเข้ารหัสสมัยใหม่ทั้งหมดควรให้การป้องกันแม้กระทั่งการโจมตีแบบข้อความธรรมดาที่เลือกไว้ สิ่งนี้เรียกว่า IND-CPA: ความสามารถในการแยกแยะไม่ได้ภายใต้การโจมตีแบบข้อความธรรมดาที่เลือก และส่วนใหญ่มีให้โดยโหมดการทำงานส่วนใหญ่หรือไม่ใช่ทุกโหมด ยกเว้น ECB จะไม่มี *edge* ที่จะได้รับหากรหัสนั้นปลอดภัย IND-CPA และการบังคับดุร้ายสำหรับ AES นั้นขึ้นอยู่กับขนาดคีย์ทั้งหมด ซึ่งสำหรับ AES-256 นั้นมีการป้องกันที่เพียงพออย่างแน่นอน
ke flag
@MaartenBodewes ขอบคุณสำหรับคำชี้แจง อย่างไรก็ตาม ฉันคิดว่าฉันควรอธิบายเพิ่มเติมในสิ่งที่ฉันคิดในตอนแรก (ซึ่งตอนนี้ฉันรู้แล้วว่าผิด) ฉันคิดว่า IV ทำงานแบบนี้ (ใน CBC): a) เพิ่ม IV ต่อท้ายข้อความธรรมดา b) เข้ารหัสโดยไม่ต้อง XORing บล็อกแรกด้วยอะไร หากเป็นกรณีนี้จริงๆ ก็ไม่จำเป็นต้องส่ง IV เพียงเพื่อสุ่ม และผู้รับก็จะถอดรหัสและโยนบล็อกแรกทิ้งไป ขอบคุณอีกครั้ง.
Maarten Bodewes avatar
in flag
การใช้งาน IV ตามปกติไม่มีความแตกต่างกันมากนัก ข้อแตกต่างเพียงอย่างเดียวคือ IV จริงในขณะนี้คือ *เข้ารหัส* IV บางครั้งใช้จริงเพื่อสุ่มค่าตัวนับ ดังนั้นค่า IV จึงไม่สามารถคาดเดาได้สำหรับศัตรู การรู้ IV หรือไม่นั้นไม่สำคัญ แต่สำหรับ CBC จำเป็นต้องมี IV แบบสุ่มที่คาดเดาไม่ได้ (หลอก) *โดยเฉพาะอย่างยิ่ง* IV จะถูกเข้ารหัสด้วยคีย์อื่นโปรดทราบว่าข้อความธรรมดาอาจเป็นเลขศูนย์ทั้งหมดได้ และเนื่องจากผู้โจมตีทราบบล็อกที่เข้ารหัสล่วงหน้า (ซึ่งเป็นแบบสาธารณะแต่คาดเดาไม่ได้) การรั่วไหลของ IV จะยังคงไม่สร้างความแตกต่าง
Score:4
ธง in

ฉันไม่เข้าใจแผนทั้งหมด แต่:

ใน CBC แต่ละบล็อกไซเฟอร์เท็กซ์จะมีบทบาทเป็น IV สำหรับบล็อกถัดไป ดังนั้นผู้โจมตีที่ดุร้ายสามารถโจมตีบล็อกถัดไปได้ เนื่องจากบล็อกข้อความรหัสจะถูกส่งอย่างชัดเจน

คุณกลัวจริงๆ ไหมว่าจะมีใครบังคับให้ใช้คีย์ 256 บิต มันเป็นไปไม่ได้.

นอกจากนี้ โปรดพิจารณาใช้การเข้ารหัสที่รับรองความถูกต้องเพื่อหยุดผู้โจมตีที่ใช้งานอยู่

ke flag
`ผู้โจมตีที่ดุร้ายสามารถโจมตีบล็อกถัดไปได้' - พวกเขาทดสอบคีย์และรับผลลัพธ์ พวกเขารู้ได้อย่างไรว่าถูกต้อง AFAIK AES จะเปลี่ยน 16 ไบต์เป็น 16 ไบต์ เสมอ. ไม่เคยล้มเหลว (ยกเว้นอันสุดท้ายเนื่องจากการเติม) ฉันผิดเหรอ?
ke flag
`คุณกลัวจริงๆ เหรอว่าจะมีใครบังคับรหัส 256 บิต ` - ไม่ใช่รหัสสุ่ม คีย์ที่ใช้รหัสผ่านที่จำง่ายซึ่งผู้ใช้ที่ไม่คำนึงถึงความปลอดภัยจะเลือก (เช่น "รหัสผ่าน 1" เป็นต้น)
ke flag
`โปรดพิจารณาใช้การเข้ารหัสที่รับรองความถูกต้อง' - ดังที่ฉันได้กล่าวไว้ในคำถามของฉัน: 'การตรวจสอบสิทธิ์จะทำแยกกัน ละเว้นที่นี่ `.
Fractalice avatar
in flag
หากผู้โจมตีไม่รู้อะไรเลยเกี่ยวกับข้อความธรรมดา คุณจะทดสอบบล็อกแรกด้วยข้อความธรรมดา IV ได้อย่างไร โปรดทราบว่าบล็อก ciphertext แรกที่ถอดรหัสคือข้อความ IV xor ดังนั้นผู้โจมตีจะได้รับตัวเลือกข้อความในการคาดเดาแต่ละคีย์ และอย่างที่คุณสังเกต - บล็อกสุดท้ายมักจะรู้จักข้อความธรรมดา - ช่องว่างภายในซึ่งอนุญาตให้ใช้กำลังดุร้ายในตอนท้าย
ke flag
ขอบคุณ. ฉันถูกชักนำให้เข้าใจผิดโดยบทเรียนที่บอกว่า IV เป็นเพียงส่วนเสริมของข้อความธรรมดา หากเป็นอย่างนั้น ความกังวลของข้าพเจ้าก็จะเกิดขึ้น ตามที่เป็นอยู่ IV คือ XORd ที่มีบล็อกแรกแทน (ใน CBC) ซึ่งช่วยแก้ปัญหานั้นได้ ขอบคุณอีกครั้ง.
Fractalice avatar
in flag
@ispiro IV ถูกส่งอย่างชัดเจนซึ่งเป็น "IV" สำหรับบล็อกแรก "IV" สำหรับบล็อกที่สองคือบล็อกไซเฟอร์เท็กซ์ชุดแรก ซึ่งจะถูกส่งไปอย่างชัดเจนเช่นกันCBC ได้รับการออกแบบมาเช่นนั้น และไม่มีปัญหากับสิ่งนั้น มันต้องคาดเดาไม่ได้

โพสต์คำตอบ

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