CFB1 กับ CFB8 กับ CFB128 คือขนาดฟีดแบ็ก ไม่ใช่ขนาดคีย์
ตัวเลขหลัง CFB คือขั้นฟีดแบ็ก ไม่ใช่ความยาวคีย์: CFB1, CFB8 และ CFB128 ใช้บล็อก 128 บิตเหมือนกัน อ่านชื่อเก่าโดยไม่ต้องสร้างคีย์อ่อนขึ้นมาเอง
ชื่ออย่าง AES-256-CFB1 มีตัวเลขสองตัว และทั้งสองตอบคำถามคนละข้อ 256 คือความยาวคีย์ AES ส่วน 1 คือฟีดแบ็กของ CFB หรือขนาดเซกเมนต์ ซึ่งเป็นคุณสมบัติของการที่โหมดเลื่อนสถานะของตัวเอง ถ้าอ่าน 1 เป็นความยาวคีย์ ชื่อนั้นก็ดูเหมือนการกำหนดค่าผิดขั้นร้ายแรง และนั่นคือเหตุผลที่คำถามนี้กลับมาอีกเรื่อย ๆ
ตัดสินใจก่อนว่าคุณกำลังดูปริมาณใดในสามอย่าง: ขนาดคีย์ ขนาดบล็อก หรือขนาดเซกเมนต์ มีเพียงอย่างแรกที่เป็นพารามิเตอร์ความปลอดภัยในความหมายปกติ
สามตัวเลข สามปริมาณ
AES รับคีย์ 128, 192 หรือ 256 บิต และมีบล็อก 128 บิตไม่ว่าคุณจะเลือกอะไร ขนาดบล็อกเป็นของ AES ไม่ใช่ของโหมด ต่อท้าย CFB คือปริมาณที่สาม: โหมดใช้และป้อนกลับข้อมูลเท่าไรต่อขั้น เอกสาร AES ของ OpenSSL ระบุขนาดการเลื่อนเหล่านั้นอย่างชัดเจนสำหรับรูปแบบ CFB
CFB1 ป้อนกลับครั้งละหนึ่งบิต CFB8 หนึ่งไบต์ CFB128 หนึ่งบล็อกเต็ม ทั้งสามใช้บล็อกไซเฟอร์ 128 บิตเดียวกันภายใน สิ่งที่เปลี่ยนคือใช้กี่บิตของแต่ละบล็อกที่คำนวณต่อการดำเนินการ ดังนั้นส่วนต่อท้ายจึงเปลี่ยนต้นทุนและพฤติกรรมการบัฟเฟอร์ ไม่ใช่ความแข็งแรงของคีย์
| Name | Key | AES block | Feedback |
|---|---|---|---|
| AES-256-CFB1 | 256 bits | 128 bits | 1 bit |
| AES-256-CFB8 | 256 bits | 128 bits | 8 bits |
| AES-256-CFB128 | 256 bits | 128 bits | 128 bits |
ทำไมขนาดบล็อกไม่เคยเปลี่ยน
AES เป็นบล็อกไซเฟอร์ที่มีบล็อกคงที่ 128 บิต และโหมดคือโครงสร้างที่สร้างขึ้นรอบ ๆ มัน ไม่มีโหมดใดย่อบล็อกให้ตรงกับขนาดเซกเมนต์ การใช้งาน CFB1 ยังคงคำนวณบล็อก AES เต็มก้อนและเอาหนึ่งบิตของผลลัพธ์ บิตที่เหลือถูกทิ้งสำหรับขั้นนั้น และนั่นคือที่มาของต้นทุนประสิทธิภาพ
ดังนั้นฟีดแบ็กหนึ่งบิตไม่ได้หมายถึงคีย์หนึ่งบิต และชื่อไม่สามารถจัดอันดับตามส่วนต่อท้ายได้ CFB128 ไม่ได้แข็งแรงกว่า CFB32 สี่เท่า มันประมวลผลเซกเมนต์ที่ใหญ่กว่า
ขนาดเซกเมนต์เปลี่ยนอะไรจริง ๆ
ขนาดเซกเมนต์เปลี่ยนปริมาณข้อความเข้ารหัสที่ป้อนกลับต่อขั้น และปริมาณข้อความธรรมดาที่แต่ละขั้นพาไปได้ มันยังเปลี่ยนการแพร่ของข้อผิดพลาดและพฤติกรรมการบัฟเฟอร์ ซึ่งสำคัญต่อการใช้งานแบบสตรีม เซกเมนต์ที่เน้นไบต์เข้ากับบัฟเฟอร์ ส่วนที่เน้นบิตไม่เข้ากัน
ในทางปฏิบัติ โปรโตคอลเป็นผู้เลือกโหมด ไม่ใช่ผู้ดูแลระบบ ช่องข้อมูล ของ VPN ใช้โครงสร้างที่โปรโตคอลกำหนด พร้อมการป้องกันความสมบูรณ์ของตัวเอง และรายการไลบรารีเพียงบอกว่ามีชื่ออะไรบ้าง
การอ่านป้าย CFB ที่ไม่มีตัวระบุ
ป้าย CFB ที่ไม่มีตัวระบุต้องอาศัยบริบทการใช้งาน ในเฮดเดอร์ OpenSSL 1.0.2 นั้น EVP_aes_128_cfb เป็นมาโครสำหรับ EVP_aes_128_cfb128 พร้อมชื่อแทนที่ตรงกันสำหรับคีย์ 192 และ 256 บิต นั่นเป็นธรรมเนียมการตั้งชื่อ API จากสาขาเดียว ไม่ใช่ข้ออ้างว่าทุกไลบรารี รูปแบบไฟล์ หรือ GUI ขยายคำย่อเดียวกันนั้นเหมือนกัน ตรวจเฮดเดอร์หรือเอกสารของเวอร์ชันที่อยู่ตรงหน้าคุณ
ถ้าโปรไฟล์เก่าบอกว่า CFB และคู่ตรงข้ามยอมรับ พารามิเตอร์ที่เจรจาจะถูกบันทึกไว้ที่ใดที่หนึ่ง: ในล็อก ในดัมป์การกำหนดค่า ในคำตอบ API จงอ่านสิ่งเหล่านั้นแทนการอนุมานขนาดเซกเมนต์จากสตริงที่แสดง
สิ่งที่ชื่อโหมดไม่ได้บอกคุณ
ชื่ออธิบายพฤติกรรมการเข้ารหัสและไม่มีอะไรอื่น VPN ยังต้องการการป้องกันความสมบูรณ์ การสร้างคีย์ และการพิสูจน์ตัวตนคู่ตรงข้าม และ CFB ไม่ได้ให้สิ่งใดในนั้น การสลับ CFB8 เป็น CFB1 ก็ไม่ใช่การเปลี่ยนแปลงด้านรูปลักษณ์: พฤติกรรมบนสายต่างกันและทั้งสองฝ่ายต้องรองรับโครงสร้างเดียวกัน ชื่อในไลบรารีก็ไม่ได้พิสูจน์ว่าเกตเวย์ที่ติดตั้งยอมรับสำหรับช่องข้อมูลของตน
สำหรับทุกสิ่งที่ได้รับการดูแล ให้ใช้การจัดป้องกันเต็มรูปแบบของโปรโตคอลและนโยบายของผู้ดูแลระบบ และบันทึกเวอร์ชันไลบรารีและเกตเวย์ ตัวเลือกที่แน่นอน และผลการเจรจา ชื่อเก่าอธิบายสิ่งที่คุณกำลังอ่าน มันไม่ได้ให้เหตุผลในการฟื้นการกำหนดค่านั้น