ข้อใดที่พวกเขาต้องการในสถานการณ์ใด

ฉันต้องการดูรายการการประเมิน crtieria สำหรับโหมดต่าง ๆ และอาจเป็นการอภิปรายการบังคับใช้ของแต่ละเกณฑ์

ตัวอย่างเช่นฉันคิดว่าหนึ่งในเกณฑ์คือ "ขนาดของรหัส" สำหรับการเข้ารหัสและถอดรหัสซึ่งเป็นสิ่งสำคัญสำหรับระบบฝังตัวไมโครโค้ดเช่น 802.11 อะแดปเตอร์เครือข่าย หากรหัสที่ต้องใช้ในการปรับใช้ CBC นั้นเล็กกว่าที่ต้องการสำหรับ CTR (ฉันไม่รู้ว่านี่เป็นจริงมันเป็นเพียงตัวอย่าง) จากนั้นฉันสามารถเข้าใจได้ว่าทำไมถึงเลือกใช้โหมดที่มีรหัสขนาดเล็กกว่า แต่ถ้าฉันเขียนแอพที่ทำงานบนเซิร์ฟเวอร์และไลบรารี่ AES ที่ฉันใช้นั้นทำทั้ง CBC และ CTR อย่างไรก็ตามเงื่อนไขนี้ไม่เกี่ยวข้อง

ดูสิ่งที่ฉันหมายถึงโดย "รายการเกณฑ์การประเมินผลและการบังคับใช้ของแต่ละเกณฑ์"

นี่ไม่ได้เกี่ยวข้องกับการเขียนโปรแกรม แต่เกี่ยวข้องกับอัลกอริทึม

• ไม่ควรใช้ ECB หากเข้ารหัสข้อมูลมากกว่าหนึ่งบล็อกด้วยคีย์เดียวกัน

• CBC, OFB และ CFB มีความคล้ายคลึงกัน แต่ OFB / CFB นั้นดีกว่าเพราะคุณต้องการเพียงการเข้ารหัสและไม่ต้องถอดรหัสซึ่งสามารถประหยัดพื้นที่โค้ดได้

• CTR จะใช้หากคุณต้องการการขนานที่ดี (เช่นความเร็ว) แทนที่จะเป็น CBC / OFB / CFB

• โหมด XTS เป็นโหมดที่ใช้กันโดยทั่วไปหากคุณเข้ารหัสข้อมูลที่สามารถเข้าถึงได้แบบสุ่ม (เช่นฮาร์ดดิสก์หรือ RAM)

• OCB เป็นโหมดที่ดีที่สุดเนื่องจากช่วยให้สามารถเข้ารหัสและรับรองความถูกต้องได้ในครั้งเดียว อย่างไรก็ตามมีสิทธิบัตรในสหรัฐอเมริกา

สิ่งเดียวที่คุณต้องรู้ก็คือ ECB นั้นไม่ควรใช้เว้นแต่คุณจะเข้ารหัสเพียง 1 บล็อก ควรใช้ XTS หากคุณเข้ารหัสข้อมูลที่เข้าถึงแบบสุ่มไม่ใช่สตรีม

• คุณควรใช้ที่ไม่ซ้ำกันIV 's ทุกครั้งที่คุณเข้ารหัสและพวกเขาควรจะเป็นแบบสุ่ม หากคุณไม่สามารถรับประกันได้ว่าพวกเขาจะสุ่มใช้ OCB เพราะมันต้องการเพียงnonceไม่ใช่IVและมีความแตกต่างที่ชัดเจน nonceไม่ได้ลดลงการรักษาความปลอดภัยถ้าคนสามารถคาดเดาหนึ่งต่อไปเป็นIVสามารถทำให้เกิดปัญหานี้

โปรดพิจารณายาวและหนักถ้าคุณไม่สามารถนำการเข้ารหัสมาใช้

ความจริงที่น่าเกลียดของเรื่องนี้คือถ้าคุณถามคำถามนี้คุณอาจจะไม่สามารถออกแบบและใช้ระบบที่ปลอดภัยได้

ให้ฉันแสดงจุดของฉัน: ลองนึกภาพคุณกำลังสร้างโปรแกรมประยุกต์บนเว็บและคุณต้องเก็บข้อมูลเซสชั่นบางอย่าง คุณสามารถกำหนด ID เซสชันของผู้ใช้แต่ละคนและจัดเก็บข้อมูลเซสชันบนเซิร์ฟเวอร์ใน ID เซสชันการแมปแฮชแผนที่ให้กับข้อมูลเซสชัน แต่คุณต้องจัดการกับสถานะที่น่ารำคาญนี้บนเซิร์ฟเวอร์และหากในบางจุดคุณต้องการสิ่งที่มากกว่าหนึ่งเซิร์ฟเวอร์จะได้รับยุ่ง ดังนั้นคุณจึงมีแนวคิดที่จะเก็บข้อมูลเซสชันในคุกกี้ที่ฝั่งไคลเอ็นต์ คุณจะเข้ารหัสมันแน่นอนเพื่อให้ผู้ใช้ไม่สามารถอ่านและจัดการข้อมูล ดังนั้นคุณควรใช้โหมดใด มาที่นี่คุณอ่านคำตอบที่ดีที่สุด (ขอโทษที่ออกมา myforwik) อันแรกที่ครอบคลุม - ECB - ไม่เหมาะสำหรับคุณคุณต้องการเข้ารหัสมากกว่าหนึ่งบล็อกบล็อกถัดไป - CBC - ฟังดูดีและคุณไม่ต้องการขนานของ CTR คุณไม่จำเป็นต้องเข้าถึงแบบสุ่ม ดังนั้นจึงไม่มี XTS และสิทธิบัตรเป็น PITA ดังนั้นจึงไม่มี OCB การใช้ไลบรารี่ crypto ของคุณทำให้คุณรู้ว่าคุณต้องใช้ช่องว่างภายในเนื่องจากคุณสามารถเข้ารหัสได้หลายเท่าของขนาดบล็อก คุณเลือกPKCS7เนื่องจากถูกกำหนดในมาตรฐานการเข้ารหัสที่ร้ายแรงบางอย่าง หลังจากอ่านที่ไหนสักแห่งที่ CBC มีความปลอดภัยอย่างพิสูจน์ได้ถ้าใช้กับ IV แบบสุ่มและรหัสบล็อกที่ปลอดภัยคุณจะรู้สึกสบายใจแม้ว่าคุณจะเก็บข้อมูลสำคัญของคุณไว้ที่ฝั่งไคลเอ็นต์

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

นี่ไม่ใช่สถานการณ์สมมติ: Microsoft มีข้อบกพร่องนี้แน่นอนใน ASP.NET จนกระทั่งไม่กี่ปีที่ผ่านมา

ปัญหาคือมีข้อผิดพลาดมากมายเกี่ยวกับการเข้ารหัสและมันเป็นเรื่องง่ายมากที่จะสร้างระบบที่ดูปลอดภัยสำหรับคนธรรมดา แต่มีปัญหาเล็กน้อยที่จะทำลายผู้โจมตีที่มีความรู้

จะทำอย่างไรถ้าคุณต้องการเข้ารหัสข้อมูล

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

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

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

เปรียบเทียบโหมด

การเข้ารหัสเท่านั้น:

• โหมดที่ต้องใช้การขยาย : เช่นในตัวอย่างการแพ็ดดิงอาจเป็นอันตรายได้เพราะมันเปิดโอกาสในการโจมตีแบบแพ็ดดิ้ง oracle การป้องกันที่ง่ายที่สุดคือการตรวจสอบความถูกต้องทุกข้อความก่อนถอดรหัส ดูด้านล่าง
  • ECBเข้ารหัสแต่ละบล็อกของข้อมูลอย่างอิสระและบล็อก plaintext เดียวกันจะส่งผลให้บล็อก ciphertext เดียวกัน ดูภาพทักซ์ที่เข้ารหัส ECB บนหน้า Wikipedia ของ ECBเพื่อดูว่าทำไมนี่จึงเป็นปัญหาร้ายแรง ฉันไม่ทราบกรณีการใช้งานใด ๆ ที่ ECB จะยอมรับได้
  • CBCมี IV และต้องมีการสุ่มทุกครั้งที่มีการเข้ารหัสข้อความการเปลี่ยนแปลงส่วนหนึ่งของข้อความนั้นจำเป็นต้องเข้ารหัสใหม่ทุกอย่างหลังจากการเปลี่ยนแปลงข้อผิดพลาดในการส่งสัญญาณในบล็อก ciphertext บล็อกเดียวทำลายทำลายธรรมดาและเปลี่ยนการถอดรหัสของบล็อกถัดไป สามารถ parallelized / การเข้ารหัสไม่สามารถ plaintext คืออ่อนในระดับหนึ่ง - นี้อาจจะมีปัญหา
• โหมดการเข้ารหัสแบบสตรีม : โหมดเหล่านี้จะสร้างกระแสข้อมูลแบบหลอกเทียมที่อาจหรือไม่ขึ้นอยู่กับข้อความธรรมดา ในทำนองเดียวกันกับสตรีม ciphers โดยทั่วไปสตรีมแบบหลอกเทียมที่สร้างขึ้นคือ XORed พร้อมด้วยข้อความธรรมดาเพื่อสร้างไซเฟอร์เท็กซ์ ตามที่คุณสามารถใช้สตรีมแบบสุ่มได้มากเท่าที่คุณต้องการโดยไม่ต้องใช้ช่องว่างภายใน ข้อเสียของความเรียบง่ายนี้คือการเข้ารหัสมีความอ่อนอย่างสมบูรณ์ซึ่งหมายความว่าการถอดรหัสสามารถเปลี่ยนแปลงได้โดยผู้โจมตีในลักษณะใด ๆ ที่เขาชอบสำหรับธรรมดา p1, ciphertext c1 และหลอกกระแสสุ่มหลอก r และผู้โจมตีสามารถเลือกความแตกต่างเช่นการถอดรหัสของ ciphertext c2 = c1⊕d คือ p2 = p1⊕dในขณะที่ p2 = c2⊕r = (c1 ⊕ d) ⊕ r = d ⊕ (c1 ⊕ r) นอกจากนี้กระแสสุ่มหลอกเดียวกันจะต้องไม่ถูกใช้สองครั้งสำหรับ ciphertexts สอง c1 = p1⊕rและ c2 = p2⊕rผู้โจมตีสามารถคำนวณ xor ของ plaintexts ทั้งสองเป็นc1⊕c2 = p1⊕r⊕p2⊕r = p1⊕p2 นั่นหมายความว่าการเปลี่ยนข้อความนั้นต้องมีการเข้ารหัสใหม่ทั้งหมดหากผู้โจมตีได้รับข้อความต้นฉบับ โหมดเข้ารหัสตัวเลขต่อไปนี้ทั้งหมดต้องการการดำเนินการเข้ารหัสของรหัสบล็อกเท่านั้นดังนั้นขึ้นอยู่กับรหัสนี้อาจช่วยประหยัดพื้นที่ (ซิลิคอนหรือรหัสเครื่อง) บางส่วนในสภาพแวดล้อมที่ จำกัด อย่างยิ่ง
  • CTRนั้นง่ายมันสร้างสตรีมแบบหลอกเทียมที่ไม่ขึ้นอยู่กับ plaintext สตรีมแบบสุ่มหลอกต่าง ๆ จะได้มาจากการนับจาก nonces / IV ที่แตกต่างกันซึ่งคูณด้วยความยาวสูงสุดของข้อความเพื่อป้องกันการทับซ้อน เป็นไปได้โดยไม่มีการสุ่มข้อความ, การถอดรหัสและการเข้ารหัสเสร็จสมบูรณ์แบบขนาน, ข้อผิดพลาดในการส่งผลกระทบเฉพาะบิตผิดและไม่มีอะไรเพิ่มเติม
  • OFBยังสร้างกระแสสุ่มหลอกเป็นอิสระจาก plaintext, ลำธารสุ่มหลอกที่แตกต่างกันจะได้รับโดยเริ่มต้นด้วย nonce หรือสุ่ม IV ที่แตกต่างกันสำหรับทุกข้อความไม่เข้ารหัสหรือถอดรหัสเป็นแบบขนานเช่นเดียวกับ CTR โดยใช้การเข้ารหัสข้อความ nonces เป็นไปได้ การสุ่มเช่นเดียวกับข้อผิดพลาดในการส่ง CTR จะส่งผลต่อบิตที่ไม่ถูกต้องเท่านั้น
  • สตรีมแบบสุ่มหลอกของCFBขึ้นอยู่กับข้อความธรรมดาที่ต้องการ nonce หรือ Random IV ที่แตกต่างกันสำหรับทุกข้อความเช่นเดียวกับ CTR และ OFB โดยใช้การเข้ารหัสข้อความที่ไม่เป็นไปได้โดยไม่มีการสุ่มข้อความต่อการถอดรหัสเป็นแบบคู่ขนาน / การเข้ารหัสไม่สมบูรณ์ ทำลายบล็อกต่อไปนี้ แต่มีผลเฉพาะบิตที่ไม่ถูกต้องในบล็อกปัจจุบัน
• โหมดการเข้ารหัสดิสก์ :โหมดเหล่านี้มีความเชี่ยวชาญในการเข้ารหัสข้อมูลด้านล่างนามธรรมของระบบไฟล์ สำหรับเหตุผลด้านประสิทธิภาพการเปลี่ยนข้อมูลบางอย่างบนแผ่นดิสก์จะต้องใช้การเขียนบล็อกดิสก์อย่างน้อยหนึ่งบล็อก (512 ไบต์หรือ 4kib) พวกเขาอยู่นอกขอบเขตของคำตอบนี้เนื่องจากพวกเขามีสถานการณ์การใช้งานที่แตกต่างกันอย่างมากมายกว่าที่อื่น ๆ อย่าใช้พวกเขาสำหรับสิ่งใดนอกจากบล็อกการเข้ารหัสดิสก์ระดับ สมาชิกบางคน: XEX, XTS, LRW

การเข้ารหัสที่ผ่านการรับรองความถูกต้อง:

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

• CCMเป็นการผสมผสานระหว่างโหมด CTR และ CBC-MAC อย่างง่าย การใช้การเข้ารหัสตัวเลขบล็อกสองครั้งต่อบล็อกนั้นช้ามาก
• OCBนั้นเร็วกว่า แต่มีการจดสิทธิบัตรไว้ แม้ว่าผู้ถือสิทธิบัตรจะได้รับใบอนุญาตฟรี (เป็นอิสระ) หรือซอฟต์แวร์ที่ไม่ใช่ทางทหาร
• GCMเป็นการรวมกันอย่างรวดเร็ว แต่มีความซับซ้อนของโหมด CTR และ GHASH ซึ่งเป็น MAC เหนือฟิลด์ Galois ที่มีองค์ประกอบ 2 ^ 128 การใช้งานอย่างกว้างขวางในมาตรฐานเครือข่ายที่สำคัญเช่น TLS 1.2 นั้นสะท้อนให้เห็นจากคำสั่งพิเศษที่ Intel ได้แนะนำเพื่อเพิ่มความเร็วในการคำนวณ GHASH

คำแนะนำ:

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

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

โปรดทราบว่าสิ่งเหล่านี้ส่วนใหญ่ต้องการให้ IV เป็นแบบสุ่มซึ่งหมายถึงไม่สามารถคาดเดาได้ดังนั้นจึงควรสร้างด้วยความปลอดภัยแบบเข้ารหัส อย่างไรก็ตามบางคนต้องการเพียง "nonce" ซึ่งไม่ต้องการคุณสมบัตินั้น แต่ต้องการเพียงแค่ว่ามันไม่ได้ถูกนำมาใช้ใหม่ ดังนั้นการออกแบบที่พึ่งพา nonce จึงมีข้อผิดพลาดน้อยกว่าการออกแบบที่ไม่ได้ (และเชื่อฉันฉันได้เห็นหลายกรณีที่ CBC ไม่ได้ใช้งานกับการเลือก IV ที่เหมาะสม) ดังนั้นคุณจะเห็นว่าฉันได้เพิ่มตัวหนาเมื่อ Rogaway พูดบางอย่างเช่น "การรักษาความลับไม่สำเร็จเมื่อ IV เป็น nonce" หมายความว่าถ้าคุณเลือก IV ของคุณปลอดภัย cryptographically (คาดเดาไม่ได้) ก็ไม่มีปัญหา แต่ถ้าคุณทำไม่ได้คุณจะสูญเสียคุณสมบัติความปลอดภัยที่ดี ห้ามใช้ IV อีกครั้งสำหรับโหมดใด ๆ เหล่านี้

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

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

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

ฉันไม่ได้ตระหนักถึงปัญหา IP

ตอนนี้เป็นเรื่องดีจากศาสตราจารย์ Rogaway:

บล็อกโหมด ciphers การเข้ารหัส แต่ไม่ใช่ความสมบูรณ์ของข้อความ

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

CBC : รูปแบบการเข้ารหัส IV-based, โหมดมีความปลอดภัยเป็นรูปแบบการเข้ารหัสน่าจะเป็น, บรรลุความไม่สามารถแยกแยะได้จากบิตสุ่ม, สมมติว่า IV แบบสุ่ม การรักษาความลับนั้นไม่สามารถทำได้หาก IV เป็นเพียง nonceหรือถ้าไม่ใช่การเข้ารหัสภายใต้คีย์เดียวกันที่ใช้โดยโครงการตามที่มาตรฐานแนะนำอย่างไม่ถูกต้อง ไซเฟอร์เท็กซ์นั้นอ่อนมาก ไม่มีการรักษาความปลอดภัยการเข้ารหัส ciphertext (CCA) ที่เลือก การรักษาความลับถูกริบในที่ที่มีออราเคิลแบบแพ็ดดิ้งที่ถูกต้องสำหรับวิธีการแพ็ดดิ้งจำนวนมาก การเข้ารหัสที่ไม่มีประสิทธิภาพจากการเป็นอนุกรมโดยเนื้อแท้ มีการใช้กันอย่างแพร่หลายคุณสมบัติความปลอดภัยความเป็นส่วนตัวเพียงอย่างเดียวของโหมดส่งผลให้เกิดการใช้ผิดวิธีบ่อยครั้ง สามารถใช้เป็นแบบเอกสารสำเร็จรูปสำหรับอัลกอริทึม CBC-MAC ฉันไม่สามารถระบุข้อได้เปรียบที่สำคัญเหนือโหมด CTR

CFB : รูปแบบการเข้ารหัส IV-based โหมดมีความปลอดภัยเป็นรูปแบบการเข้ารหัสน่าจะเป็นบรรลุความไม่สามารถแยกแยะได้จากบิตสุ่มโดยสมมติว่า IV แบบสุ่ม การรักษาความลับนั้นไม่สามารถทำได้ถ้า IV นั้นสามารถทำนายได้และไม่ได้ทำโดยการเข้ารหัสแบบ nonce ภายใต้คีย์เดียวกันที่ใช้โดยโครงการตามที่มาตรฐานแนะนำอย่างไม่ถูกต้อง ไซเฟอร์เท็กซ์จะอ่อนตัว ไม่มีความปลอดภัย CCA การเข้ารหัสที่ไม่มีประสิทธิภาพจากการเป็นอนุกรมโดยเนื้อแท้ แบบแผนขึ้นอยู่กับพารามิเตอร์ s, 1 ≤ s ≤ n, โดยทั่วไปคือ s = 1 หรือ s = 8 ที่ไม่มีประสิทธิภาพสำหรับการเรียก blockcipher หนึ่งครั้งเพื่อประมวลผลบิต s เท่านั้น โหมดนี้ให้คุณสมบัติ "การซิงโครไนซ์ด้วยตนเอง" ที่น่าสนใจ การแทรกหรือลบอักขระ s-bit จำนวนเท่าใดก็ได้ลงใน ciphertext จะเป็นการขัดขวางการถอดรหัสที่ถูกต้องชั่วคราวเท่านั้น

OFB : รูปแบบการเข้ารหัส IV-based, โหมดมีความปลอดภัยเป็นรูปแบบการเข้ารหัสที่น่าจะเป็น, บรรลุความไม่สามารถแยกแยะได้จากบิตสุ่ม, สมมติว่า IV แบบสุ่ม การรักษาความลับนั้นไม่สามารถทำได้หาก IV เป็น nonce แม้ว่าลำดับของ IVs ที่คงที่ (เช่นตัวนับ) จะทำงานได้ดี ไซเฟอร์เท็กซ์นั้นอ่อนมาก ไม่มีความปลอดภัย CCA การเข้ารหัสและถอดรหัสไม่มีประสิทธิภาพจากการเป็นอนุกรมโดยเนื้อแท้ เข้ารหัสสตริงที่มีความยาวบิตใด ๆ (ไม่จำเป็นต้องมีการแพ็ด) ฉันไม่สามารถระบุข้อได้เปรียบที่สำคัญเหนือโหมด CTR

CTR : รูปแบบการเข้ารหัสที่อิง IV โหมดจะไม่สามารถแยกแยะความแตกต่างได้จากบิตสุ่มโดยสมมติว่าไม่ใช่ IV ในฐานะที่เป็นรูปแบบ nonce ที่ปลอดภัยโหมดนี้ยังสามารถใช้เป็นรูปแบบการเข้ารหัสที่น่าจะเป็นด้วย IV แบบสุ่ม ความล้มเหลวของความเป็นส่วนตัวโดยสมบูรณ์หากไม่มีการใช้ซ้ำในการเข้ารหัสหรือถอดรหัส ความขนานของโหมดมักจะทำให้เร็วขึ้นในการตั้งค่าบางอย่างเร็วกว่าโหมดการรักษาความลับอื่น ๆ Building Block ที่สำคัญสำหรับรูปแบบการเข้ารหัสที่รับรองความถูกต้อง โดยรวมแล้วเป็นวิธีที่ดีที่สุดและทันสมัยที่สุดในการเข้ารหัสลับข้อมูลส่วนบุคคลเท่านั้น

XTS : รูปแบบการเข้ารหัส IV-based, โหมดการทำงานโดยใช้ tweakable blockcipher (ปลอดภัยเป็น strong-PRP) กับแต่ละก้อน n-bit สำหรับข้อความที่มีความยาวไม่สามารถหารด้วย n บล็อกสองอันสุดท้ายจะได้รับการปฏิบัติเป็นพิเศษ การใช้โหมดที่ได้รับอนุญาตเท่านั้นคือการเข้ารหัสข้อมูลบนอุปกรณ์เก็บข้อมูลแบบบล็อก ความกว้างที่แคบของ PRP พื้นฐานและการจัดการบล็อกขั้นสุดท้ายที่เป็นเศษส่วนไม่ดีเป็นปัญหา มีประสิทธิภาพมากขึ้น แต่เป็นที่ต้องการน้อยกว่า blockcipher ที่มีความปลอดภัย PRP (wide-block)

MACs (ความสมบูรณ์ของข้อความ แต่ไม่เข้ารหัส)

ALG1–6 : คอลเล็กชันของ MAC ทั้งหมดล้วนมาจาก CBC-MAC แผนการมากเกินไป บางตัวมีความปลอดภัยที่พิสูจน์ได้ว่าเป็น VIL PRF บางตัวเป็น FIL PRFs และบางตัวไม่มีความปลอดภัยที่พิสูจน์ได้ แผนการบางอย่างยอมรับการโจมตีที่สร้างความเสียหาย บางโหมดเป็นวันที่ การแยกคีย์ได้รับการเข้าร่วมไม่เพียงพอสำหรับโหมดที่มี ไม่ควรนำมาใช้กับคนจำนวนมาก แต่การเลือกแผนการ "ดีที่สุด" เป็นไปได้ มันจะเป็นการดีถ้าจะไม่ยอมรับโหมดเหล่านี้ในความโปรดปรานของ CMAC เครื่อง MAC 9797-1 บางรุ่นได้รับการรับรองมาตรฐานและใช้กันอย่างแพร่หลายโดยเฉพาะในด้านการธนาคาร มาตรฐานฉบับปรับปรุง (ISO / IEC FDIS 9797-1: 2010) จะเปิดตัวเร็ว ๆ นี้ [93]

CMAC : MAC ที่ใช้ CBC-MAC โหมดนี้มีความปลอดภัย (ขึ้นอยู่กับวันเกิด) เป็น (VIL) PRF (สมมติว่า blockcipher นั้นเป็น PRP ที่ดี) ค่าใช้จ่ายที่น้อยที่สุดเป็นหลักสำหรับโครงการที่ใช้ CBCMAC ปัญหาที่เกิดขึ้นตามลำดับโดยธรรมชาตินั้นมีปัญหาในบางโดเมนของแอปพลิเคชัน สะอาดกว่าคอลเลคชั่น ISO 9797-1 ของ MAC

HMAC : MAC ที่ใช้ฟังก์ชั่นแฮชแบบเข้ารหัสลับมากกว่าบล็อคโค้ด (แม้ว่าฟังก์ชั่นแฮชแบบเข้ารหัสลับส่วนใหญ่จะมาจาก Blockciphers) กลไกสนุกกับขอบเขตความปลอดภัยที่พิสูจน์ได้ แต่ไม่ได้มาจากข้อสันนิษฐาน หลายตัวแปรที่เกี่ยวข้องอย่างใกล้ชิดในวรรณคดีซับซ้อนได้รับความเข้าใจในสิ่งที่เป็นที่รู้จัก ไม่เคยมีใครแนะนำการโจมตีที่สร้างความเสียหาย ได้รับมาตรฐานและใช้กันอย่างแพร่หลาย

GMAC : MAC ที่ไม่ได้ใช้งานแล้วซึ่งเป็นกรณีพิเศษของ GCM สืบทอดคุณลักษณะที่ดีและไม่ดีของ GCM มาหลายประการ แต่ความต้องการแบบไม่มีเงื่อนไขนั้นไม่จำเป็นสำหรับ MAC และนี่ก็เป็นการซื้อผลประโยชน์เพียงเล็กน้อย การโจมตีที่ใช้งานได้จริงหากแท็กถูกตัดเหลือเพียง≤ 64 บิตและขอบเขตของการถอดรหัสจะไม่ถูกตรวจสอบและตัดทอน ล้มเหลวโดยสมบูรณ์ในการใช้ซ้ำ การใช้งานจะมีความหมายอยู่แล้วหากมีการใช้ GCM ไม่แนะนำสำหรับการแยกมาตรฐาน

การเข้ารหัสที่รับรองความถูกต้อง (ทั้งการเข้ารหัสและความสมบูรณ์ของข้อความ)

CCM : แบบแผน AEAD ที่ไม่ขึ้นกับที่รวมการเข้ารหัสโหมด CTR และ raw CBC-MAC อนุกรมโดยเนื้อแท้ความเร็ว จำกัด ในบริบทบางอย่าง ปลอดภัยแน่นอนด้วยขอบเขตที่ดีสมมติว่า blockcipher พื้นฐานเป็น PRP ที่ดี การก่อสร้างที่ไม่เด่นชัดแสดงให้เห็นถึงการทำงาน ใช้งานง่ายกว่า GCM สามารถใช้เป็น MAC ที่ไม่ใช่ฐานได้ ได้รับมาตรฐานและใช้กันอย่างแพร่หลาย

GCM : แบบแผน AEAD ที่ไม่ขึ้นกับที่รวมการเข้ารหัสโหมด CTR และฟังก์ชันแฮชเอนกประสงค์สากลที่ใช้ GF (2128) คุณสมบัติประสิทธิภาพที่ดีสำหรับสภาพแวดล้อมการใช้งานบางอย่าง ผลลัพธ์ที่ปลอดภัยพิสูจน์ได้ดีโดยสมมติว่ามีการตัดแท็กน้อยที่สุด การโจมตีและขอบเขตการรักษาความปลอดภัยที่พิสูจน์ได้ไม่ดีในกรณีที่มีการตัดทอนแท็กจำนวนมาก สามารถใช้เป็น MAC ที่ไม่ใช่ฐานซึ่งเรียกว่า GMAC ตัวเลือกที่น่าสงสัยในการอนุญาต nonces นอกเหนือจาก 96 บิต แนะนำให้ จำกัด nonces ให้ 96- บิตและแท็กเป็นอย่างน้อย 96 บิต ได้รับมาตรฐานและใช้กันอย่างแพร่หลาย

1. อะไรก็ได้นอกจาก ECB
2. หากใช้ CTR จำเป็นที่คุณจะต้องใช้ IV ที่แตกต่างกันสำหรับแต่ละข้อความไม่เช่นนั้นคุณจะต้องจบลงด้วยการที่ผู้โจมตีสามารถใช้ไซเฟอร์เท็กซ์สองอันและได้รับข้อความธรรมดาที่ไม่เข้ารหัส เหตุผลก็คือโหมด CTR จะเปลี่ยนบล็อคตัวเลขเป็นกระแสข้อมูลหลักและกฎข้อแรกของการเข้ารหัสสตรีมคือไม่เคยใช้ Key + IV เดียวกันสองครั้ง
3. จริงๆแล้วมันไม่ได้มีความแตกต่างกันมากนักในการใช้โหมดต่างๆ บางโหมดจำเป็นต้องใช้รหัสบล็อกเพื่อทำงานในทิศทางการเข้ารหัส อย่างไรก็ตามรหัสลับส่วนใหญ่รวมถึง AES ไม่ต้องใช้รหัสมากขึ้นในการใช้การถอดรหัส
4. สำหรับโหมดตัวเลขทั้งหมดคุณจำเป็นต้องใช้ IV ที่แตกต่างกันสำหรับแต่ละข้อความหากข้อความของคุณอาจเหมือนกันในหลายไบต์แรกและคุณไม่ต้องการให้ผู้โจมตีรู้สิ่งนี้

คุณเริ่มต้นด้วยการอ่านข้อมูลเกี่ยวกับเรื่องนี้ใน Wikipedia - บล็อกโหมดการทำงานของตัวเลขหรือไม่ จากนั้นทำตามลิงค์อ้างอิงบนวิกิพีเดียNIST: คำแนะนำหา Block Cipher โหมดการทำงาน

คุณอาจต้องการเลือกตามสิ่งที่มีอยู่อย่างกว้างขวาง ฉันมีคำถามเดียวกันและนี่คือผลลัพธ์ของการวิจัยที่ จำกัด ของฉัน

ข้อ จำกัด ของฮาร์ดแวร์

STM32L (low energy ARM cores) from ST Micro support ECB, CBC,CTR GCM
CC2541 (Bluetooth Low Energy) from TI supports ECB, CBC, CFB, OFB, CTR, and CBC-MAC

ข้อ จำกัด ของโอเพ่นซอร์ส

Original rijndael-api source  - ECB, CBC, CFB1
OpenSSL - command line CBC, CFB, CFB1, CFB8, ECB, OFB
OpenSSL - C/C++ API    CBC, CFB, CFB1, CFB8, ECB, OFB and CTR
EFAES lib [1] - ECB, CBC, PCBC, OFB, CFB, CRT ([sic] CTR mispelled)  
OpenAES [2] - ECB, CBC 

[1] http://www.codeproject.com/Articles/57478/A-Fast-and-Easy-to-Use-AES-Library

[2] https://openaes.googlecode.com/files/OpenAES-0.8.0.zip

ฉันรู้แง่มุมหนึ่ง: ถึงแม้ว่า CBC จะให้ความปลอดภัยที่ดีขึ้นด้วยการเปลี่ยน IV สำหรับแต่ละบล็อก แต่ก็ไม่สามารถใช้ได้กับเนื้อหาที่เข้ารหัสที่เข้าถึงแบบสุ่ม (เช่นฮาร์ดดิสก์ที่เข้ารหัส)

ดังนั้นใช้ CBC (และโหมดลำดับอื่น ๆ ) สำหรับสตรีมลำดับและ ECB สำหรับการเข้าถึงแบบสุ่ม