ใช่ การโจมตีในคำถามสามารถทำงานได้ภายใต้สมมติฐานที่ระบุไว้ ไม่แนะนำให้เข้ารหัส AES-CTR ของช่องฐานข้อมูลด้วยเหตุผลนี้และอื่นๆ
กำลังใช้การบรรเทาบางส่วนที่เป็นไปได้ เข้ารหัสรับรองความถูกต้องตัวอย่างเช่น AES-GCM และรวมถึง รหัส และ ชื่อผู้ใช้ ฟิลด์ในข้อมูลที่รับรองความถูกต้อง ผลกระทบสุทธิคือข้อมูลที่เข้ารหัส (ในไฟล์ ที่อยู่ ฟิลด์) เปลี่ยนแปลงในทางใดทางหนึ่ง รวมทั้งแยกจากต้นฉบับ รหัส หรือ ชื่อผู้ใช้ หรือ IVจะล้มเหลวในการถอดรหัสด้วยความมั่นใจในการเข้ารหัส
การพิสูจน์ตัวตนจะเพิ่มขนาดของรหัสลับ (ข้อมูลในไฟล์ ที่อยู่ field) เท่ากับ 12 ไบต์ (นั่นคือพารามิเตอร์) โดยไม่คำนึงถึงขนาดของ รหัส และ ชื่อผู้ใช้ สนาม. การเพิ่มขนาดเล็กน้อยสามารถลดลงได้โดยการสร้างส่วน IV ของรหัสลับ ซึ่งแนะนำให้ทำต่อไปหากเพียงเพราะจะทำให้การเชื่อมโยงระหว่างรหัสลับและ IV หายไปน้อยลง การวาง IV ที่จุดเริ่มต้นของข้อมูลที่เข้ารหัสโดยรหัสบล็อกเป็นการปฏิบัติมาตรฐานอยู่แล้ว
การเข้ารหัสที่รับรองความถูกต้องให้การป้องกันที่ดีกว่าการรับคีย์ AES-CTR จากมาสเตอร์คีย์และ รหัส หรือ/และ ชื่อผู้ใช้: หากผู้ไม่หวังดีสามารถจัดการเพื่อเปลี่ยนแปลงข้อมูลที่เข้ารหัส CTR และสังเกตพฤติกรรมของระบบไอทีบางอย่างในข้อมูลที่ถอดรหัสได้ ก็ไม่ต้องกลัวว่าพวกเขาจะเรียนรู้บางอย่างเกี่ยวกับข้อมูล ตัวอย่างเช่น หากไบต์ '<' ในข้อมูลที่ถอดรหัสทำให้เกิดพฤติกรรมบางอย่างที่จดจำได้ ก็จะต้องใช้ความพยายาม 30 ครั้งต่ออักขระในการถอดรหัส เหมือนในภาพยนตร์ การเข้ารหัสที่รับรองความถูกต้องป้องกันสิ่งนี้ คีย์ที่ได้รับไม่ได้ป้องกัน
ฉันยังห่างไกลจากการระบุว่าการเข้ารหัสที่รับรองความถูกต้องของรายการฐานข้อมูลที่เป็นความลับนั้นไม่สามารถเข้าใจผิดได้ มันไม่ได้ให้ความคุ้มครองจากบุคคลภายในมากนัก มันไม่ได้ให้การป้องกันที่ดีสำหรับการสำรองข้อมูล เพราะบ่อยครั้งที่คีย์จะอยู่ในการสำรองข้อมูลมากเกินไป (ด้วยเหตุนี้ฉันจึงแนะนำให้เข้ารหัสการสำรองข้อมูลฐานข้อมูลด้วยรหัสสาธารณะและ การเข้ารหัสแบบไฮบริด). และการเข้ารหัสที่ผ่านการรับรองความถูกต้องสามารถหลีกเลี่ยงได้ ตัวอย่างเช่น ด้วยการเข้าถึงเพื่ออ่านฐานข้อมูลที่มีรหัสผ่านที่แฮช ผู้โจมตีมักจะสามารถเมานต์การค้นหารหัสผ่านที่จะค้นหารหัสผ่านของผู้ใช้บางคน จากนั้นจึงเข้าสู่ระบบในฐานะหนึ่งในผู้ใช้เหล่านี้ และด้วยสิทธิ์ในการเขียน ผู้โจมตีสามารถเปลี่ยนแฮชรหัสผ่านเป็นรหัสผ่านที่ตนรู้ และเข้าสู่ระบบในฐานะผู้ใช้ใดก็ได้ที่ต้องการ
อีกครั้ง: การเข้ารหัสไม่ควรเป็นแนวป้องกันด่านแรกสำหรับฐานข้อมูล ไม่ควรเข้าถึงแบบอ่านได้ ผู้โจมตีเข้าถึงแบบเขียนได้น้อยกว่ามากและฐานข้อมูลใช้ภาษาข้อความสำหรับการสืบค้นข้อมูล (ข้อผิดพลาดในการออกแบบซึ่งฝังแน่นอยู่ในแนวปฏิบัติด้านไอทีในปัจจุบัน ซึ่งอนุญาตและยังอนุญาตให้มีการโจมตีนับครั้งไม่ถ้วน และทำให้สิ้นเปลืองทรัพยากรคอมพิวเตอร์อย่างมากในการสร้างและแยกวิเคราะห์แบบสอบถาม) จากนั้น อย่างน้อยก็ได้รับการออกแบบและตรวจสอบอย่างรอบคอบ ชั้นซอฟต์แวร์การสร้างแบบสอบถามต้องบังคับใช้การแยกข้อมูลจากภาษาแบบสอบถาม