TLS 1.3 - เหตุใดจึงไม่มีการระบุโหมดเข้ารหัสแล้วเป็น MAC

ฉันได้เกาหัวของฉันในขณะที่ทำไม TLS 1.3 ไม่รวมโหมดเข้ารหัสแล้ว MAC (EtM) ปัญหาก่อนหน้านี้ทั้งหมดใน TLS เกิดจาก MAC แล้วเข้ารหัส ในขณะที่เข้ารหัสแล้ว MAC จะหลีกเลี่ยงปัญหาทั้งหมดที่เกิดจากการเติมข้อมูลในอดีต เนื่องจากผู้รับสามารถตรวจสอบความสมบูรณ์ของข้อความได้โดยไม่ต้องถอดรหัสข้อความก่อน แล้วจึงจัดการการเติมข้อมูลผิดพลาดอย่างถูกต้อง

สิ่งที่น่ารำคาญสำหรับฉันคือมีไมโครคอนโทรลเลอร์ไม่กี่ตัวที่มีการเร่งฮาร์ดแวร์ AES ในตัว อย่างไรก็ตาม บางอย่างเช่นการคูณแบบไม่ต้องพกพาสำหรับ GCM มีอยู่จริงบนเซิร์ฟเวอร์และซีพียูเดสก์ท็อปเท่านั้น

ในขณะที่มี ChaCha20-Poly1305 ใช้แทน หมายความว่าคุณละทิ้งการใช้ฮาร์ดแวร์ AES บนไมโครคอนโทรลเลอร์ แม้ว่า ChaCha20 จะทำงานได้ดีกับไมโคร 32 บิต แต่ก็ยังคงใช้พลังงานมากกว่าฮาร์ดแวร์ AES ในตัว และน่าจะช้ากว่านั้นขึ้นอยู่กับไมโคร นอกจากนี้ Poly1305 ยังต้องการการคำนวณทางคณิตศาสตร์แบบโมดูลาร์ตัวเลขขนาดใหญ่เมื่อเทียบกับฟังก์ชันแฮชจำนวนมาก

ฉันแค่เกาหัวเพราะไม่มีอะไรผิดปกติกับ EtM ฉันยังพบร่าง IETF AES-CBC-HMAC ที่ดำเนินการ EtMอย่างไรก็ตาม มันไม่เคยผ่านการร่างซึ่งทำให้ฉันรู้สึกแปลก

แก้ไข: เนื่องจากมีการกล่าวถึงชุด CCM Cipher ในขณะที่เรียกใช้ AES ในโหมด CTR จะหลีกเลี่ยงการเติม oracles มันไม่ได้อยู่ในชุดรหัสบังคับหรืออย่างใดอย่างหนึ่ง ควร ใช้ห้องชุด ดู: Cipher Suites ที่จำเป็นต้องนำไปใช้ ดังนั้นโดยทั่วไปแล้วเราไม่สามารถใช้ประโยชน์จากฮาร์ดแวร์ AES บนไมโครได้หากไม่มี GCM (เช่น เซิร์ฟเวอร์จำนวนมากปิดใช้งาน CCM โดยค่าเริ่มต้น และทั้ง Firefox และ Chrome ก็เปิดใช้งาน CCM) ดูเหมือนจะแปลกอีกครั้งที่ไม่มีอะไรอยู่ระหว่างนี้ และฉันไม่เห็นเหตุผลที่ดีว่าทำไม และโหมด EtM ดูเหมือนจะเป็นตัวเลือกที่ดี แต่ไม่เคยถูกเพิ่มเข้าไปในมาตรฐานด้วยซ้ำ

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

ciphersuites ที่มีอยู่คือ:

• TLS_AES_128_CCM_SHA256
• TLS_AES_128_CCM_8_SHA256 (ตามที่กำหนด ใน RFC 6655)

หลังยังมีแท็กการรับรองความถูกต้องที่มีประสิทธิภาพมากกว่า (เกี่ยวกับขนาด ไม่ใช่ความพยายามในการคำนวณ) ที่ 8 ไบต์ / 64 บิต ซึ่ง ควรจะเพียงพอ.

ดังนั้นฉันเดาว่าพวกเขาไม่คิดว่าจำเป็นต้องมีอัลกอริทึมอื่น เนื่องจากมีระบบฝังตัวไม่กี่ตัวที่มีการเร่งความเร็ว SHA-1 หรือ SHA-256

หมายเหตุ:

• แฮชที่ส่วนท้ายของ ciphersuite ใช้สำหรับการสืบทอดคีย์เซสชันเท่านั้น (PRF ใน TLS) ดังนั้นจึงไม่ได้ใช้สำหรับแต่ละข้อความ
• AES ในโหมด CTR และ ใน CBC-MAC จะใช้เฉพาะในโหมดการส่งต่อ / การเข้ารหัส ดังนั้นคุณไม่จำเป็นต้องมีการสนับสนุนฮาร์ดแวร์สำหรับการดำเนินการถอดรหัส