Score:1

ความปลอดภัยของ AES-256/CBC/PKCS#7 + การสุ่มและการใช้ซ้ำของ IV

ธง es

ในการเริ่มต้น ฉันไม่ใช่ผู้เชี่ยวชาญหรืออะไรก็ตามที่ใกล้เคียงในการเข้ารหัส ฉันรู้พื้นฐานเกี่ยวกับเรื่องนี้มากพอที่จะเลือกวิธีที่จะนำไปใช้ไม่มากก็น้อย จากนั้นอ่านเกี่ยวกับเรื่องนี้เพื่อให้ฉันรู้ว่าฉันกำลังดำเนินการอะไรอยู่ ดังนั้นโปรดยกโทษให้กับคำถามโง่ๆ ฮ่าๆ

ฉันได้สร้างคลาสการเข้ารหัส/ถอดรหัส AES-256/CBC/PKCS#7 + HMAC-SHA512 ในแอปผู้ช่วย Android ที่ฉันกำลังสร้าง (ควรมี ในท้องถิ่น (มาก?) เรื่องส่วนตัวและฉันอาจเผยแพร่บน Play Store ดังนั้นไม่ใช่เฉพาะฉันเท่านั้น) ชุดค่าผสมนั้นควรจะมีความปลอดภัยสูงสำหรับ (?) ปีถัดไป อาจจะช้าลงเล็กน้อย แต่ฉันก็ไม่ว่าอะไร อย่างน้อยก็ในตอนนี้ (ข้อมูลน้อยมาก) แม้ว่าฉันยังอ่านเจอว่ามีปัญหาอย่างหนึ่งเกี่ยวกับสิ่งนี้ ซึ่งก็คือเมื่อเวกเตอร์เริ่มต้นถูกนำมาใช้ซ้ำ ด้วย CBC ดูเหมือนว่าจะไม่สามารถกู้คืนข้อมูลกลับมาได้ (ใช่ไหม) เช่นเดียวกับโหมดอื่นๆ ที่เป็นไปได้ และนั่นคือเหตุผลที่ฉันเลือกโหมดนี้ [หากมีปัญหาอื่นใดเกี่ยวกับวิธีนี้ เรายินดีแจ้งให้ทราบ]

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

ดังนั้นฉันจึงมีความคิด ซึ่งก็คือ: ข้อมูลทั้งหมดที่ฉันเข้ารหัสต้องเข้ารหัสโดยใช้ UTF-7 ค่าไบต์ที่เหลือ (128-255) ถูกใช้เป็นค่าสุ่มที่จะใส่หนึ่งค่าในแต่ละ 16 ไบต์ในตำแหน่งสุ่ม ตัวอย่างเช่น ในดัชนี 4 เพิ่ม 154 ไบต์ และในดัชนี 19 เพิ่ม 234 ไบต์ ด้วยวิธีนี้ มันจะสุ่มเสมอ และบล็อกที่เท่ากันในข้อมูลที่เท่ากันจะแตกต่างกันหากใช้ IV เดียวกันซ้ำ ("การสุ่ม" สามารถทำซ้ำค่าได้ และฉันไม่สามารถตรวจสอบได้ว่าฉันได้ใช้มันไปแล้วในกรณีนี้หรือไม่ ดังนั้นฉันจึงคิดว่า เพื่อป้องกันปัญหา)

นี่เป็นแนวทางที่ดีหรือไม่? มันอาจจะบรรเทาปัญหา? อาจจะแก้ปัญหาได้อย่างสมบูรณ์ในอีกไม่กี่ปีข้างหน้าและวิธีการนี้จะปลอดภัยอย่างสมบูรณ์หรืออย่างน้อยก็ปลอดภัยกว่ามาก?

นอกจากนี้ หากสิ่งใดที่ฉันพูดผิด ฉันยินดีที่จะแก้ไข! ขอบคุณ!

Score:1
ธง in

เหตุผลเดียวที่คุณควรกลัวการใช้ IV ซ้ำคือหากตัวสร้างตัวเลขสุ่มปิดอยู่

สมมติว่า IV แบบสุ่มทั้งหมดคุณสามารถเข้ารหัสได้ $2^{64}$ บล็อก ภายใน AES-CBC และยังมีเพียงหนึ่งใน $~2^{64}$ มีโอกาสเกิดการชนกัน (โดยประมาณ) โปรดทราบว่าปัญหาการป้อนซ้ำไม่ได้จำกัดตัวเองไว้ที่ IV; แต่ละไซเฟอร์เท็กซ์จะถูกใช้เป็น "เวกเตอร์" สำหรับ AES-block-encrypt ถัดไป

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

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


หากคุณต้องการปกป้องข้อมูลของคุณ คุณควรได้รับหรือห่อหุ้มคีย์เฉพาะของข้อความจาก "มาสเตอร์คีย์" ของคุณจะดีกว่า

หากแหล่งที่มาของการสุ่มของคุณไม่ปลอดภัยในการเข้ารหัส คุณอาจประสบปัญหาอยู่ดี คุณสามารถดูโหมด AES-SIV เพื่อลดปัญหาได้บ้าง ในโหมดนั้น IV ขึ้นอยู่กับข้อความธรรมดา

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


บันทึกความปลอดภัย:

  • เพื่อป้องกันการเปลี่ยนแปลงในอนาคต ฉันขอแนะนำให้รวม IV ไว้ในการคำนวณ MAC ด้วย การใช้ MAC บน IV จะเพิ่มเพียง 16 ไบต์ในการคำนวณ ซึ่งค่อนข้างไม่มีนัยสำคัญปัจจุบัน IV ของคุณไม่สามารถเปลี่ยนแปลงได้โดยผู้โจมตี แต่การเปลี่ยนแปลงโปรโตคอลอาจทำให้ IV และข้อความของคุณ เสี่ยงต่อการเปลี่ยนแปลง.
  • ฉันขอเตือนคุณด้วยว่าหากข้อมูลเป็นของ MAC แสดงว่าคุณเสี่ยงต่อการถูกโจมตีด้วยการแทนที่: แทนที่ข้อมูลของไฟล์หนึ่งด้วยอีกไฟล์หนึ่ง คุณต้องมีบางสิ่งที่ตรวจสอบได้ / ไม่ซ้ำใครในส่วนหัว / ข้อมูลเมตาและ MAC ร่วมกับข้อความเข้ารหัสของคุณ (เรามีแบบแผน AEAD เพื่อช่วยในเรื่องนั้น)
DADi590 avatar
es flag
ความคิดของฉันคือเมื่อฉันใช้ตัวสร้างการสุ่มที่ปลอดภัย (SecureRandom ใน Java) สำหรับ IV แล้ว ฉันสามารถใช้มันอีกครั้งเพื่อสุ่มข้อมูล เนื่องจากค่าสุ่มอาจซ้ำรอย ฉันจึงคิดเรื่องนี้ จากนั้นสิ่งที่คุณพูดว่า "แต่ละไซเฟอร์เท็กซ์จะถูกใช้เป็น 'เวกเตอร์' สำหรับ AES-block-encrypt ถัดไปหลังจากทั้งหมด" ก็สามารถลดลงได้เนื่องจากโดยทั่วไปแล้วมันเป็นแบบสุ่มในแต่ละบล็อกของข้อความซึ่งมีขนาด 16 ไบต์ (ในของฉัน หัวหน้าไม่เชี่ยวชาญเลย ฮ่าๆ) แต่ฉันไม่คิดว่าการชนจะเกิดขึ้นบ่อยแค่ไหน....เพียงแต่ว่า "มันจะเกิดขึ้น ฉันจะทำให้หนักขึ้น"
DADi590 avatar
es flag
แต่ถ้ามีโอกาสน้อยมากที่จะเกิดการชนกัน และไอเดียของฉันจะไม่ทำงานมากขนาดนั้น ฉันจะลบออกและกลับไปใช้การเข้ารหัส UTF-8 ตามปกติ นอกจากนี้ เกี่ยวกับ AES-SIV ฉันไม่สามารถพูดต่อไปได้ไม่ได้ใช้งานใน Android (Cipher บน Android Developers - ด้านบนสรุปในกรณีที่คุณสนใจ) ส่วนการห่อหุ้ม ถ้าฉันเข้าใจถูกต้องจากวิกิพีเดีย มันไม่ใช่กรณีของฉัน ฉันไม่เก็บคีย์ไว้ที่ใด (อย่างน้อยก็ในตอนนี้ - ไม่มีเซิร์ฟเวอร์ เป็นเพียงโครงการเล็กๆ) ได้มาจากรหัสผ่านที่ต้องใส่เอง - นั่นคือสิ่งที่ต้องปลอดภัยเพียงพอ (ดีกว่าเก็บคีย์ไว้ในเครื่อง)
Maarten Bodewes avatar
in flag
เรียกใช้ Argon2 หรือ - หากคุณต้องการใช้อันที่นำไปใช้แล้ว - PBKDF2ระวังว่าคุณยอมรับ ASCII ก็ต่อเมื่อคุณยังคงสามารถทำงานร่วมกับ Java SE ได้ และคุณใช้แฮชที่มีขนาดเอาต์พุตที่ใหญ่เพียงพอ (อย่าแยกขนาดเอาต์พุตแฮชออกจากฟังก์ชันมากกว่าขนาดเอาต์พุตแฮช) เกลือสุ่ม 16 ไบต์ที่ปลอดภัยและจำนวนการวนซ้ำที่สูงที่สุดเท่าที่จะเป็นไปได้ และคุณก็พร้อมแล้ว (คุณอาจต้องการรวมหมายเลขเวอร์ชันในโปรโตคอลของคุณในกรณีที่คุณต้องการอัปเกรดหรือจำนวนการวนซ้ำ) โดยทั่วไปแล้ว `new SecureRandom()` นั้นใช้ได้ และควรให้ PRNG ที่ดีแก่คุณ
DADi590 avatar
es flag
เกี่ยวกับบันทึกความปลอดภัย ฉันได้รวม IV ในการคำนวณ MAC แล้ว (ฉันคำนวณ MAC ด้วยข้อความตัวเลข, IV และคีย์ MAC) ฉันใช้ AEAD กับสิ่งนี้ด้วย ฉันอ่านตามที่คุณพูดทุกประการ ว่ามันเป็นไปได้ที่จะสลับไฟล์ที่เข้ารหัส 2 ไฟล์ และไฟล์เหล่านั้นจะถูกอ่านอยู่ดี แม้ว่าฉันจะรวมส่วนหัวบางส่วนไว้ในไฟล์ แต่ก็อาจจะใช้งานไม่ได้ แต่ไม่ว่าในกรณีใด ฉันจะใช้ AAD เพื่อช่วยป้องกันสิ่งนี้ ขอบคุณสำหรับข้อมูลทั้งหมด! ฉันจะทำเครื่องหมายเป็นคำตอบ!

โพสต์คำตอบ

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