AES-GCM หรือ ChaCha20-Poly1305: การเลือกการเข้ารหัสข้อมูลของ VPN

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

งานเดียวกัน แกนต่างกัน

โครงสร้างทั้งสองให้ความลับและความสมบูรณ์ในการผ่านครั้งเดียวและรับรองข้อมูลที่เกี่ยวข้อง จึงเป็นเหตุให้โปรโตคอล VPN ใช้มันกับช่องทางข้อมูล ความแตกต่างอยู่ข้างใน AES-GCM คือการเข้ารหัสบล็อก AES ในโหมดตัวนับพร้อมตัวรับรองพหุนามบน GF(2^128) ขณะที่ ChaCha20-Poly1305 คือการเข้ารหัสแบบสตรีมด้วยคีย์ 256 บิตและตัวรับรองแบบใช้ครั้งเดียวแยกต่างหาก

สิ่งที่สำคัญในเชิงปฏิบัติการนั้นเหมือนกัน ทั้งคู่ล้มเหลวอย่างร้ายแรงเมื่อใช้ nonce ซ้ำ ทั้งคู่ต้องจัดการพื้นที่ nonce ต่อคีย์ และไม่มีตัวใดแก้ไขคู่ที่รับรองสิ่งที่ผิด โปรไฟล์ที่ระบุ AES-256-GCM ไม่ปลอดภัยกว่าโปรไฟล์ที่ระบุ CHACHA20-POLY1305 ทั้งคู่แข็งแรงเมื่อการนำไปใช้ถูกต้อง

ที่ที่ AES-GCM ชนะ

AES มีคำสั่งเฉพาะบน CPU สมัยใหม่ส่วนใหญ่ AES-NI บน x86 ส่วนขยายคริปโตบน ARMv8 และสิ่งที่เทียบเท่าบนการออกแบบ POWER และ RISC-V ล่าสุด เมื่อมีสิ่งเหล่านี้ GCM จะทำงานหลายบล็อกพร้อมกันต่อคลาสรอบ และการนำไปใช้ในซอฟต์แวร์ก็ไม่สำคัญ นี่คือกรณีปกติของเซิร์ฟเวอร์ เดสก์ท็อปและโทรศัพท์ในปัจจุบัน และนั่นคือเหตุผลที่คำแนะนำให้ใช้ AES เป็นค่าเริ่มต้นที่สมเหตุสมผลในศูนย์ข้อมูล

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

ตรวจสอบสิ่งที่โปรเซสเห็นจริง ไม่ใช่สิ่งที่ CPU รองรับ: grep -o aes /proc/cpuinfo | head -1 บน Linux หรือแฟล็กคุณสมบัติที่เทียบเท่าในโมเดล CPU ของไฮเปอร์ไวเซอร์

ที่ที่ ChaCha20-Poly1305 ชนะ

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

ทางเลือกเดียวนั้นบอกสิ่งที่เป็นประโยชน์ บนฮาร์ดแวร์ที่มีการเร่ง AES นั้น WireGuard ยอมสละอัตราการส่งผ่านบางส่วนเมื่อเทียบกับ AES-GCM และผู้เขียนยอมรับสิ่งนั้นเพื่อแลกกับพฤติกรรมที่คาดเดาได้บนโทรศัพท์ เราเตอร์ในบ้านและโฮสต์คอนเทนเนอร์ หากฝูงของคุณส่วนใหญ่เป็นกล่อง ARM ขนาดเล็ก การแลกเปลี่ยนนั้นเป็นผลดีกับคุณ

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

สิ่งที่โปรโตคอลของคุณให้คุณเลือกได้จริง

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

ใน OpenVPN การเข้ารหัสของช่องข้อมูลมาจากรายการ data-ciphers ที่ทั้งสองปลาย หากรายการของเซิร์ฟเวอร์และรายการของไคลเอนต์ไม่ตัดกัน การเชื่อมต่อจะถอยกลับไปสิ่งที่ data-ciphers-fallback อนุญาตหรือล้มเหลวทั้งหมด และความล้มเหลวนั้นมักถูกตำหนิที่ชั้นผิด ใส่รายการเดียวกันทั้งสองด้าน จากนั้นยืนยันผลการเจรจาในบันทึกแทนการสันนิษฐานว่าลำดับของรายการได้รับการเคารพ

ตัดสินจากข้อเท็จจริงสามข้อเกี่ยวกับการติดตั้ง

ข้อแรก ปลายทางมีการเร่ง AES หรือไม่ หากทุกคู่มี AES-GCM คือตัวเลือกที่ถูกกว่าและเป็นค่าเริ่มต้นในการกำหนดค่าที่ดูแลอยู่ส่วนใหญ่ หากส่วนสำคัญเป็นเราเตอร์เล็กหรือโทรศัพท์เก่า ChaCha20-Poly1305 จะป้องกันไม่ให้หางของฝูงกลายเป็นขีดจำกัดความจุ

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

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

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