เจสัน เอ. โดเนนเฟลด์, ผู้เขียน VPN WireGuard ทำให้เป็นที่รู้จัก ไม่กี่วันที่ผ่านมามีการใช้งานใหม่ อัปเดตจากตัวสร้างตัวเลขสุ่ม RDRANDซึ่งรับผิดชอบการทำงานของอุปกรณ์ / dev / random และ / dev / urandom ในเคอร์เนล Linux
เมื่อปลายเดือนพฤศจิกายน Jason ถูกรวมอยู่ในรายชื่อผู้ดูแลตัวควบคุมแบบสุ่ม และขณะนี้ได้เผยแพร่ผลงานชิ้นแรกในการทำงานซ้ำของเขาแล้ว
มีการกล่าวถึงในการประกาศว่าการดำเนินการใหม่มีความโดดเด่นสำหรับ เปลี่ยนไปใช้ฟังก์ชันแฮช BLAKE2s แทน SHA1 สำหรับการผสมเอนโทรปี
BLAKE2s เองมีคุณสมบัติที่ดีในการอิงจากภายใน
การเรียงสับเปลี่ยน ChaCha ซึ่ง RNG ใช้สำหรับการขยายอยู่แล้วดังนั้น
ไม่น่าจะมีปัญหากับความแปลกใหม่ ความคิดริเริ่ม หรือ CPU ที่น่าทึ่ง
พฤติกรรมตามสิ่งที่ใช้อยู่แล้ว
นอกจากนี้ ยังสังเกตได้ว่าการเปลี่ยนแปลง ยังปรับปรุงความปลอดภัยของตัวสร้างตัวเลขสุ่มเทียม โดยการกำจัดอัลกอริธึม SHA1 ที่ยุ่งยากและหลีกเลี่ยงการเขียนทับเวกเตอร์การเริ่มต้น RNG เนื่องจากอัลกอริธึม BLAKE2 นั้นเหนือกว่า SHA1 ในด้านประสิทธิภาพ การใช้งานก็ส่งผลดีต่อประสิทธิภาพของตัวสร้างตัวเลขสุ่มหลอก (การทดสอบบนระบบที่มีโปรเซสเซอร์ Intel i7-11850H พบว่ามีความเร็วเพิ่มขึ้น 131%) ) .
ข้อดีอีกประการหนึ่งที่โดดเด่นคือการถ่ายโอนส่วนผสมเอนโทรปีไปยัง BLAKE2 คือการรวมกันของอัลกอริทึมที่ใช้: BLAKE2 ใช้ในการเข้ารหัส ChaCha ซึ่งใช้ในการแยกลำดับแบบสุ่มแล้ว
โดยทั่วไปแล้ว BLAKE2 จะเร็วกว่าและปลอดภัยกว่าอย่างแน่นอน มันพังมากจริงๆ นอกจากนี้ บิลด์ปัจจุบันใน RNG ไม่ได้ใช้ฟังก์ชัน SHA1 เต็มรูปแบบ เช่น ระบุและอนุญาตให้คุณเขียนทับ IV ด้วยเอาต์พุต RDRAND ในทาง ไม่มีเอกสาร แม้ว่า RDRAND จะไม่ได้กำหนดค่าเป็น "เชื่อถือได้" ซึ่ง ซึ่งหมายถึงตัวเลือก IV ที่อาจเป็นอันตรายได้
และความยาวสั้นของมันหมายถึง เพื่อเก็บเป็นความลับเพียงครึ่งเดียวเมื่อป้อนกลับเข้าเครื่องผสม ให้ความลับส่งต่อแก่เราเพียง 2 ^ 80 บิต กล่าวอีกนัยหนึ่งไม่เพียงเท่านั้น ทางเลือกของฟังก์ชั่นแฮชนั้นล้าสมัย แต่การใช้งานก็ไม่ค่อยดีเช่นกัน.
นอกจากนี้ยังมีการปรับปรุงตัวสร้างตัวเลขสุ่มหลอก CRNG ที่ปลอดภัยสำหรับการเข้ารหัสที่ใช้ในการโทร getrandom
ยังกล่าวอีกว่า การปรับปรุงจะลดลงเพื่อจำกัดการโทรไปยังตัวสร้าง RDRAND ช้าเมื่อดึงเอนโทรปีซึ่ง สามารถปรับปรุงประสิทธิภาพได้ 3,7 เจสันแสดงให้เห็นว่าการเรียก RDRAND สมเหตุสมผลในสถานการณ์ที่ CRNG ยังไม่ได้เตรียมใช้งานอย่างสมบูรณ์ แต่ถ้าการเริ่มต้น CRNG เสร็จสมบูรณ์ ค่าของ CRNG จะไม่ส่งผลต่อคุณภาพของสตรีมที่สร้างขึ้น และในกรณีนี้ สามารถทำได้โดยไม่ต้องโทร ร.ร.
ความมุ่งมั่นนี้มีจุดมุ่งหมายเพื่อแก้ปัญหาทั้งสองนี้และในขณะเดียวกันก็รักษา โครงสร้างทั่วไปและความหมายใกล้เคียงกับต้นฉบับมากที่สุด
โดยเฉพาะ:ก) แทนที่จะเขียนทับแฮช 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)
สุดท้ายนี้ หากสนใจอยากทราบข้อมูลเพิ่มเติม สามารถเข้าไปดูรายละเอียดใน ลิงค์ต่อไปนี้