Jason A. Donenfeldผู้เขียน WireGuard VPN เพิ่งประกาศการใช้งานเวอร์ชันใหม่ที่ได้รับการปรับปรุงของตัวสร้างเลขสุ่ม RDRANDซึ่งรับผิดชอบการทำงานของอุปกรณ์ /dev/random และ /dev/urandom ในเคอร์เนล Linux
เมื่อปลายเดือนพฤศจิกายน Jason ถูกรวมอยู่ในรายชื่อผู้ดูแลตัวควบคุมแบบสุ่ม และขณะนี้ได้เผยแพร่ผลงานชิ้นแรกในการทำงานซ้ำของเขาแล้ว
ประกาศดังกล่าวระบุว่า การใช้งานเวอร์ชันใหม่นี้มีความโดดเด่นตรงที่เปลี่ยนมาใช้ฟังก์ชันแฮช BLAKE2s แทน SHA1สำหรับการดำเนินการผสมเอนโทรปี
BLAKE2s เองมีคุณสมบัติที่ดีในการอิงจากภายใน
การเรียงสับเปลี่ยน ChaCha ซึ่ง RNG ใช้สำหรับการขยายอยู่แล้วดังนั้น
ไม่น่าจะมีปัญหากับความแปลกใหม่ ความคิดริเริ่ม หรือ CPU ที่น่าทึ่ง
พฤติกรรมตามสิ่งที่ใช้อยู่แล้ว
นอกจากนี้ การเปลี่ยนแปลงนี้ยังช่วยปรับปรุงความปลอดภัยของตัวสร้างเลขสุ่มเทียมด้วยการกำจัดอัลกอริธึม SHA1 ที่มีปัญหา และป้องกันการเขียนทับเวกเตอร์เริ่มต้นของ RNG เนื่องจากอัลกอริธึม BLAKE2s มีประสิทธิภาพเหนือกว่า SHA1 การใช้งานอัลกอริธึมนี้จึงส่งผลดีต่อประสิทธิภาพของตัวสร้างเลขสุ่มเทียมด้วย (การทดสอบบนระบบที่มีโปรเซสเซอร์ Intel i7-11850H แสดงให้เห็นถึงความเร็วที่เพิ่มขึ้น 131%)
ข้อดีอีกประการหนึ่งที่ถูกเน้นย้ำคือ การถ่ายโอนการผสมเอนโทรปีไปยัง BLAKE2เป็นการรวมอัลกอริธึมที่ใช้เข้าด้วยกัน: BLAKE2 ถูกใช้ในรหัสลับ ChaCha ซึ่งถูกนำไปใช้ในการสร้างลำดับสุ่มอยู่แล้ว
โดยทั่วไปแล้ว BLAKE2s เร็วกว่าและปลอดภัยกว่าอย่างแน่นอน แต่ก็ถูกโจมตีอย่างรุนแรง นอกจากนี้โครงสร้าง RNG ปัจจุบันไม่ได้ใช้ฟังก์ชัน SHA1 อย่างเต็มที่ตามที่ระบุไว้ และอนุญาตให้มีการเขียนทับ IV ด้วยเอาต์พุต RDRAND โดยไม่มีการบันทึกไว้แม้ว่า RDRAND จะไม่ได้ถูกกำหนดค่าเป็น "เชื่อถือได้" ซึ่งหมายความว่าอาจมีตัวเลือก IV ที่เป็นอันตราย
และเนื่องจากความยาวที่สั้น ทำให้การเก็บความลับเพียงครึ่งเดียวเมื่อส่งกลับไปยังตัวผสมส่งผลให้เราได้ความลับแบบส่งต่อเพียง 2^80 บิตเท่านั้น กล่าวอีกนัยหนึ่ง ไม่เพียงแต่ฟังก์ชันแฮชที่เลือกใช้จะล้าสมัยเท่านั้น แต่การใช้งานก็ไม่ได้ดีเท่าที่ควรด้วย
นอกจากนี้ยังมีการปรับปรุงตัวสร้างตัวเลขสุ่มหลอก CRNG ที่ปลอดภัยสำหรับการเข้ารหัสที่ใช้ในการโทร getrandom
มีการกล่าวถึงด้วยว่าการปรับปรุงที่สำคัญคือการจำกัดการเรียกใช้ฟังก์ชันสร้างค่าสุ่มแบบ RDRAND ที่ทำงานช้าเมื่อทำการดึงค่าเอนโทรปี ซึ่งสามารถเพิ่มประสิทธิภาพได้ถึง 3,7 เท่า เจสันได้แสดงให้เห็นว่าการเรียกใช้ฟังก์ชัน RDRAND นั้นมีประโยชน์เฉพาะในกรณีที่ CRNG ยังไม่ได้รับการเริ่มต้นอย่างสมบูรณ์ แต่ถ้าการเริ่มต้น CRNG เสร็จสมบูรณ์แล้ว ค่าของมันจะไม่ส่งผลต่อคุณภาพของลำดับที่สร้างขึ้น และในกรณีนี้ สามารถทำได้โดยไม่ต้องเรียกใช้ฟังก์ชัน RDRAND
ความมุ่งมั่นนี้มีจุดมุ่งหมายเพื่อแก้ปัญหาทั้งสองนี้และในขณะเดียวกันก็รักษา โครงสร้างทั่วไปและความหมายใกล้เคียงกับต้นฉบับมากที่สุด
โดยเฉพาะ:ก) แทนที่จะเขียนทับแฮช IV ด้วย RDRAND เราใส่ฟิลด์ "เกลือ" และ "ส่วนบุคคล" ที่บันทึกไว้ใน BLAKE2 ซึ่งก็คือ สร้างขึ้นเพื่อการใช้งานประเภทนี้โดยเฉพาะ
b) เนื่องจากฟังก์ชันนี้ส่งคืนผลลัพธ์ของแฮชที่สมบูรณ์ไปที่ ตัวสะสมเอนโทรปี เราคืนค่าเพียงครึ่งหนึ่งของความยาวของ แฮชเหมือนที่เคยทำมาก่อน สิ่งนี้จะเพิ่ม สร้างความลับล่วงหน้าจาก 2^80 ถึง 2 ^ 128 สบายขึ้นมาก
c) แทนที่จะใช้ฟังก์ชันดิบ "sha1_transform" แต่เรากลับใช้ฟังก์ชัน BLAKE2s ที่สมบูรณ์และเหมาะสมแทนโดยสมบูรณ์
การเปลี่ยนแปลงดังกล่าวมีกำหนดจะรวมอยู่ในเคอร์เนลเวอร์ชัน 5.17และได้รับการตรวจสอบแล้วโดยนักพัฒนา Ted Ts'o (บุคคลที่สองที่รับผิดชอบในการดูแลไดรเวอร์สุ่ม), Greg Kroah-Hartman (ผู้รับผิดชอบในการรักษาเสถียรภาพของเคอร์เนล Linux) และ Jean-Philippe Aumasson (ผู้เขียนอัลกอริทึม BLAKE2/3)
สุดท้ายนี้ หากคุณสนใจเรียนรู้เพิ่มเติม สามารถดูรายละเอียดได้ที่ลิงก์ต่อไปนี้