การเลือก AEAD สำหรับระบบใช้งานจริง

AES-GCM เป็น AEAD เริ่มต้นที่ถูกต้องสำหรับระบบใช้งานจริงส่วนใหญ่ มีการเร่งด้วยฮาร์ดแวร์ผ่าน AES-NI บนตัวประมวลผล x86 และ ARM64 สมัยใหม่แทบทั้งหมด รองรับอย่างแพร่หลายในชุดซอฟต์แวร์ TLS และไลบรารีการเข้ารหัส และได้รับประโยชน์จากการวิเคราะห์การเข้ารหัสอย่างกว้างขวาง รวมถึงประสบการณ์จากการใช้งานจริง

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

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

เมื่อมีโอกาสใช้ นอนซ์ซ้ำหรือต้องสร้าง นอนซ์แบบกำหนดผลลัพธ์แน่นอน เช่น ในบริการไม่มีสถานะหรือการห่อหุ้มคีย์ AES-GCM-SIV (RFC 8452) เป็นตัวเลือกที่ถูกต้อง โหมดนี้ให้ความสามารถในการต้านทานการใช้ นอนซ์ผิดวิธี โดยมีต้นทุนด้านประสิทธิภาพเพิ่มขึ้นไม่มากเมื่อเทียบกับ AES-GCM มาตรฐาน

ควรเลือก AEGIS-128L เมื่อจำเป็นต้องมีอัตราการประมวลผลการเข้ารหัสสูงสุด และรับรองได้ว่ามี AES-NI ในเป้าหมายการนำไปใช้งานทั้งหมด อุปกรณ์เครือข่ายแบนด์วิดท์สูง อุปกรณ์รวมการเชื่อมต่อ VPN และระบบเข้ารหัสพื้นที่จัดเก็บข้อมูล เป็นตัวเลือกที่เหมาะอย่างยิ่งเมื่อ AEGIS ให้ประสิทธิภาพที่เพิ่มขึ้นอย่างมีนัยสำคัญเหนือ AES-GCM

AES-128 ให้ความปลอดภัยระดับ 128 บิต ซึ่งถือว่าเพียงพอสำหรับภัยคุกคามจากการประมวลผลแบบดั้งเดิมทั้งหมดในปัจจุบันและที่คาดการณ์ได้ AES-256 ให้ขอบเขตความปลอดภัยเพิ่มเติมเพื่อรับมือความก้าวหน้าในอนาคต และเป็นข้อกำหนดของกรอบการปฏิบัติตามข้อกำหนดบางประเภท เช่น การจัดชั้นความลับ TOP SECRET ภายใต้ NSA Suite B สำหรับแอปพลิเคชันส่วนใหญ่ AES-128 เพียงพอและทำงานได้เร็วกว่าเล็กน้อย

AES-GCM ใช้ นอนซ์ขนาด 96 บิต ขณะที่ AES-GCM-SIV ก็ใช้ นอนซ์ขนาด 96 บิตเช่นกัน XSalsa20 ซึ่งใช้ใน secretbox ของ libsodium ใช้ นอนซ์ขนาด 192 บิต ทำให้การสร้าง นอนซ์แบบสุ่มปลอดภัยสำหรับข้อความจำนวนมากกว่าภายใต้คีย์เดียวกัน นอนซ์ที่มีขนาดใหญ่กว่าจะลดความเสี่ยงจากการใช้ซ้ำโดยไม่ตั้งใจในระบบที่มีปริมาณงานสูง

ควรใช้ไลบรารี AEAD ที่ผ่านการยอมรับอย่างแพร่หลาย แทนการนำองค์ประกอบพื้นฐานมาใช้งานโดยตรง libsodium มี API ของ AEAD ที่เรียบง่าย (crypto_aead_aes256gcm_encrypt, crypto_aead_chacha20poly1305_ietf_encrypt) Google Tink ห่อหุ้มองค์ประกอบพื้นฐานของ AEAD พร้อมการหมุนเวียนคีย์และการจัดการรุ่น ไลบรารี TLS ประจำภาษาจะจัดการ AEAD โดยอัตโนมัติเพื่อความปลอดภัยในการรับส่งข้อมูล

AES-CBC ที่ใช้ HMAC-SHA256 แยกต่างหาก (ตามลำดับ EtM) ยอมรับได้ แต่เป็นแนวทางแบบเก่า การย้ายไปใช้ AES-GCM ทำให้การใช้งานง่ายขึ้น โดยแทนที่องค์ประกอบพื้นฐานสองรายการด้วยองค์ประกอบเดียว และกำจัดความเสี่ยงจากการประกอบที่ไม่ถูกต้อง ข้อมูลขณะจัดเก็บที่เข้ารหัสด้วย CBC-HMAC ควรเข้ารหัสใหม่ด้วย AES-GCM ระหว่างการหมุนเวียนคีย์ตามกำหนดการ

ควรทดสอบการใช้งาน AEAD เทียบกับเวกเตอร์ทดสอบอย่างเป็นทางการจาก NIST (สำหรับ AES-GCM) และ RFC 8439 (สำหรับ ChaCha20-Poly1305) ต้องทดสอบเสมอว่าความล้มเหลวในการตรวจสอบแท็กการยืนยันความถูกต้องทำให้การถอดรหัสส่งคืนข้อผิดพลาด แทนที่จะส่งคืนข้อความต้นฉบับเพียงบางส่วน การจัดการข้อผิดพลาดที่ไม่ถูกต้องเป็นข้อบกพร่องที่พบได้บ่อยในการใช้งาน

เลือก AES-GCM เมื่อมี AES-NI และ นอนซ์ไม่ซ้ำกัน เลือก ChaCha20-Poly1305 เมื่อไม่มี AES-NI หรือ นอนซ์มีความน่าเชื่อถือน้อยกว่า เลือก AES-GCM-SIV เมื่อกังวลเรื่องการใช้ นอนซ์ซ้ำ เลือก AEGIS เมื่อสิ่งสำคัญอันดับแรกคืออัตราการประมวลผลสูงสุดและรับรองว่ามี AES-NI ห้ามเลือกโหมดที่ไม่ใช่ AEAD สำหรับระบบใหม่

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

AES-GCM เป็นค่าเริ่มต้น ChaCha20-Poly1305 เหมาะสำหรับสภาพแวดล้อมที่ไม่มี AES-NI AES-GCM-SIV จัดการสภาพแวดล้อมที่ นอนซ์ไม่ปลอดภัย AEGIS ให้อัตราการประมวลผลสูงสุดเมื่อรับรองว่ามี AES-NI ควรใช้ไลบรารีอย่าง libsodium หรือ Tink แทนการประกอบองค์ประกอบพื้นฐานด้วยตนเอง ต้องทดสอบกับเวกเตอร์ทดสอบอย่างเป็นทางการเสมอ และตรวจสอบว่าจัดการความล้มเหลวในการยืนยันความถูกต้องอย่างถูกต้อง