การเข้ารหัสที่อิงจากการแฮชซ้ำจะไม่ปลอดภัยเพียงใด

ฉันแค่สงสัยว่าสิ่งก่อสร้างต่อไปนี้จะไม่ปลอดภัยได้อย่างไร ฉันสามารถบอกได้ว่าการโจมตีธรรมดานั้นเป็นไปได้ แต่ฉันไม่แน่ใจเกี่ยวกับสิ่งอื่น

ให้ผู้ใช้เลือกรหัสผ่านและแฮชรหัสผ่านจำนวนมากพอด้วยบางสิ่งที่มีความต้านทานพรีอิมเมจ เช่น SHA-256 XOR ข้อความธรรมดาที่มีแฮช แฮชแฮชอีกครั้ง XOR ผลลัพธ์ด้วยบล็อกถัดไปของข้อความธรรมดา...และต่อไปเรื่อยๆ จนจบ ศัตรูจะทำลายสิ่งนี้ได้อย่างไร

TL;DR; ไม่ปลอดภัยอย่าใช้มัน ใช้มาตรฐานและโหมดการทำงานที่เป็นที่รู้จัก

การก่อสร้างของคุณคือ $s_i = H^i(รหัสผ่าน)$ เช่น แฮชรหัสผ่าน $i$ ครั้งแล้วใช้ผลลัพธ์ $s_i$ สำหรับแต่ละขั้นตอนไปยัง x-หรือด้วยข้อความธรรมดาเพื่อมาถึงข้อความเข้ารหัส $c_i = p_i \oบวก s_i$

ศัตรูจะทำลายสิ่งนี้ได้อย่างไร

มีวิธีที่จะบรรลุเป้าหมายนี้

• การโจมตีที่เดาได้: หากมีคนได้รับบางส่วนของข้อความของคุณ เช่น อย่างน้อย 256 บิตของบล็อก SHA-256 แบบเต็ม ข้อความที่เหลือจะถูกถอดรหัสอย่างง่ายดาย ดังนั้น ไม่มีความลับล่วงหน้าที่นี่.

  หนึ่งควรดูที่สไลด์เหล่านี้เกี่ยวกับ Hash_DRGB ดูการออกแบบที่ดีกว่าในการต่อต้านการประนีประนอมของรัฐ เมื่อสร้าง Pseudo-Random Sequence ประนีประนอมของสถานะปัจจุบันต้องไม่รั่วไหลสถานะอื่น ความล้มเหลวหลักของการออกแบบที่เสนอคือสิ่งนี้

• แผนของคุณดูเหมือนจะเสี่ยงต่อ การโจมตีต้องห้าม ว่าเมื่อ $(IV,คีย์)$ การจับคู่โหมด CTR ซ้ำสามารถทำลายความลับของข้อความเข้ารหัสได้ คุณไม่ได้กำหนด IV ในรูปแบบของคุณ ดังนั้นคุณจะมีรหัสผ่านเดียวกัน และสตรีมที่สร้างโดยรหัสของคุณจะสร้างเอาต์พุตเดียวกันตลอดเวลา

  ทั้งสองคนต้องเปลี่ยนรหัสผ่านทุกครั้งที่มีการเข้ารหัสหรือต้องแนะนำแนวทางปฏิบัติมาตรฐาน IV เพื่อบรรเทา มิฉะนั้นหายนะ!

• ไม่สามารถตรวจสอบความปลอดภัยของรหัสผ่านได้ และเรามักจะใช้ฟังก์ชันการสืบทอดคีย์ที่ใช้รหัสผ่าน เช่น PBKDF2, Scrypt หรือ Argon2 เพื่อรับรหัสผ่านแบบสุ่ม สิ่งเหล่านี้อย่างน้อยให้จำนวนการวนซ้ำเพื่อลดการโจมตีด้วยการค้นหารหัสผ่าน พวกเขายังมีสายรัดหน่วยความจำและจำนวนเธรดเพื่อลดความสามารถในการโจมตีด้วยการค้นหารหัสผ่าน เนื่องจากรูปแบบของคุณมีความเสี่ยงต่อการโจมตีที่ต้องห้าม ผู้ใช้จะเลือกรหัสผ่านใหม่สำหรับการเข้ารหัสทุกครั้งได้ยากขึ้น

  เราใช้คีย์สุ่มซึ่งสร้างขึ้นภายในเครื่องเพื่อใช้หรือได้รับมาจากโปรโตคอลเช่น DHKE

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

  สำหรับการเข้ารหัสแบบโลคัล การปฏิบัติตามปกติคือ สร้าง FEK คีย์การเข้ารหัสไฟล์แบบสุ่มสำหรับทุกไฟล์ จากนั้นใช้รหัสผ่านของผู้ใช้เพื่อรับ Key Encryption Key (KEK) ที่มี PBKDF ที่ดีเช่น Argon2 ด้วย KEK เข้ารหัสและถอดรหัส FEK จากนั้นจึงเข้ารหัส/ถอดรหัสไฟล์ รายละเอียดเพิ่มเติมคือ ที่นี่.

• โครงการของคุณ ขาดการเข้าถึงแบบสุ่มดังนั้นจึงไม่มีประโยชน์สำหรับแอปพลิเคชันจำนวนมาก เช่น การเข้ารหัสดิสก์

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

  ให้โมเดล SHA-256 เป็นฟังก์ชันสุ่มแบบสม่ำเสมอ ดังนั้นความน่าจะเป็นขององค์ประกอบที่อยู่ในวงจรคือ

  $$\frac{1}{\sqrt{\hspace{.03 in}2\hspace{-0.05 in}\cdot \hspace{-0.04 in}\pi} \cdot 2^{127}}$$

  ความยาวรอบเฉลี่ยที่มีค่าคาดไว้สำหรับ SHA-256 คือ $$2^{127} \sqrt{2\pi}$$ ดังนั้นคุณจึงไม่ต้องกลัวรอบสั้น การอ้างอิงคือ แฮร์ริส 2503

• แบบแผนของคุณไม่มีการรักษาความปลอดภัย Ind-CPA

เรามีอะไรแทนสิ่งนี้?

• เรามีโหมด CTR ที่รู้จักกันดีซึ่งสามารถแปลง Pseudo-Random Function (PRF) เป็นรูปแบบการเข้ารหัสตั้งแต่ปี 1979 เป็นเอกสารสำคัญของ Whitfield Diffie และ Martin Hellman;

  • ความเป็นส่วนตัวและการรับรองความถูกต้อง: ความรู้เบื้องต้นเกี่ยวกับการเข้ารหัส เป็นบทความรับเชิญเรื่อง Proceedings of the IEEE, 67 (1979), pp. 397â427

นี่เป็นข้อได้เปรียบอย่างมากเนื่องจากทำให้สามารถใช้ฟังก์ชันต่างๆ มากมายแทนการใช้ PRP ได้เพียงอย่างเดียวโหมด CTR มี IV เพื่อสุ่มการเข้ารหัสและได้การเข้ารหัสที่น่าจะเป็น CTR สามารถบรรลุความปลอดภัย Ind-CPA

ปัจจุบัน การเข้ารหัสทั้งหมดในโหมด TLS ใช้โหมด CTR ภายใน, AES-GCM, AES-CCM และ ChaCha20-Poly1305

บทสรุป

ไม่มีข้อได้เปรียบเหนือโหมด CTR แม้ว่าคุณจะเพิ่ม IV ในรูปแบบการเข้ารหัสของคุณ และแม้แต่คุณแก้ปัญหารหัสผ่านและส่วนที่เป็นปัญหามากที่สุด: การโจมตีที่คาดเดาได้.

ก่อนที่จะพูดถึงการโจมตี ฉันขอแนะนำให้คุณใช้รหัสสุ่มที่มีบิตเพียงพอ (อย่างน้อย 128 บิต) แทนรหัสผ่าน คุณไม่จำเป็นต้องแฮชคีย์หลาย ๆ ครั้ง เพียงแค่ใช้คีย์ที่ดี หากมาจากรหัสผ่าน ให้ใช้ฟังก์ชันการหาค่าคีย์ที่ดีเพื่อรับรหัสและใช้รหัสนั้นแทน

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

อันที่จริง นานมาแล้วก่อนที่ฉันจะนึกถึงการเข้ารหัสที่คล้ายกัน แต่แทนที่จะแฮชทุกอย่างซ้ำๆ ฉันคิดที่จะทำ xor ของผลลัพธ์แฮชครึ่งซ้ายด้วยบล็อกข้อความธรรมดาและแฮชครึ่งขวาสำหรับบล็อกถัดไป สิ่งนี้สามารถสุ่มได้โดยการผสมหมายเลขสุ่มสาธารณะเข้ากับคีย์ อีกวิธีที่เป็นที่รู้จักมากขึ้นคือการใช้แฮชในโหมด CTR เพื่อสร้างสตรีมเหมือนกับที่เราทำกับรหัสบล็อก เนื่องจากโหมด CTR ไม่ต้องการให้คุณถอดรหัสบล็อกได้ ดังที่ kelalaka ชี้ให้เห็น มันให้การเข้าถึงแบบสุ่มเช่นกัน

แต่โปรดจำไว้ว่าสิ่งนี้ไม่สามารถแสดงว่าปลอดภัยในโมเดลธรรมดา ดังนั้นคุณจึงไม่แน่ใจเกี่ยวกับความปลอดภัยของมันด้วยฟังก์ชันแฮชเช่น SHA-2 ซึ่งไม่ได้ออกแบบมาเพื่อใช้งานในลักษณะนี้ สิ่งนี้จำเป็นต้องมีข้อสันนิษฐานเพิ่มเติมว่าฟังก์ชันแฮชของคุณใกล้เคียงกับคำพยากรณ์แบบสุ่มที่จะใช้ในลักษณะนี้อย่างปลอดภัย และแม้ว่าจะมีความปลอดภัยด้วยฟังก์ชันแฮชทั่วไป แต่ก็มีแนวโน้มที่จะไม่มีการใช้งานอย่างแพร่หลาย เพราะมันจะช้ากว่า AES หรือ Chacha20 ที่ใช้ฮาร์ดแวร์ช่วยมาก (ซึ่งใช้โหมด CTR ตามที่กล่าวไว้ข้างต้นด้วย)