AES-256 กับ OFB: เลือกโครงสร้างการเข้ารหัส VPN ที่ครบถ้วน

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

ระบุสี่ส่วนของโครงสร้าง

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

OFB ปรากฏในโหมดความลับในเอกสารของ NIST เรื่องโหมดรหัสบล็อก และความลับคือทั้งหมดที่มันให้ โปรโตคอลที่จับคู่โหมดการเข้ารหัสกับ MAC แยกต้องประกอบทั้งสองเข้าด้วยกันอย่างถูกต้อง และชื่ออัลกอริทึมไม่ได้พิสูจน์การประกอบนั้น ดังนั้นชื่อโหมดเพียงอย่างเดียวจึงตัดสินการติดตั้งไม่ได้

คำถามที่สี่คือสิ่งที่ผู้ดูแลระบบตรวจสอบได้จริงบนระบบที่กำลังทำงาน

เลือกโครงสร้างที่ผ่านการพิสูจน์ตัวตน

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

คำแนะนำการตั้งค่าคริปโตของ OpenVPN จาก Netgate ชี้ไปที่ตัวเลือก AEAD รวมถึง AES-GCM สำหรับช่องทางข้อมูล และนี่คือประเภทของนโยบายที่รองรับซึ่งควรปฏิบัติตาม ใช้ตัวเลือกที่รีลีสที่ติดตั้งและไคลเอนต์คู่สัญญารองรับ แทนที่จะคัดลอกลำดับโหมดในอดีตไปยังการติดตั้งใหม่ ความเข้ากันได้แบบเก่า แบ็กเอนด์คริปโต และการรองรับ offload ล้วนจำกัดสิ่งที่ใช้ได้จริง

โครงสร้างที่รองรับชนะการประกอบที่ชาญฉลาดทุกครั้ง

อ่านผลลัพธ์ที่ตกลงกัน ไม่ใช่ข้อเสนอ

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

openvpn --config client.conf --verb 4 2>&1 | grep -Ei 'cipher|data channel|auth'

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

บันทึกข้อเท็จจริงทั้งสองพร้อมกัน พร้อมวันที่และเวอร์ชันไคลเอนต์

วัดเฉพาะสิ่งที่เปรียบเทียบได้

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

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

หากคู่สัญญาเก่าไม่สามารถปฏิบัติตามนโยบายได้ นั่นคือการตัดสินใจด้านความเข้ากันได้สำหรับเจ้าของ

แยกความสมบูรณ์ออกจากการต่อรอง

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

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

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