ไลบรารี random number generation ตัวใหม่ของ C++ ที่มาพร้อมกับ WELL (Well Equidistributed Long-period Linear) generators ได้จุดประกายการถกเถียงอย่างเข้มข้นในชุมชนโปรแกรมเมอร์เกี่ยวกับว่าควรใช้ cryptographically secure random number generators เป็นตัวเลือกเริ่มต้นสำหรับแอปพลิเคชันทั้งหมดหรือไม่
ไลบรารีนี้ซึ่งเน้นไปที่การสร้าง pseudo-random number ที่มีประสิทธิภาพสูง พร้อมคุณสมบัติอย่างการทำงานแบบ cross-platform reproducibility และอัลกอริทึม distribution ที่ปรับให้เหมาะสม ได้กลายเป็นจุดศูนย์กลางของการถกเถียงในเชิงปรัชญาที่กว้างขึ้นเกี่ยวกับความปลอดภัยเทียบกับประสิทธิภาพในการพัฒนาซอฟต์แวร์
การเปรียบเทียบตระกูล WELL Generator
- WELL44497b เทียบกับ WELL19937a แสดงผลลัพธ์ "ตรงกันข้าม" ใน TestU01 ในภาษาโปรแกรมที่แตกต่างกัน
- การปรับขนาด state space ให้เหมาะสมขึ้นอยู่กับค่า TBit และ MASK เป็นหลัก
- พารามิเตอร์เพิ่มเติม (K, J) ให้ข้อจำกัดแต่ไม่ส่งผลกระทบอย่างมีนัยสำคัญต่อประสิทธิภาพของชุดทดสอบ
ข้อโต้แย้งเรื่อง Security-First เผชิญกับการต่อต้านอย่างแรง
หนึ่งในประเด็นที่ถกเถียงกันมากที่สุดเกิดขึ้นเมื่อนักพัฒนาคนหนึ่งโต้แย้งว่ามี use case ที่น้อยมากสำหรับ non-crypto RNGs และเสนอให้ random number generation ทั้งหมดควรเป็น cryptographically secure โดยค่าเริ่มต้น ตำแหน่งนี้ซึ่งสนับสนุนอัลกอริทึมอย่าง Randen ที่ให้การรับประกันความปลอดภัยที่พิสูจน์ได้ ได้เผชิญกับการต่อต้านอย่างมากจากชุมชน
นักวิจารณ์ได้ชี้ให้เห็นอย่างรวดเร็วถึงผลกระทบด้านประสิทธิภาพที่มหาศาลของแนวทางนี้ นักพัฒนาหลายคนเน้นย้ำว่าอุตสาหกรรมจำนวนมากรวมถึงวิทยาศาสตร์, neural networks, การจำลอง, เกม, การเรนเดอร์, การสร้างแบบจำลองสภาพอากาศ, การวิจัยนิวเคลียร์, หุ่นยนต์ และการประมวลผลสัญญาณ ต้องการตัวเลขสุ่มหลายพันล้านถึงหลายล้านล้านตัวอย่างรวดเร็ว สำหรับแอปพลิเคชันเหล่านี้ ภาระของ cryptographically secure generators จะเป็นอุปสรรคที่ใหญ่เกินไป
ข้อพิจารณาด้านความปลอดภัย
- การใช้งาน ChaCha CSPRNG อาจมีค่า seed entropy ไม่เพียงพอ (32-64 บิต)
- กระแสข้อมูลขาออกจะวนซ้ำหลังจาก 2^32 บล็อก ซึ่งสามารถขยายได้
- อัลกอริทึม Randen ให้ความปลอดภัยที่พิสูจน์ได้โดยอิงจากพื้นฐาน AES primitives
- Linux vDSO getrandom() เสนอตัวเลขสุ่มที่ปลอดภัยทางการเข้ารหัสลับแบบเร็ว (รวมเข้าด้วยกันในเดือนกรกฎาคม 2024)
ปรัชญาการออกแบบ API จุดประกายการถกเถียงทางเทคนิค
การสนทนายังเจาะลึกไปถึงหลักการพื้นฐานของการออกแบบ API โดยเฉพาะเรื่องกลไก seeding นักพัฒนาถกเถียงกันว่าฟังก์ชันที่สะดวกควรอนุญาให้ manual seeding หรือใช้ entropy sources เสมอ การถกเถียงเผยให้เห็นความตึงเครียดแบบคลาสสิกระหว่าง backward compatibility และการปรับปรุงความปลอดภัย โดยอ้างอิงถึงวิธีที่ระบบเก่าอย่างฟังก์ชัน rand() ของ glibc ยังคงติดอยู่กับอัลกอริทึมที่ล้าสมัยเนื่องจากสัญญา API
โซลูชันทางเทคนิคที่น่าสนใจอย่างหนึ่งที่เสนอมาเกี่ยวข้องกับการใช้ thread-local storage เพื่อให้ความสะดวกและ seeding ที่เหมาะสมพร้อมกัน แสดงให้เห็นว่าคุณสมบัติ C++ สมัยใหม่สามารถแก้ไขปัญหา random number generation แบบดั้งเดิมได้อย่างไร
การอ้างสิทธิ์เรื่องประสิทธิภาพสร้างความสงสัย
เบนช์มาร์กประสิทธิภาพของไลบรารีที่แสดงให้เห็นว่า generator บางตัวทำงานที่ 100-105% ของประสิทธิภาพ standard library ทำให้นักพัฒนาที่มีประสบการณ์เกิดความสงสัย บางคนตั้งคำถามถึงความน่าเชื่อถือของตัวเลขเหล่านี้ ในขณะที่คนอื่นๆ เน้นไปที่ความกังวลที่ปฏิบัติได้มากกว่า เช่น แนวทางของไลบรารีต่อการสร้าง floating-point number และความสอดคล้อง cross-platform
การถกเถียงยังสัมผัสถึงโซลูชันระดับ kernel ที่เกิดขึ้นใหม่อย่าง vDSO getrandom() ของ Linux ซึ่งให้การเข้าถึงที่รวดเร็วไปยัง cryptographically secure random numbers แม้ว่านักพัฒนาจะสังเกตว่านี่ยังคงช้ากว่า specialized pseudo-random generators สำหรับแอปพลิเคชันที่ต้องการ throughput สูงอย่างมาก
การเปรียบเทียบประสิทธิภาพ
- std::minstd_rand: ประสิทธิภาพพื้นฐาน 100%
- std::mt19937: ประสิทธิภาพ 105% เมื่อเทียบกับพื้นฐาน
- ไลบรารีอ้างว่ามีการกระจายแบบสม่ำเสมอและปกติที่เร็วกว่า พร้อมความสอดคล้องของลำดับข้ามแพลตฟอร์ม
- การกระจายแบบปกติที่รวดเร็วโดยใช้การประมาณแบบทวินามที่ใช้ popcount สำหรับแอปพลิเคชันเกมและการทดสอบ
คำตัดสิน: บริบทมีความสำคัญ
การถกเถียงในที่สุดได้เสริมหลักการสำคัญในการพัฒนาซอฟต์แวร์: การเลือกเครื่องมือที่เหมาะสมสำหรับงาน ในขณะที่ cryptographically secure generators มีความจำเป็นสำหรับแอปพลิเคชันที่มีความไวต่อความปลอดภัย การใช้ random number ส่วนใหญ่ในการคำนวณทางวิทยาศาสตร์ เกม และงานจำลองต้องการความเร็วและ determinism ที่ specialized pseudo-random generators ให้
ใช้เครื่องมือที่เหมาะสมสำหรับงาน ขยายมุมมองของคุณเกี่ยวกับสิ่งที่ใช้สำหรับอะไร
การถกเถียงเน้นย้ำให้เห็นว่าโดเมนต่างๆ มีความต้องการที่แตกต่างกันอย่างมาก และการแนะนำแบบกว้างๆ ให้ใช้ cryptographically secure generators เสมอนั้นล้มเหลวในการคำนึงถึงความต้องการที่หลากหลายของชุมชนโปรแกรมเมอร์
อ้างอิง: well-random