ความไร้ประโยชน์ของโคมลาวา: ความสุ่มหมายถึงอะไรจริง ๆ
(loup-vaillant.fr)- การโปรโมตเลขสุ่มที่อิงจาก lava lamp ของ Cloudflare ใกล้เคียงกับ การตลาดและละครความปลอดภัย มากกว่าการมีส่วนช่วยเชิงปฏิบัติอย่างมากต่อการเข้ารหัสบนอินเทอร์เน็ต
- ในวิทยาการเข้ารหัส สิ่งสำคัญไม่ใช่ ความสุ่มโดยเนื้อแท้ของค่า เท่ากับว่า ผู้โจมตีรู้อะไรเกี่ยวกับค่านั้นมากแค่ไหน และความต่างของความรู้นี้เป็นตัวกำหนดความปลอดภัย
- One-time pad สามารถซ่อนข้อมูลของข้อความต้นฉบับได้ หากใช้กุญแจที่สุ่มเพียงพอเพียงครั้งเดียว แต่ถ้านำกุญแจเดิมกลับมาใช้ซ้ำ มันจะถูกเจาะได้เมื่อรวมกับข้อมูลที่สังเกตได้
- ระบบสมัยใหม่ใช้ CSPRNG และสตรีมไซเฟอร์แทน one-time pad โดย ChaCha20 หรือ AES-256-CTR มอบความปลอดภัยที่ใช้งานได้จริงด้วยกุญแจ 256 บิต
- true RNG ทางกายภาพนั้นกำจัดอคติได้ยากและเพิ่มความปลอดภัยได้ไม่มากนัก ดังนั้นการออกแบบที่เรียบง่ายกว่าอย่างให้เซิร์ฟเวอร์สร้าง seed เองและใช้ fast key erasure จึงปลอดภัยกว่า
ความสุ่มขึ้นอยู่กับความรู้ของผู้สังเกต มากกว่าตัวสิ่งที่ถูกสังเกต
- Cloudflare โปรโมตว่า lava lamp ช่วยการเข้ารหัสบนอินเทอร์เน็ต แต่แนวทางนี้ใกล้เคียงกับ การตลาดและละครความปลอดภัย มากกว่าจะมีส่วนช่วยด้านความปลอดภัยอย่างมีนัยสำคัญ
- นอกจาก lava lamp แล้ว Cloudflare ยังใช้อุปกรณ์ความคาดเดาไม่ได้ทางกายภาพอย่าง double pendulums, wave motion, และ mobiles
- ฟังก์ชันแบบ XKCD ที่ทำเพียง
return 4จะคืนค่า 4 เสมอ จึงไม่สุ่มในตัวมันเอง แต่ถ้าผู้เรียกทราบเพียงข้อมูลว่าเป็น “ค่าคงที่ที่เลือกด้วยลูกเต๋ายุติธรรม” และเรียกใช้เพียงครั้งเดียว ในการกระจายความน่าจะเป็นของผู้สังเกตมันก็อาจถูกมองว่าเป็นค่าที่สุ่มได้ - คำถามสำคัญในวิทยาการเข้ารหัสไม่ใช่ว่า ผลลัพธ์สุ่มโดยเนื้อแท้หรือไม่ แต่คือผู้โจมตีรู้อะไรเกี่ยวกับผลลัพธ์นั้นมากแค่ไหน
- แม้จะเป็นค่าเดียวกัน ความหมายของความสุ่มก็เปลี่ยนไปตามว่าใครมีข้อมูลอะไรอยู่ และในระบบเข้ารหัส ความต่างของความรู้นี้เองที่กำหนดความปลอดภัย
วิธีที่ One-time pad ใช้งานได้และพังลง
- ในอุปมาเรื่อง Russian roulette ผู้สมรู้ร่วมคิดรู้ตำแหน่งกระสุน และพูดออกไปภายนอกเพียงผลลัพธ์จากการเอาตำแหน่งกระสุนไปบวกกับค่าลูกเต๋าที่แบ่งปันไว้ล่วงหน้ากับผู้เล่น
- ผู้เล่นสามารถลบค่าลูกเต๋าออกจากค่าที่ถูกประกาศเพื่อกู้คืนตำแหน่งกระสุนได้ แต่ฝ่ายตรงข้ามไม่รู้ค่าลูกเต๋า จึงไม่อาจรู้ตำแหน่งกระสุนได้จากค่าที่ถูกประกาศเพียงอย่างเดียว
- ถ้าเป็นลูกเต๋ายุติธรรม ความน่าจะเป็นก่อนสังเกต
P(Ci)ที่ฝ่ายตรงข้ามมี และความน่าจะเป็นหลังได้ยินเลขS3คือP(Ci|S3)จะเท่ากัน - ตามกฎของเบย์
P(Ci|S3) = P(Ci) × 1/6 ÷ 1/6 = P(Ci)ดังนั้นฝ่ายตรงข้ามจึง ไม่ได้เรียนรู้อะไรเลย แม้จะได้ยินค่าที่ถูกประกาศ - นี่คือแก่นของ One-time pad: หากใช้กุญแจที่สุ่มเพียงพอผูกกับข้อความเพียงครั้งเดียว ข้อความเข้ารหัสจะไม่เปิดเผยข้อมูลของข้อความต้นฉบับ
- หากนำกุญแจเดียวกันไปใช้ซ้ำในเกมที่สอง ฝ่ายตรงข้ามจะใช้ข้อมูลที่เปิดเผยจากเกมแรกเพื่อลดช่วงความเป็นไปได้ของค่าลูกเต๋าได้
- หากในเกมแรกยืนยันได้ว่าช่องหน้า 4 ช่องของปืนว่าง ฝ่ายตรงข้ามก็จะรู้ว่าเหลือเพียงความเป็นไปได้ที่ลูกเต๋าจะออก 3 หรือ 4 และเมื่อผู้สมรู้ร่วมคิดพูดว่า “Four” ในครั้งที่สอง ก็จะได้ข้อมูลเพิ่มเติมว่ากระสุนอยู่ที่ช่องแรกหรือช่องสุดท้ายเท่านั้น
- One-time pad ปลอดภัยได้เพียงครั้งเดียวตามชื่อของมัน หากใช้กุญแจเดิมซ้ำ ข้อความเข้ารหัสที่สังเกตได้จะรวมกับข้อมูลก่อนหน้าและทำให้ความปลอดภัยพังทลาย
ความยาวกุญแจและความปลอดภัยเชิงปฏิบัติของการเข้ารหัสสมัยใหม่
- บนอินเทอร์เน็ต เราส่งบิตและไบต์แทนตำแหน่งกระสุน และข้อความหนึ่งบิตแบบ “yes/no” สามารถซ่อนได้ด้วยการโยนเหรียญหนึ่งครั้ง
- ถ้าออกหัวก็ปล่อยข้อความไว้ตามเดิม ถ้าออกก้อยก็สลับ “yes” กับ “no” วิธีนี้ซ่อนข้อความต้นฉบับจากผู้สังเกตที่ไม่รู้ผลการโยนเหรียญ
- แต่ถ้าเข้ารหัส 2 บิตด้วยผลการโยนเหรียญเดียวกัน ข้อความเข้ารหัสจะลดความเป็นไปได้ของข้อความต้นฉบับจาก 4 แบบเหลือ 2 แบบ
- “Yes yes” หมายความว่าข้อความต้นฉบับเป็น “yes yes” หรือ “no no”
- “No no” หมายความว่าข้อความต้นฉบับเป็น “no no” หรือ “yes yes”
- “Yes no” หมายความว่าข้อความต้นฉบับเป็น “yes no” หรือ “no yes”
- “No yes” หมายความว่าข้อความต้นฉบับเป็น “no yes” หรือ “yes no”
- หากทำให้เป็นกรณีทั่วไป เมื่อเข้ารหัส n บิตด้วยการโยนเหรียญเพียงครั้งเดียว พื้นที่ข้อความต้นฉบับที่เป็นไปได้จะลดจาก
2^nเหลือ 2 แบบ - ในความหมายแบบสารสนเทศเชิงทฤษฎี หากต้องการเข้ารหัส n บิตอย่างสมบูรณ์ จำเป็นต้องใช้ กุญแจ n บิต และถ้าข้อความยาวกว่านั้น บางส่วนจะถูกถอดได้ และหากผู้สังเกตรู้ข้อมูลมากกว่า n บิตอยู่แล้ว โดยทั่วไปก็อาจถอดได้ทั้งข้อความ
- หากจะใช้ one-time pad กับทราฟฟิกทั้งหมดที่ Cloudflare ประมวลผล ก็จะต้องใช้จำนวนเลขสุ่มมหาศาลอย่างดาราศาสตร์ แต่ระบบสมัยใหม่ไม่ได้ใช้ one-time pad
- หากใช้งาน authenticated encryption และสตรีมไซเฟอร์อย่างถูกต้อง กุญแจ 256 บิตก็สามารถเข้ารหัสข้อมูลจำนวนมากได้อย่างปลอดภัยในทางปฏิบัติ
- หากใช้สตรีมไซเฟอร์ที่เหมาะสมอย่าง ChaCha20 หรือ AES-256-CTR ผู้สังเกตแบบพาสซีฟจะต้องลองประมาณ
2^255ชุดจึงจะหาข้อความต้นฉบับได้ - สำหรับผู้ที่รู้กุญแจ สตรีมนี้คาดเดาได้อย่างสมบูรณ์ แต่สำหรับผู้สังเกตระดับอารยธรรมโลกที่ไม่รู้กุญแจ มันทำงานเหมือน “เอนโทรปี” ที่คาดเดาไม่ได้โดยสิ้นเชิง
- ชื่ออย่างเป็นทางการของแนวทางนี้คือ Cryptographically Secure Pseudo-Random Number Generator หรือย่อว่า CSPRNG
การสร้างเลขสุ่มจริงและ fast key erasure
- หากต้องการอนุมานเลขสุ่มตามต้องการจากมาสเตอร์คีย์ 256 บิตเพียงตัวเดียว ก็สามารถเก็บมาสเตอร์คีย์ไว้บนมาสเตอร์เซิร์ฟเวอร์หรือฮาร์ดแวร์ซีเคียวริตีโมดูล แล้วสร้าง local key stream เพื่อแจกจ่ายอย่างปลอดภัยทั่วทั้งบริษัทได้
- แต่ละเซิร์ฟเวอร์หรือแต่ละ CPU core สามารถใช้ local key ขนาด 256 บิตและตัวนับเพื่อสร้างไบต์สุ่มได้มากเท่าที่ต้องการ
- ปัญหาสำคัญคือ การแจกจ่ายอย่างปลอดภัย นั้นยากมาก
- หาก local key รั่ว ข้อความทั้งหมดที่เครื่องนั้นเคยเข้ารหัสในอดีตและจะเข้ารหัสในอนาคตก็จะเสี่ยง และหากมาสเตอร์คีย์รั่ว ความเสียหายจะรุนแรงยิ่งกว่าเดิมมาก
- fast key erasure คือขั้นตอนที่ออกแบบมาเพื่อลดโอกาสกุญแจรั่วและลดความเสียหายหากเกิดการรั่ว
- วาง random seed ขนาด 32 ไบต์ไว้ที่ต้นบัฟเฟอร์ 512 ไบต์
- ใช้ seed นั้นสร้างข้อมูล 512 ไบต์เพื่อเขียนทับบัฟเฟอร์
- ส่งออกส่วนที่เหลือยกเว้น 32 ไบต์แรกตามคำขอ แล้วลบทิ้ง
- เมื่อใช้บัฟเฟอร์หมดแล้ว ให้กลับไปสู่ขั้นตอนการสร้างอีกครั้ง
- คำว่า “erasure” มาจากการที่ขั้นตอนการสร้างลบกุญแจเดิมทิ้งไป
- หากบัฟเฟอร์รั่ว ข้อความในอนาคตอาจเสี่ยงได้ แต่ค่าที่เคยส่งออกและลบไปแล้วในอดีตจะยังได้รับการปกป้อง
- ข้อควรระวังที่สำคัญยิ่งกว่าคืออย่าคัดลอกบัฟเฟอร์นี้
- ต้องไม่สร้างสองสตรีมจาก seed เดียวกัน
- เมื่อต้อง fork โปรเซส ต้องแยกสตรีมออกอย่างเหมาะสม
- หากเกิดสตรีมเดียวกันมากกว่าหนึ่งชุด ไบต์สุ่มชุดเดิมจะถูกใช้ซ้ำและอาจก่อผลร้ายแรงถึงขั้นวิกฤต
- ด้วยเหตุนี้จึงไม่แนะนำ RNG ใน user space และแม้ kernel RNG จะไม่ใช่เรื่องง่าย แต่จำนวนสิ่งที่ต้องตรวจสอบก็ยังน้อยกว่า
การเลือกสตรีมไซเฟอร์และส่วนเผื่อความปลอดภัย
- ขนาดบล็อกภายในของสตรีมไซเฟอร์พื้นฐานก็สำคัญเช่นกัน
- บล็อก 512 บิตของ ChaCha20 ใหญ่พอจนแทบไม่ต้องกังวล และบล็อก 128 บิตของ AES ก็ใหญ่พอเช่นกัน
- มีการโจมตีเชิงปฏิบัติต่อ AES ที่มีโอกาสสำเร็จดีกว่าการ brute force ธรรมดาอย่างมาก โดยมองว่า AES-128 อาจถูกเจาะได้ แต่ AES-256 ยังปลอดภัย
- สำหรับการใช้งานนี้ หากใช้ขนาดบล็อกเล็กกว่านี้ก็ควรมองว่าแตกแล้ว
- ตัวเลือกที่แนะนำคือ ChaCha20 หรือ AES-256 และเอนเอียงไปทาง ChaCha20 มากกว่า
- สตรีมไซเฟอร์สมัยใหม่ปลอดภัยมาก และเมื่อดูจากงานวิชาการกับการใช้งานโดยหลายรัฐบาล โดยเฉพาะสหรัฐฯ ก็เห็นว่าโอกาสจะถูกเจาะในอนาคตอันใกล้นั้นต่ำมาก
- เนื่องจากทั้ง CSPRNG และการเข้ารหัสต่างพึ่งพาไซเฟอร์ หากสิ่งใดสิ่งหนึ่งถูกเจาะ ระบบทั้งหมดก็จะพังตามไปด้วย
- หากสมมติว่า AES-256 หรือ ChaCha20 มีโอกาสถูกเจาะอย่างมีนัยสำคัญในอนาคตอันใกล้ ก็ยังมีวิธีเพิ่มส่วนเผื่อความปลอดภัยได้
- หากใช้ไซเฟอร์ตัวเดียวกันทั้งใน CSPRNG และการเข้ารหัส ก็จะตัดทางเลือกที่ผู้โจมตีต้องเจาะเพียง AES หรือ ChaCha อย่างใดอย่างหนึ่งออกไป และบังคับให้ต้องเจาะตัวที่กำหนดเพียงตัวเดียว
- การเพิ่มจำนวนรอบช่วยไม่เพียงเพิ่มต้นทุนของ brute force แต่ยังช่วยป้องกันการโจมตีที่ดีกว่า brute force ด้วย
- AES-256 ใช้ 14 รอบ และ ChaCha20 ใช้ 20 รอบ
- มีการโจมตี ChaCha7 ที่ดีกว่า exhaustive search แต่ปัจจุบันยังไม่มีการโจมตีแบบนั้นกับ ChaCha8
- ChaCha20 ใช้ 20 รอบเพื่อเผื่อไว้ แม้จะมีการค้นพบการโจมตี 12 รอบอย่างฉับพลันก็ยังไม่เป็นปัญหา
- การใช้หลายระบบแบบขนานกันเพิ่มความซับซ้อนโดยรวมอย่างมาก และความซับซ้อนนั้นมีแนวโน้มจะสร้างช่องโหว่ร้ายแรงได้มากกว่าการโจมตีเชิงคณิตศาสตร์ต่อองค์ประกอบใดองค์ประกอบหนึ่ง
true RNG ทางกายภาพและ seed เริ่มต้น
- ควรระวังแนวคิดที่ว่า true RNG ทางกายภาพปลอดภัยกว่า CSPRNG ที่อาจถูกเจาะได้ในทางทฤษฎีเสมอ
- เอาต์พุตสุ่มมักจำเป็นต้องไม่มีอคติที่ตรวจจับได้เพื่อความปลอดภัย ซึ่งหมายถึงการมีการกระจายที่สม่ำเสมอจนแม้จะวิเคราะห์ตัวอย่าง
2^64ชุดก็ยังตรวจไม่พบอคติ - เนื่องจากการปรับกระบวนการทางกายภาพให้ได้ระดับนั้นทำได้ยาก ในทางปฏิบัติจึงต้องนำเอาต์พุตจากแหล่งกำเนิดสัญญาณรบกวนไปผ่าน cryptographic hash
- เมื่อเทียบกับสตรีมไซเฟอร์ที่ใช้ fast key erasure การเพิ่มความปลอดภัยมีน้อย แต่ต้นทุนด้านประสิทธิภาพอาจสูงตามการใช้งาน
- หากต้องการสร้างเลขสุ่มปริมาณตามต้องการ ก็ยังจำเป็นต้องมี seed ช่วงแรกไม่กี่ไบต์ก่อน
- หากบันทึกดิจิทัลจากแหล่งที่คาดเดาไม่ได้ไว้นานพอจนได้เอนโทรปีเกิน 256 บิต แล้วนำบันทึกนั้นไปแฮชด้วยแฮช 256 บิตอย่าง SHA-256 หรือ BLAKE2s ก็สามารถสร้าง master seed ได้
- แหล่งความสุ่มที่เป็นไปได้ ได้แก่ hardware random number generator, CPU jitter, ภาพต้นไม้แบบสุ่ม, beam splitter, การกดแป้นพิมพ์หรือเหตุการณ์จากเมาส์, และลูกเต๋า
- การแจกจ่ายเลขสุ่มข้ามไซต์ไม่ใช่เรื่องที่ใช้งานได้จริง และนอกจากจะซับซ้อนแล้ว ยังอาจกลายเป็นสาเหตุของการถูกเจาะได้ด้วย
- เลขสุ่มไม่ได้ต้องใช้เพียงครั้งเดียว แต่ต้องใช้ทุกครั้งที่สงสัยว่ามีการเจาะระบบหรือเมื่อทำอัปเดตด้านความปลอดภัยที่สำคัญ
- เพื่อลดความยุ่งยากและความเสี่ยง โดยทั่วไปการให้คอมพิวเตอร์เครื่องนั้นสร้าง random seed สำหรับใช้งานเองจะดีกว่าการนำมาจากภายนอก
- เซิร์ฟเวอร์ทั่วไปมีทั้ง CPU jitter, ปฏิสัมพันธ์กับอุปกรณ์รอบข้าง, และเหตุการณ์เครือข่าย ซึ่งมักเพียงพอสำหรับการใช้งานทั่วไป
- หากต้องการความปลอดภัยเพิ่ม ก็อาจเพิ่ม hardware RNG dongle สองสามตัวในแต่ละแร็กของเซิร์ฟเวอร์ได้ แต่แนวทางที่ซับซ้อนกว่านั้นคือความซับซ้อนที่ไม่จำเป็น
เหตุใดกำแพงโคมลาวาจึงไม่จำเป็น
- กำแพง lava lamp ของ Cloudflare ไม่จำเป็น และหากเชื่อมต่อเข้ากับเซิร์ฟเวอร์ผ่านเครือข่ายภายใน ก็มีแต่จะเพิ่มความซับซ้อนและพื้นที่ผิวการโจมตี
- ถึงจะติดตั้งอย่างถูกต้อง ความเสี่ยงอาจต่ำมาก แต่ถึงอย่างนั้นความเสี่ยงก็ยังมากกว่าประโยชน์ที่ได้รับ
- หาก Cloudflare จริงจังกับความปลอดภัย ก็ควรเลิกใช้ lava lamp และคงไว้เพื่อการตกแต่งกับการตลาดเท่านั้น
- ให้เซิร์ฟเวอร์แต่ละเครื่องสร้างเลขสุ่มด้วยตัวเองจะเรียบง่ายกว่าและปลอดภัยกว่า
- เป็นไปได้ว่า Cloudflare เองก็อาจทำเช่นนั้นอยู่แล้ว
1 ความคิดเห็น
ความคิดเห็นจาก Lobste.rs
บทความนี้ดูเหมือนเขียนจากความเข้าใจที่คลาดเคลื่อน และออกแนวทำลายบรรยากาศเล็กน้อย การสร้างเลขสุ่มสมัยใหม่ ใช้แหล่งเอนโทรปีอิสระหลายแหล่ง และระหว่างที่คอมพิวเตอร์ทำงานก็จะนำสิ่งเหล่านี้มาแฮชผสมลงในพูลเอนโทรปีอย่างต่อเนื่อง
คอมพิวเตอร์ไม่ได้มี “random seed” เพียงค่าเดียว แต่จะถูกรีซีดอยู่เรื่อย ๆ ระหว่างการทำงานด้วยเอนโทรปีจากหลายแหล่งในลักษณะอย่าง
seed = hash(seed, new_data)การเพิ่มข้อมูลจากกล้องที่ถ่ายโคมลาวาไม่ได้ทำให้ความปลอดภัยของระบบลดลงเลย ข้อมูลที่ใส่เข้าไปในพูลเอนโทรปีจะถูกแฮชรวมกับข้อมูลอื่นที่มีอยู่แล้ว ระบบถูกออกแบบให้ปลอดภัยตราบใดที่ยังมีข้อมูลที่ผู้โจมตีไม่รู้แม้เพียงเล็กน้อย ดังนั้นการผสมข้อมูลจำนวนมากที่มีระดับความสุ่มต่างกันจึงไม่ทำลายความปลอดภัยโคมลาวา ไม่ได้ทำลายความปลอดภัยของระบบ และโดยส่วนตัวฉันมองว่ามันเป็นงานศิลปะที่สนุกและใช้งานได้จริงซึ่งเป็นส่วนหนึ่งของระบบ มันยังช่วยเพิ่มคุณภาพของเลขสุ่มขึ้นอีกเล็กน้อยมาก และทำให้แนวคิดเรื่องความสุ่มกับเอนโทรปีมองเห็นเป็นภาพได้
ก็จริง แต่ ตัวสร้างเลขสุ่มของเคอร์เนล ใช้ความสุ่มจากฮาร์ดแวร์หลากหลายมานานกว่า 30 ปีแล้ว และไม่ควรพูดเกินจริงว่ามีการรีซีด “ตลอดเวลา” หรือ “อย่างไม่หยุดยั้ง”
ความสุ่มจากฮาร์ดแวร์ถูกรวบรวมอย่างต่อเนื่องก็จริง แต่ตัวสร้างเลขสุ่มของ Linux จะรีซีดเป็นระยะ ในช่วง 1 นาทีแรกหลังบูตจะเกิดทุกไม่กี่วินาที และหลังจากนั้นจะช้าลงเป็นประมาณนาทีละครั้ง
https://zx2c4.com/projects/linux-rng-5.17-5.18/…
ผมไม่แน่ใจว่าให้ความรู้สึกว่าเคยพูดหรือสื่อเป็นนัยว่าระบบเดิมไม่เป็นแบบนั้นตรงไหน ที่นี่ไม่ได้ตั้งใจอธิบายระบบเดิม ยกเว้นส่วนของโคมลาวา แต่อยากเน้นว่าจริง ๆ แล้วเราต้องการน้อยแค่ไหน กล่าวคือแค่ 256 บิต ก็พอ
คำพูดที่ว่าการเพิ่มข้อมูลจากกล้องที่ถ่ายโคมลาวาไม่ได้ลดความปลอดภัย ทำให้ผมนึกถึง attack surface มันเท่ากับเพิ่มคอมพิวเตอร์ฝังตัวหนึ่งตัว และการสื่อสารเครือข่ายระหว่างคอมพิวเตอร์นั้นกับเซิร์ฟเวอร์ สำหรับผม ความเสี่ยงเล็กน้อยที่เพิ่มเข้ามานี้ดูใหญ่กว่าความเสี่ยงที่ต่ำจนน่าขันซึ่งจะทำให้ต้องพึ่งโคมลาวาเสียอีก
ถ้าจะอธิบายความต่างเชิงปรัชญาอีกแบบ ก็เป็นเรื่องนี้: มีผลลัพธ์ที่เป็นไปได้กี่แบบ และผลลัพธ์นั้นคาดเดาได้มากน้อยแค่ไหน
สำหรับจุดประสงค์ทางคริปโต เราตกลงกันที่ระดับการคาดเดาได้ประมาณ 2^-256 แต่ที่น่าสนใจคือมีกระบวนการทั่วไปบางอย่างที่มีจำนวนผลลัพธ์เป็นไปได้มากกว่านั้นมาก และบางครั้งเราต้องการให้สามารถสร้างผลลัพธ์ที่เป็นไปได้ทุกแบบได้ ไม่ว่าความน่าจะเป็นจะต่ำเพียงใด ในสถานการณ์แบบนั้น ความสุ่มเชิงคริปโต อาจไม่เพียงพอ
ไพ่หนึ่งสำรับมาตรฐานมีวิธีสับได้ 52! แบบ ซึ่งประมาณ 2^226 ดังนั้น seed ที่สุ่มเชิงคริปโตก็ยังครอบคลุมการสับทุกแบบได้ แต่ถ้าเล่น Uno หรือเอาไพ่หลายสำรับมาสับรวมกัน ตัวสร้างเลขสุ่ม 256 บิตจะมีสถานะไม่พอสำหรับการสร้างการสับทุกแบบ หากความสุ่มใน user space ของระบบทั้งหมดมาจากเคอร์เนล และเคอร์เนลส่งผ่านความสุ่มจากฮาร์ดแวร์ทั้งหมดเข้าสู่ CSPRNG 256 บิต ก็อาจยังไม่พอสำหรับการสับไพ่ใน Las Vegas :-)
สิ่งที่บทความไม่ได้พูดถึงคือ การรีซีด ซึ่งเป็นหัวข้อที่น่าสนใจเพราะแสดงให้เห็นทั้งการทำงานร่วมกับ fast key erasure และความยากของการได้ seed เริ่มต้น บทความทำเหมือนว่า Linux ใช้แค่ CPU jitter แต่จริง ๆ แล้วนี่เป็นการลดทอนมากเกินไป Linux ใช้แหล่งความสุ่มจำนวนมาก และท่าเต้น jitter นั้นเป็นเพียงทางเลือกสุดท้าย
ในโลกจริง เราไม่มีทางได้ตัวอย่างมากถึง 2^128 ตัวอย่างอยู่แล้ว ที่จริงน้อยกว่านั้นมาก และนั่นจึงเป็นเหตุผลที่ AES-128 ยังปลอดภัยเพียงพอสำหรับงานจำนวนมาก การ “รันผลลัพธ์ที่เป็นไปได้ทุกแบบ” เมื่อจำนวนผลลัพธ์มากกว่า 2^256 นั้นเป็นสิ่งที่ เป็นไปไม่ได้ โดยสิ้นเชิง ควรลืมแนวคิดนั้นไปเสีย มันไม่มีอยู่จริง
แม้แต่ในแบล็กแจ็กที่ใช้ไพ่ 6 สำรับ เราก็ไม่ได้ต้องการกระบวนการสับที่กระจายความน่าจะเป็นอย่างเท่าเทียมจริง ๆ ไปยังการสับที่เป็นไปได้ทั้งหมด แค่ให้การกระจายดีพอจนไม่สามารถแยกความต่างได้ ต่อให้สุ่มตัวอย่างมากที่สุดเท่าที่ทำได้ก็พอ ต่อให้จำนวนการสับถูกจำกัดไว้ที่ 2^256 หรือแม้แต่ 2^128 คุณก็จะไม่สังเกตเห็นความต่าง
ที่ไม่พูดถึงการรีซีดในบทความนั้นเป็นความตั้งใจ เพราะเราต้องการมันเฉพาะในบางช่วงเวลา เช่น เมื่อสงสัยว่ามีการเจาะระบบ หรือมีการอัปเดตความปลอดภัยบางอย่าง และอาจรวมถึงตอนรีบูต หากมันง่ายหรือปลอดภัยกว่าการเก็บสถานะของตัวสร้างเลขสุ่มไว้ในหน่วยความจำไม่ลบเลือน ดังนั้นแทนที่จะเรียกว่า “รีซีด” ผมจึงชอบมองว่าเป็นการเริ่มใหม่ด้วย seed เริ่มต้นตัวใหม่มากกว่า
ระหว่างการทำงานปกติไม่จำเป็นต้องรีซีดเลย ยิ่งทำยิ่งเพิ่มความซับซ้อน
เรื่องที่บทความชวนให้เข้าใจว่า Linux ใช้แค่ CPU jitter นั้นผมน่าจะตรวจสอบให้แน่ชัดก่อน ความเข้าใจของผมคือ ในช่วงบูต มันเป็นแหล่งเดียว โดยเฉพาะก่อนที่จะมีอินพุตจากผู้ใช้และเครือข่าย คุณรู้จักแหล่งอื่นอีกไหม? น่าจะมีการรองรับฮาร์ดแวร์สุ่มอยู่แล้ว
ทำไม่ได้ แต่ถ้าวางประเด็นนั้นไว้ก่อน วิธีทำให้ปลอดภัยมีดังนี้…
ถ้าเดาเอา ผมคิดว่าการ์ดฮาร์ดแวร์สร้างเลขสุ่มคงมีไว้เพื่อให้ได้แหล่งความสุ่มแบบขนานที่วัดกันไม่ใช่แค่ความหนาแน่นของบิต แต่รวมถึงจำนวนบิตต่อหน่วยเวลาด้วย
แม้ผมจะไม่ได้ไม่เห็นด้วยอย่างมากกับข้ออ้างแต่ละข้อ แต่ภาพรวมของข้อโต้แย้งกลับรู้สึกพร่า ๆ บทความปูมาว่า “คริปโตสมัยใหม่ต้องการความสุ่มจริงน้อยกว่าที่คนคิดมาก” แล้วไปลงที่ “ดังนั้นโคมลาวาจึงแย่กว่าเพราะขยาย attack surface”
ทั้งสองข้ออาจเป็นจริงได้ แต่เส้นทางจากต้นเรื่องไปสู่ข้อสรุปนั้นรู้สึกหยาบไปหน่อย
LavaRand ทำเรื่องแบบนี้มาตั้งแต่กว่า 20 ปีก่อนแล้ว ตอนนั้นมันดูน่ารักดี แต่สมัยนั้นเซ็นเซอร์กล้องมีขนาดเล็กกว่ามาก และด้วยคุณสมบัติที่คาดเดาได้ของเลนส์และสิ่งอื่น ๆ มันจึงไม่ใช่แหล่งเอนโทรปีที่ดีนัก
แม้ว่าผมจะชอบโคมลาวา แต่ผมมองว่าการใช้ไฟของกำแพงโคมลาวาหลายร้อยดวงนั้นค่อนข้างมากสำหรับอุปกรณ์แนวของเล่นแบบนี้
ใกล้เคียงกับการโปรโมตตัวเอง แทบไม่ค่อยแชร์ลิงก์ แต่พอแชร์ก็แชร์ลิงก์ของตัวเอง ใน 5 โพสต์ล่าสุด 5 โพสต์ล้วนชี้ไปยังงานของตัวเอง
“เป็นเรื่องดีที่ผู้เขียนมีส่วนร่วมกับชุมชน แต่ไม่ควรใช้มันเป็นเครื่องมือสื่อสารทางเดียวเพื่อโปรโมตสินค้า หรือดึงทราฟฟิกไปยังงานของตนเอง ตามกฎคร่าว ๆ การโปรโมตตัวเองควรมีสัดส่วนน้อยกว่าหนึ่งในสี่ของ stories และ comments ของตน”
ถ้ามีโพสต์ 15 โพสต์กับคอมเมนต์ 1399 คอมเมนต์ ก็ถือว่ามีส่วนร่วมกับชุมชนชัดเจน เว้นแต่จะไปคอมเมนต์ในโพสต์ของตัวเองเกิน 90 คอมเมนต์ทุกโพสต์
Cloudflare นำเอนโทรปีจากโคมลาวามาใช้, University of Chile ใช้ข้อมูลแผ่นดินไหว, ถ้าจำไม่ผิด EPFL ใช้ค่าการวัด การสลายกัมมันตรังสี, และผู้เข้าร่วมอีกหลายรายก็นำข้อมูลหลากหลายแบบมาร่วมในพิธีสร้างคีย์แรกเริ่มของเครือข่าย drand
จะใช้ CSPRNG แทนได้ไหม? แน่นอน ได้อยู่แล้ว แต่ถ้าทำแบบนั้นแล้วความสนุกอยู่ตรงไหน?