S3 Ep95: การรั่วไหลของ Slack, การโจมตี Github และการเข้ารหัสลับหลังควอนตัม [เสียง + ข้อความ]

คลิกแล้วลากบนคลื่นเสียงด้านล่างเพื่อข้ามไปยังจุดใดก็ได้ นอกจากนี้คุณยังสามารถ ฟังโดยตรง บนซาวด์คลาวด์

ดั๊ก.  การรั่วไหลของ Slack, รหัส GitHub ที่ซุกซน และการเข้ารหัสหลังควอนตัม

ทั้งหมดนั้นและอีกมากมายในพอดคาสต์ Naked Security

[โมเด็มดนตรี]

ยินดีต้อนรับสู่พอดคาสต์ทุกคน

ฉันดั๊ก อามอธ

กับฉันเช่นเคยคือ Paul Ducklin

พอล วันนี้คุณเป็นอย่างไรบ้าง

---

เป็ด.  Super-duper ตามปกติ Doug!

---

ดั๊ก.  ฉันตื่นเต้นมากที่จะได้เข้าร่วมในสัปดาห์นี้ ประวัติเทคโนโลยี ส่วนเพราะ...

…คุณอยู่ที่นั่นผู้ชาย!

สัปดาห์นี้ วันที่ 11 สิงหาคม…

---

เป็ด.  ไม่นะ!

ฉันคิดว่าเพนนีเพิ่งลดลง ...

---

ดั๊ก.  ไม่ต้องบอกปี!

11 สิงหาคม 2003 – ​​โลกสังเกตเห็นหนอน Blaster ซึ่งส่งผลต่อระบบ Windows 2000 และ Windows XP

Blaster หรือที่รู้จักในชื่อ Lovesan และ MsBlast ใช้บัฟเฟอร์ล้นและอาจเป็นที่รู้จักดีที่สุดสำหรับข้อความ “บิลลี่ เกตส์ ทำไมคุณถึงทำให้มันเป็นไปได้? หยุดทำเงินและแก้ไขซอฟต์แวร์ของคุณ”

เกิดอะไรขึ้น พอล

---

เป็ด.  มันเป็นยุคก่อน บางที เราจริงจังกับการรักษาความปลอดภัยมาก

และโชคดีที่บั๊กประเภทนี้จะใช้ประโยชน์ได้ยากกว่ามากในปัจจุบัน: มันเป็นบัฟเฟอร์ล้นแบบสแต็ก

และถ้าฉันจำไม่ผิด เวอร์ชั่นเซิร์ฟเวอร์ของ Windows ก็ถูกสร้างขึ้นด้วยสิ่งที่เรียกว่า ป้องกันกอง.

กล่าวอีกนัยหนึ่ง หากคุณล้นสแต็กภายในฟังก์ชัน ก่อนที่ฟังก์ชันจะส่งคืนและสร้างความเสียหายกับสแต็กที่เสียหาย ฟังก์ชันจะตรวจพบว่ามีสิ่งเลวร้ายเกิดขึ้น

ดังนั้น จึงต้องปิดโปรแกรมที่ละเมิด แต่มัลแวร์จะไม่ทำงาน

แต่การป้องกันนั้นไม่ได้อยู่ใน Windows เวอร์ชันไคลเอ็นต์ในขณะนั้น

และอย่างที่ฉันจำได้ มันเป็นหนึ่งในมัลแวร์ยุคแรกๆ ที่ต้องเดาว่าคุณมีระบบปฏิบัติการเวอร์ชันใด

คุณอยู่2000? คุณอยู่ใน NT หรือไม่? คุณอยู่ใน XP หรือไม่?

และถ้ามันผิดพลาด ส่วนสำคัญของระบบก็จะพัง และคุณจะได้รับคำเตือนว่า "ระบบของคุณกำลังจะปิดตัวลง"

---

ดั๊ก.  ฮา ฉันจำมันได้!

---

เป็ด.  จึงมีหลักประกันความเสียหายที่สำหรับหลาย ๆ คนเป็นสัญญาณว่าคุณกำลังถูกทุบโดยการติดเชื้อ...

…ซึ่งอาจมาจากภายนอก เช่น ถ้าคุณเป็นเพียงผู้ใช้ตามบ้านและคุณไม่มีเราเตอร์หรือไฟร์วอลล์ที่บ้าน

แต่ถ้าคุณอยู่ในบริษัท การโจมตีที่น่าจะเป็นไปได้มากที่สุดจะมาจากคนอื่นในบริษัท และส่งแพ็กเก็ตบนเครือข่ายของคุณ

เช่นเดียวกับการโจมตี CodeRed ที่เราพูดถึง ซึ่งเมื่อสองสามปีก่อนในพอดคาสต์เมื่อเร็ว ๆ นี้ มันเป็นขนาด ปริมาตร และความเร็วที่แท้จริงของสิ่งนี้ที่เป็นปัญหา

---

ดั๊ก.  เอาล่ะ นั่นคือเมื่อประมาณ 20 ปีที่แล้ว

และถ้าเราย้อนเวลากลับไปเมื่อห้าปีที่แล้ว นั่นคือเวลาที่ Slack เริ่มรั่ว รหัสผ่านที่แฮช [เสียงหัวเราะ]

---

เป็ด.  ใช่ Slack เครื่องมือการทำงานร่วมกันยอดนิยม…

...มีคุณลักษณะที่คุณสามารถส่งลิงก์คำเชิญให้ผู้อื่นเข้าร่วมพื้นที่ทำงานของคุณได้

และคุณลองนึกภาพว่า: คุณคลิกปุ่มที่ระบุว่า "สร้างลิงก์" และจะสร้างแพ็กเก็ตเครือข่ายบางประเภทที่อาจมี JSON อยู่ภายใน

หากคุณเคยมีคำเชิญเข้าร่วมประชุม Zoom คุณจะรู้ว่ามีวันที่และเวลาและบุคคลที่เชิญคุณและ URL ที่คุณสามารถใช้สำหรับการประชุมและรหัสผ่านและทั้งหมดนั้น ข้อมูล – มันมีข้อมูลค่อนข้างมากในนั้น

โดยปกติ คุณไม่ต้องเจาะลึกข้อมูลดิบเพื่อดูว่ามีอะไรอยู่ในนั้น ลูกค้าเพียงแค่พูดว่า "นี่คือการประชุม นี่คือรายละเอียด คุณต้องการที่จะยอมรับ / อาจจะ / ปฏิเสธ?

ปรากฎว่าเมื่อคุณทำสิ่งนี้กับ Slack อย่างที่คุณพูดมานานกว่าห้าปี ข้อมูลที่รวมอยู่ในคำเชิญนั้นเป็นข้อมูลที่ไม่เกี่ยวข้องซึ่งไม่เกี่ยวข้องกับคำเชิญนั้นอย่างเคร่งครัด

ดังนั้น ไม่ใช่ URL ไม่ใช่ชื่อ ไม่ใช่วันที่ ไม่ใช่เวลา...

…แต่ *เชิญแฮชรหัสผ่านของผู้ใช้* [หัวเราะ]

---

ดั๊ก.  hmmmmm

---

เป็ด.  ฉันไม่ได้เป็นเด็ก!

---

ดั๊ก.  ฟังดูแย่…

---

เป็ด.  ใช่ มันใช่จริงๆ ใช่ไหม

ข่าวร้ายก็คือ มันเข้าไปอยู่ในโลกได้อย่างไร?

และเมื่อมันอยู่ในนั้นแล้ว มันหลบเลี่ยงการแจ้งให้ทราบเป็นเวลาห้าปีสามเดือนได้อย่างไร?

อันที่จริงแล้ว ถ้าคุณเข้าไปที่บทความเรื่อง Naked Security และดูที่ URL แบบเต็ม ของบทความ คุณจะสังเกตเห็นว่าในตอนท้าย blahblahblah-for-three-months.

เพราะตอนอ่านรายงานครั้งแรกใจไม่อยากเห็นเป็นปี 2017! [เสียงหัวเราะ]

วันที่ 17 เมษายน ถึง 17 กรกฎาคม จึงมีเลข “17” อยู่มากมาย

และความคิดของฉันก็ว่างเปล่าในปี 2017 เป็นปีเริ่มต้น – ฉันอ่านผิดว่าเป็น “เมษายนถึงกรกฎาคม *ของปีนี้*” [2022]

ฉันคิดว่า “ว้าว *สามเดือน* และพวกเขาไม่ได้สังเกตเลย”

แล้วความคิดเห็นแรกของบทความก็คือ “อะแฮ่ม [COUGH] จริงๆ แล้วเป็นวันที่ 17 เมษายน *2017*”

ว้าว!

แต่มีคนคิดออกเมื่อวันที่ 17 กรกฎาคม [2022] และ Slack ได้แก้ไขในวันเดียวกัน

แบบว่า “โอ้ ไอ้บ้า เรากำลังคิดอะไรอยู่!”

นั่นคือข่าวร้าย

ข่าวดีก็คือ อย่างน้อยก็คือ *แฮช* รหัสผ่าน

และพวกเขาไม่ได้ถูกแฮชเท่านั้น แต่ถูก *ใส่เกลือ* ซึ่งเป็นที่ที่คุณผสมข้อมูลสุ่มต่อผู้ใช้แต่ละรายที่คัดเลือกมาโดยเฉพาะด้วยรหัสผ่าน

ความคิดนี้เป็นสองเท่า

หนึ่ง ถ้าสองคนเลือกรหัสผ่านเดียวกัน พวกเขาจะไม่ได้รับแฮชเดียวกัน ดังนั้นคุณจึงไม่สามารถอนุมานได้โดยดูจากฐานข้อมูลแฮช

และสอง คุณไม่สามารถคำนวณพจนานุกรมของแฮชที่รู้จักล่วงหน้าสำหรับอินพุตที่รู้จักได้ เนื่องจากคุณต้องสร้างพจนานุกรมแยกต่างหากสำหรับรหัสผ่านแต่ละอัน *สำหรับเกลือแต่ละอัน*

ดังนั้นจึงไม่ใช่เรื่องง่ายในการถอดรหัสรหัสผ่านที่แฮช

ต้องบอกว่าแนวคิดทั้งหมดคือพวกเขาไม่ควรเป็นเรื่องของบันทึกสาธารณะ

พวกเขากำลังแฮชและเค็ม * ในกรณี * พวกเขารั่วไม่ใช่ * เพื่อให้พวกเขาสามารถ * รั่วได้

ดังนั้นไข่บนใบหน้าของ Slack!

Slack กล่าวว่าผู้ใช้ประมาณหนึ่งใน 200 หรือ 0.5% ได้รับผลกระทบ

แต่ถ้าคุณเป็นผู้ใช้ Slack ฉันจะถือว่าถ้าพวกเขาไม่รู้ว่าพวกเขารั่วไหลรหัสผ่านที่แฮชมาเป็นเวลาห้าปี บางทีพวกเขาอาจจะไม่ได้ระบุรายชื่อผู้ที่ได้รับผลกระทบทั้งหมดเช่นกัน

ดังนั้นไปและเปลี่ยนรหัสผ่านของคุณต่อไป… คุณก็เช่นกัน

---

ดั๊ก.  ตกลง เรายังกล่าวอีกว่า: หากคุณไม่ได้ใช้ตัวจัดการรหัสผ่าน ให้พิจารณาใช้ และเปิด 2FA ถ้าทำได้

---

เป็ด.  ฉันคิดว่าคุณต้องการอย่างนั้น ดั๊ก

---

ดั๊ก.  ใช่ฉันทำ!

แล้วถ้าคุณเป็น Slack หรือบริษัทที่ชอบ ให้เลือก a อัลกอริธึมเกลือแฮชและยืดที่มีชื่อเสียง เมื่อจัดการรหัสผ่านด้วยตัวเอง

---

เป็ด.  ใช่.

เรื่องใหญ่ในการตอบสนองของ Slack และสิ่งที่ฉันคิดว่ายังขาดอยู่คือพวกเขาเพิ่งพูดว่า "อย่ากังวล ไม่เพียงแต่เราแฮชรหัสผ่านเท่านั้น เรายังเพิ่มข้อมูลให้อีกด้วย"

คำแนะนำของฉันคือถ้าคุณถูกจับได้ว่ามีการละเมิดเช่นนี้ คุณควรยินดีที่จะประกาศอัลกอริทึมหรือกระบวนการที่คุณใช้สำหรับการเกลือและการแฮช รวมถึงสิ่งที่เรียกว่า การยืดซึ่งเป็นที่ที่คุณไม่แฮชรหัสผ่านเพียงครั้งเดียว แต่บางทีคุณอาจแฮชมัน 100,000 ครั้งเพื่อชะลอการใช้พจนานุกรมหรือการโจมตีแบบเดรัจฉาน

และถ้าคุณระบุว่าคุณใช้อัลกอริธึมใดและพารามิเตอร์ใด.. เช่น PBKDF2, bcrypt, scrypt, Argon2 – นี่คืออัลกอริธึม "salt-hash-stretch" ของรหัสผ่านที่รู้จักกันดีที่สุด

หากคุณระบุจริง ๆ ว่าคุณกำลังใช้อัลกอริธึมใดอยู่ ดังนั้น: [A] คุณเปิดกว้างมากขึ้น และ [B] คุณให้โอกาสผู้ที่ตกเป็นเหยื่อของปัญหาประเมินด้วยตนเองว่าพวกเขาคิดว่ามันอันตรายแค่ไหน .

และการเปิดกว้างแบบนั้นสามารถช่วยได้มากจริงๆ

Slack ไม่ได้ทำอย่างนั้น

พวกเขาแค่พูดว่า “โอ้ พวกเขาเค็มและแฮชแล้ว”

แต่สิ่งที่เราไม่รู้คือ พวกเขาใส่เกลือสองไบต์แล้วแฮชครั้งเดียวด้วย SHA-1...

…หรือว่าพวกมันมีบางอย่างที่ต้านทานการแตกได้มากกว่านี้ไหม?

---

ดั๊ก.  ติดหัวข้อเรื่องแย่ๆ เราสังเกตเห็นกระแสที่กำลังพัฒนาในที่ที่คนอยู่ ฉีดสิ่งไม่ดีลงใน GitHub,เพียงดูว่าเกิดอะไรขึ้นเผยความเสี่ยง...

…เรามีเรื่องราวเหล่านั้นอีกเรื่องหนึ่ง

---

เป็ด.  ใช่ ใครบางคนที่ถูกกล่าวหาว่าออกมาบน Twitter และกล่าวว่า “อย่ากังวลไปเลย ทุกคน ไม่ได้ทำอันตรายอะไร มันเป็นเพียงเพื่อการวิจัย ฉันจะเขียนรายงานให้โดดเด่นจาก Blue Alert”

พวกเขาสร้างโปรเจ็กต์ GitHub ปลอมนับพันตัว โดยอิงจากการคัดลอกโค้ดที่ถูกต้องตามกฎหมายที่มีอยู่ โดยจงใจแทรกคำสั่งมัลแวร์บางอย่างในนั้น เช่น "โทรกลับบ้านเพื่อขอคำแนะนำเพิ่มเติม" และ "ตีความเนื้อหาของคำตอบเป็นโค้ดลับๆ เพื่อดำเนินการ" และ เร็วๆ นี้.

ดังนั้น สิ่งที่อาจทำอันตรายได้จริงๆ หากคุณติดตั้งหนึ่งในแพ็คเกจเหล่านี้

ให้ชื่อที่ดูถูกกฎหมายแก่พวกเขา...

…เห็นได้ชัดว่าการยืมประวัติความมุ่งมั่นของโครงการของแท้เพื่อให้สิ่งนั้นดูถูกกฎหมายมากกว่าที่คุณคาดหวังหากเพิ่งปรากฏขึ้นด้วย "เฮ้ดาวน์โหลดไฟล์นี้ คุณก็รู้ว่าคุณต้องการ!”

จริงๆ?! การวิจัย?? นี่เราไม่รู้หรือไง!!?

ตอนนี้คุณสามารถโต้เถียงว่า "ก็ Microsoft ซึ่งเป็นเจ้าของ GitHub พวกเขากำลังทำอะไรอยู่ที่ทำให้ผู้คนอัปโหลดเนื้อหาประเภทนี้ได้ง่าย"

และมีความจริงบางอย่างในเรื่องนี้

บางทีพวกเขาอาจทำงานได้ดีกว่าในการป้องกันมัลแวร์ตั้งแต่แรก

แต่การพูดเกินจริงไปหน่อยว่า "โอ้ ทั้งหมดเป็นความผิดของ Microsoft"

ความคิดของฉันมันแย่ยิ่งกว่าเดิมที่จะพูดว่า “ใช่ นี่เป็นงานวิจัยที่แท้จริง สิ่งนี้สำคัญมาก เราต้องเตือนผู้คนว่าสิ่งนี้อาจเกิดขึ้นได้”

[A] เรารู้แล้วว่า ขอบคุณมาก เพราะคนจำนวนมากเคยทำสิ่งนี้มาก่อน เราได้รับข้อความดังและชัดเจน

และ [B] นี่ *ไม่ใช่* การวิจัย

นี่เป็นการจงใจพยายามหลอกล่อให้ผู้คนดาวน์โหลดโค้ดที่ให้การควบคุมระยะไกลสำหรับผู้โจมตี แลกกับความสามารถในการเขียนรายงาน

ฟังดูเหมือนเป็น "ข้อแก้ตัวที่ยิ่งใหญ่" สำหรับฉันมากกว่าแรงจูงใจที่ถูกต้องสำหรับการวิจัย

ดังนั้น คำแนะนำของฉันคือ ถ้าคุณคิดว่านี่เป็นงานวิจัย และถ้าคุณตั้งใจจะทำอะไรแบบนี้ซ้ำแล้วซ้ำเล่า *อย่าคาดหวังความเห็นอกเห็นใจมากนัก* ถ้าคุณถูกจับได้

---

ดั๊ก.  เอาล่ะ – เราจะกลับมาที่สิ่งนี้และความคิดเห็นของผู้อ่านในตอนท้ายของการแสดง ดังนั้นจงอยู่นิ่งๆ

แต่ก่อนอื่นให้เราพูดถึง ไฟจราจรและสิ่งที่พวกเขาเกี่ยวข้องกับความปลอดภัยทางไซเบอร์

---

เป็ด.  อ่าใช่! [หัวเราะ]

มีสิ่งที่เรียกว่า TLP, the โปรโตคอลสัญญาณไฟจราจร.

และ TLP คือสิ่งที่คุณอาจเรียกว่า "โปรโตคอลการวิจัยความปลอดภัยทางไซเบอร์ของมนุษย์" ที่ช่วยให้คุณติดป้ายกำกับเอกสารที่คุณส่งให้ผู้อื่น เพื่อบอกใบ้ว่าคุณคาดหวังอะไรจากพวกเขา (และที่สำคัญกว่านั้นคือสิ่งที่คุณหวังว่าพวกเขาจะทำ* ไม่*) ทำกับข้อมูล

โดยเฉพาะอย่างยิ่งพวกเขาควรจะแจกจ่ายซ้ำอย่างกว้างขวางเพียงใด?

นี่เป็นสิ่งที่สำคัญมากจนคุณสามารถประกาศให้โลกรู้ได้หรือไม่?

หรือสิ่งนี้อาจเป็นอันตราย หรืออาจมีบางสิ่งที่เราไม่ต้องการเปิดเผยต่อสาธารณะ… ดังนั้นเก็บไว้เป็นความลับ?

และเริ่มด้วย: TLP:REDซึ่งหมายความว่า "เก็บไว้กับตัว"; TLP:AMBERซึ่งหมายความว่า "คุณสามารถเผยแพร่ภายในบริษัทของคุณเองหรือให้กับลูกค้าของคุณที่คุณคิดว่าอาจจำเป็นต้องรู้เรื่องนี้อย่างเร่งด่วน"; TLP:GREENซึ่งหมายความว่า “ตกลง คุณสามารถปล่อยให้สิ่งนี้แพร่กระจายอย่างกว้างขวางภายในชุมชนความปลอดภัยทางไซเบอร์”

และ TLP:WHITEซึ่งหมายความว่า "คุณสามารถบอกใครก็ได้"

มีประโยชน์มาก ง่ายมาก: RED, AMBER, GREEN… คำอุปมาที่ใช้งานได้ทั่วโลกโดยไม่ต้องกังวลว่า "ความลับ" และ "ความลับ" ต่างกันอย่างไรและอะไรคือความแตกต่างระหว่าง "ความลับ" และ "จำแนก" ทุกสิ่งที่ซับซ้อนนั้น ต้องการกฎหมายจำนวนมากรอบตัว

TLP เพิ่งมีการปรับเปลี่ยนบางอย่าง

ดังนั้น หากคุณสนใจในการวิจัยความปลอดภัยทางไซเบอร์ ให้แน่ใจว่าคุณทราบข้อมูลเหล่านั้น

TLP:WHITE ถูกเปลี่ยนเป็นคำที่ผมว่าดีกว่ามากจริงๆ เพราะ ขาว มีหวือหวาทางวัฒนธรรมที่ไม่จำเป็นทั้งหมดที่เราสามารถทำได้โดยไม่ต้องในยุคสมัยใหม่

ดังนั้น TLP:WHITE เพิ่งกลายเป็น TLP:CLEARซึ่งในความคิดของฉันเป็นคำที่ดีกว่ามากเพราะมันบอกว่า "คุณชัดเจนที่จะใช้ข้อมูลนี้" และความตั้งใจนั้นก็ระบุไว้ อะแฮ่ม ชัดเจนมาก (ขออภัยฉันไม่สามารถต้านทานการเล่นสำนวน)

และยังมีเลเยอร์เพิ่มเติม (ซึ่งทำให้อุปมาเสียไปเล็กน้อย ตอนนี้เป็นสัญญาณไฟจราจรสี *ห้า*-สี!)

มีระดับพิเศษที่เรียกว่า TLP:AMBER+STRICTและความหมายก็คือ “คุณสามารถแบ่งปันสิ่งนี้ภายในบริษัทของคุณได้”

ดังนั้น คุณอาจได้รับเชิญให้เข้าร่วมการประชุม หรือบางทีคุณอาจทำงานให้กับบริษัทรักษาความปลอดภัยทางไซเบอร์ และค่อนข้างชัดเจนว่าคุณจะต้องแสดงสิ่งนี้ต่อโปรแกรมเมอร์ บางทีให้ทีมไอทีของคุณ หรืออาจจะให้เจ้าหน้าที่ประกันคุณภาพของคุณทราบ เพื่อที่คุณจะได้ค้นคว้าเกี่ยวกับ ปัญหาหรือจัดการกับการแก้ไข

แต่ TLP:AMBER+STRICT หมายความว่าถึงแม้คุณสามารถแพร่ระบาดในองค์กรของคุณได้ *โปรดอย่าบอกลูกค้าหรือลูกค้าของคุณ* หรือแม้แต่คนนอกบริษัทที่คุณคิดว่าอาจจำเป็นต้องรู้

เก็บไว้ในชุมชนที่แน่นแฟ้นยิ่งขึ้นเพื่อเริ่มต้น

TLP:AMBERเหมือนเมื่อก่อนหมายความว่า "โอเค ถ้าคุณรู้สึกว่าจำเป็นต้องบอกลูกค้า คุณก็ทำได้"

และนั่นอาจเป็นเรื่องสำคัญ เพราะบางครั้งคุณอาจต้องการแจ้งให้ลูกค้าของคุณทราบ "เฮ้ เรามีวิธีแก้ไขกำลังมา คุณจะต้องใช้ขั้นตอนป้องกันไว้ก่อนที่การแก้ไขจะมาถึง แต่เนื่องจากมันเป็นเรื่องละเอียดอ่อน เราขอถามคุณว่าอย่าเพิ่งบอกโลกนี้ได้ไหม”

บางครั้ง การบอกโลกเร็วเกินไปจริง ๆ แล้วเล่นในมือของโจรมากกว่าที่จะเล่นในมือของผู้พิทักษ์

ดังนั้น หากคุณเป็นผู้ตอบกลับด้านความปลอดภัยทางไซเบอร์ เราขอแนะนำให้คุณไป: https://www.first.org/tlp

---

ดั๊ก.  และคุณสามารถ อ่านเพิ่มเติมเกี่ยวกับเรื่องนั้น บนเว็บไซต์ของเรา Nakedsecurity.sophos.com.

และหากคุณกำลังมองหาการอ่านแบบละเอียดอื่นๆ ลืมการเข้ารหัสควอนตัมไปได้เลย… เรากำลังพูดถึง การเข้ารหัสหลังควอนตัม, พอล!

---

เป็ด.  ใช่ เราเคยพูดถึงเรื่องนี้สองสามครั้งก่อนหน้านี้ในพอดคาสต์ใช่ไหม

แนวคิดของคอมพิวเตอร์ควอนตัม สมมติว่ามีคอมพิวเตอร์ที่ทรงพลังและน่าเชื่อถือเพียงพอ ก็คือว่าอัลกอริธึมบางประเภทสามารถเร่งความเร็วให้ทันสมัยในปัจจุบัน ไม่ว่าจะเป็นการปรับแต่งรากที่สอง… หรือแย่กว่านั้น *ลอการิทึม* ของมาตราส่วนของปัญหาในปัจจุบัน

กล่าวอีกนัยหนึ่งแทนที่จะใช้2²⁵⁶ พยายามค้นหาไฟล์ที่มีแฮชเฉพาะ คุณอาจทำได้ในเวลาเพียง (“เพียง”!) 2¹²⁸ พยายาม ซึ่งเป็นรากที่สอง

เร็วขึ้นอย่างเห็นได้ชัด

แต่มีปัญหาทั้งชั้นที่เกี่ยวข้องกับผลคูณของจำนวนเฉพาะที่ทฤษฎีบอกว่าสามารถถอดรหัสได้ใน *ลอการิทึม* ของเวลาที่พวกเขาใช้ในวันนี้

ดังนั้น แทนที่จะรับ ให้พูดว่า 2¹²⁸ วันที่จะแตก [นานกว่ายุคปัจจุบันของจักรวาล] อาจใช้เวลาเพียง 128 วันในการถอดรหัส

หรือคุณสามารถแทนที่ "วัน" ด้วย "นาที" หรืออะไรก็ตาม

และน่าเสียดายที่อัลกอริธึมเวลาลอการิทึมนั้น (เรียกว่า อัลกอริทึมการแยกตัวประกอบควอนตัมของ Shor)… ตามทฤษฎีแล้ว มันสามารถนำไปใช้กับเทคนิคการเข้ารหัสบางอย่างในปัจจุบัน โดยเฉพาะเทคนิคที่ใช้สำหรับการเข้ารหัสคีย์สาธารณะ

และในกรณีที่อุปกรณ์คอมพิวเตอร์ควอนตัมเหล่านี้มีความเป็นไปได้ในอีกไม่กี่ปีข้างหน้า บางทีเราควรเริ่มเตรียมการสำหรับอัลกอริธึมการเข้ารหัสซึ่งไม่เสี่ยงต่อการโจมตีทั้งสองประเภทโดยเฉพาะ?

โดยเฉพาะอย่างยิ่งลอการิทึมอันหนึ่ง เพราะมันเร่งความเร็วการโจมตีที่อาจเกิดขึ้นได้อย่างมากจนคีย์เข้ารหัสที่เราคิดว่า "ไม่มีใครคิดออก" ในตอนนี้อาจเปิดเผยได้ในภายหลัง

อย่างไรก็ตาม NIST, the สถาบันมาตรฐานและเทคโนโลยีแห่งชาติ ในสหรัฐอเมริกา เป็นเวลาหลายปีที่ได้ทำการแข่งขันเพื่อพยายามสร้างมาตรฐานอัลกอริธึมสาธารณะที่ไม่ได้รับการจดสิทธิบัตรและได้รับการตรวจสอบอย่างดี ซึ่งสามารถต้านทานคอมพิวเตอร์ควอนตัมมหัศจรรย์เหล่านี้ได้ หากมีปรากฏให้เห็น

และเมื่อเร็ว ๆ นี้พวกเขาเลือกอัลกอริธึมสี่แบบที่พวกเขาพร้อมที่จะสร้างมาตรฐานในตอนนี้

พวกเขามีชื่อเจ๋งๆ ดั๊ก ดังนั้นฉันต้องอ่าน: CRYSTALS-KYBER, CRYSTALS-DILITHIUM, FALCONและ SPHINCS+. [เสียงหัวเราะ]

ดังนั้นพวกเขาจึงมีชื่อเจ๋ง ๆ ถ้าไม่มีอะไรอื่น

แต่ในขณะเดียวกัน NIST ก็พบว่า "นั่นก็แค่สี่อัลกอริธึม สิ่งที่เราจะทำคือเราจะเลือกผู้สมัครรองที่มีศักยภาพอีกสี่คน และเราจะดูว่าคนเหล่านี้ควรผ่านหรือไม่”

ดังนั้นจึงมีอัลกอริธึมที่เป็นมาตรฐานอยู่สี่ชุด และอัลกอริธึมสี่ชุดที่อาจได้รับมาตรฐานในอนาคต

หรือมี* สี่ครั้งในวันที่ 5 กรกฎาคม พ.ศ. 2022 และหนึ่งในนั้นคือ SIKE, ย่อจาก การห่อหุ้มคีย์ไอโซเจนีเหนือเอกพจน์.

(เราต้องการพอดคาสต์หลายรายการเพื่ออธิบายไอโซเจนียีเอกพจน์ ดังนั้นเราจะไม่รบกวน [หัวเราะ])

แต่น่าเสียดายที่อันนี้ ซึ่งแขวนอยู่ที่นั่นและมีโอกาสต่อสู้ที่จะได้มาตรฐาน ดูเหมือนว่ามันพังไปแล้วที่แก้ไขไม่ได้ แม้จะเปิดให้มีการตรวจสอบโดยสาธารณะแล้วอย่างน้อยห้าปี

โชคดีที่ก่อนที่มันจะได้รับหรือสามารถได้รับมาตรฐาน นักเข้ารหัสชาวเบลเยียมสองคนก็พบว่า “คุณรู้อะไรไหม? เราคิดว่าเรามีวิธีแก้ไขโดยใช้การคำนวณที่ใช้เวลาประมาณหนึ่งชั่วโมง บน CPU โดยเฉลี่ยที่ค่อนข้างธรรมดา โดยใช้เพียงแกนเดียว”

---

ดั๊ก.  ฉันเดาว่ามันดีกว่าที่จะค้นหาตอนนี้ ดีกว่าหลังจากสร้างมาตรฐานและนำมันออกไปในป่า?

---

เป็ด.  แน่นอน!

ฉันเดาว่าถ้ามันเป็นหนึ่งในอัลกอริธึมที่ได้มาตรฐานแล้ว พวกเขาจะต้องยกเลิกมาตรฐานแล้วสร้างใหม่เหรอ?

มันดูแปลกที่สิ่งนี้ไม่ได้รับการสังเกตเป็นเวลาห้าปี

แต่ฉันเดาว่านั่นคือความคิดทั้งหมดเกี่ยวกับการพิจารณาอย่างถี่ถ้วนในที่สาธารณะ คุณไม่มีทางรู้หรอกว่าเมื่อไรอาจมีคนแตะต้องรอยแตกที่จำเป็น หรือลิ่มเล็กๆ ที่พวกเขาสามารถใช้เจาะเข้าไปและพิสูจน์ว่าอัลกอริทึมนั้นไม่แข็งแรงอย่างที่คิดไว้ในตอนแรก

เป็นเครื่องเตือนใจที่ดีว่าถ้าคุณ *เคย* คิดที่จะถักนิตติ้งการเข้ารหัสของคุณเอง...

---

ดั๊ก.  [หัวเราะ] ฉันไม่ได้!

---

เป็ด.  ..ทั้งๆ ที่เราเคยบอกคุณในพอดแคสต์ Naked Security N ครั้งว่า “อย่าทำอย่างนั้น!”

นี่ควรเป็นเครื่องเตือนใจขั้นสูงสุดว่า แม้ว่าผู้เชี่ยวชาญที่แท้จริงจะวางอัลกอริทึมที่อยู่ภายใต้การพิจารณาของสาธารณชนในการแข่งขันระดับโลกเป็นเวลาห้าปี แต่ก็ยังไม่จำเป็นต้องให้เวลาเพียงพอในการเปิดเผยข้อบกพร่องที่กลายเป็นว่าเลวร้ายทีเดียว

มันดูไม่ดีสำหรับสิ่งนี้อย่างแน่นอน SIKE ขั้นตอนวิธี

และใครจะรู้บางทีมันอาจจะถูกถอนออก?

---

ดั๊ก.  เราจะจับตาดูสิ่งนั้น

และในขณะที่พระอาทิตย์ตกดินในรายการของเราในสัปดาห์นี้อย่างช้าๆ ก็ถึงเวลาที่จะได้ยินจากผู้อ่านคนหนึ่งของเราเกี่ยวกับเรื่องราวของ GitHub ที่เราได้พูดคุยกันก่อนหน้านี้

ปล้น เขียน:

“ความคิดเห็นมีชอล์กและชีสอยู่บ้าง และฉันไม่อยากพูดเลย แต่ฉันเห็นการโต้เถียงทั้งสองฝ่ายจริงๆ เป็นอันตราย ลำบาก เสียเวลา และสิ้นเปลืองทรัพยากรหรือไม่? ใช่แน่นอนมันเป็น มันเป็นสิ่งที่ประเภทที่คิดร้ายจะทำ? ใช่ใช่มันเป็น เป็นเครื่องเตือนใจสำหรับทุกคนที่ใช้ GitHub หรือระบบที่เก็บรหัสอื่น ๆ สำหรับเรื่องนั้นหรือไม่ว่าการเดินทางอินเทอร์เน็ตอย่างปลอดภัยนั้นต้องใช้ความเห็นถากถางดูถูกและความหวาดระแวงในระดับที่ดีต่อสุขภาพ? ใช่. ในฐานะผู้ดูแลระบบ ส่วนหนึ่งของฉันต้องการปรบมือให้กับความเสี่ยงที่อยู่ในมือ ในฐานะผู้ดูแลระบบของนักพัฒนาจำนวนมาก ตอนนี้ฉันต้องตรวจสอบให้แน่ใจว่าทุกคนได้ค้นหารายการที่น่าสงสัยเมื่อเร็วๆ นี้”

---

เป็ด.  ใช่ ขอบคุณ RobB สำหรับความคิดเห็นนั้น เพราะฉันเดาว่ามันสำคัญที่จะเห็นการโต้แย้งทั้งสองฝ่าย

มีผู้แสดงความคิดเห็นที่พูดว่า “มันมีปัญหาอะไรกับเรื่องนี้? มันเยี่ยมมาก!”

คนหนึ่งกล่าวว่า “ไม่ จริงๆ แล้ว การทดสอบปากกานี้ดีและมีประโยชน์ ดีใจที่สิ่งเหล่านี้ถูกเปิดเผยแทนที่จะเลี้ยงดูหัวที่น่าเกลียดจากผู้โจมตีที่แท้จริง”

และการตอบสนองของฉันต่อสิ่งนั้นคือ “จริงๆ แล้ว *เป็น* เป็นการโจมตี”

เป็นเพียงว่ามีคนออกมาหลังจากนั้นและพูดว่า "โอ้ ไม่ ไม่ ไม่เสียหาย! สุจริตฉันไม่ได้ซน”

ฉันไม่คิดว่าคุณต้องซื้อข้อแก้ตัวนั้น!

แต่อย่างไรก็ตาม นี่ไม่ใช่การทดสอบการเจาะระบบ

คำตอบของฉันคือพูดง่าย ๆ : “ผู้ทดสอบการเจาะที่มีความรับผิดชอบจะกระทำการ [A] หลังจากได้รับอนุญาตอย่างชัดแจ้งเท่านั้น และ [B] ภายในขอบเขตพฤติกรรมที่ตกลงกันไว้ล่วงหน้าอย่างชัดเจน”

คุณไม่เพียงแค่สร้างกฎของคุณเอง และเราได้พูดคุยเรื่องนี้มาก่อนแล้ว

ดังที่ผู้แสดงความคิดเห็นคนอื่นพูด ซึ่งก็คือ ฉันคิดว่า ความคิดเห็นที่ฉันชอบ... Ecurb กล่าวว่า, “ฉันคิดว่าใครบางคนควรเดินไปตามบ้านและทุบหน้าต่างเพื่อแสดงให้เห็นว่าตัวล็อคประตูไม่ได้ผลจริงๆ นี่พ้นกำหนดแล้ว มีคนกระโดดขึ้นไปบนนี้โปรด”

แล้วในกรณีที่คุณไม่รู้ว่านั่นเป็นการเสียดสี คนอื่นๆ เขาพูดว่า "ไม่!"

---

เป็ด.  ฉันได้รับแนวคิดว่าเป็นเครื่องเตือนใจที่ดี และฉันก็มีความคิดว่าหากคุณเป็นผู้ใช้ GitHub ทั้งในฐานะผู้ผลิตและผู้บริโภค มีหลายสิ่งที่คุณทำได้

เราแสดงรายการไว้ในความคิดเห็นและในบทความ

ตัวอย่างเช่น ใส่ลายเซ็นดิจิทัลบนคอมมิตทั้งหมดของคุณ เพื่อให้ชัดเจนว่าการเปลี่ยนแปลงมาจากคุณ และสามารถตรวจสอบย้อนกลับได้

และอย่ากินของอย่างสุ่มสี่สุ่มห้าเพราะคุณค้นหาแล้ว "ดูเหมือน" อาจเป็นโครงการที่เหมาะสม

ใช่ เราทุกคนสามารถเรียนรู้จากสิ่งนี้ได้ แต่สิ่งนี้นับเป็นการสอนเราจริง ๆ หรือเป็นเพียงสิ่งที่เราควรเรียนรู้อยู่แล้ว?

ฉันคิดว่านี่คือ *ไม่ใช่* การสอน

เป็นเพียง *ไม่สูงพอที่จะนับเป็นการวิจัย*

---

ดั๊ก.  การสนทนาที่ยอดเยี่ยมเกี่ยวกับบทความนี้ และขอขอบคุณที่ส่งมาให้ Rob

หากคุณมีเรื่องราว ข้อคิดเห็น หรือคำถามที่น่าสนใจที่คุณต้องการส่ง เรายินดีที่จะอ่านในพอดแคสต์

คุณสามารถส่งอีเมล tips@sophos.com; คุณสามารถแสดงความคิดเห็นในบทความของเราได้ หรือคุณสามารถติดต่อเราบนโซเชียล: @NakedSecurity.

นั่นคือการแสดงของเราในวันนี้ ขอบคุณมากสำหรับการฟัง

สำหรับ Paul Ducklin ฉัน Doug Aamoth เตือนคุณจนถึงครั้งต่อไป ให้...

---

ทั้งสอง  รักษาความปลอดภัย!

[โมเด็มดนตรี]