filippo.io/mlkem768: การเข้ารหัสทนทานต่อควอนตัมสำหรับระบบนิเวศ Go

 (words.filippo.io)
1 คะแนน โดย GN⁺ 2024-02-02 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • filippo.io/mlkem768 คือการอิมพลีเมนต์ ML-KEM-768 แบบ pure Go ซึ่งกำลังอยู่ในกระบวนการทำให้เป็นมาตรฐานของ NIST ทำให้สามารถพิจารณาการแลกเปลี่ยนกุญแจที่ทนทานต่อควอนตัมในระบบนิเวศ Go ได้
  • ประกอบด้วยโค้ดประมาณ 500 บรรทัด, คอมเมนต์ 200 บรรทัด, และเทสต์ 650 บรรทัด โดยไม่มี dependency นอกจาก golang.org/x/crypto/sha3 จึงอยู่ในรูปแบบที่นำเข้าไปเป็นแพ็กเกจภายในของไลบรารีมาตรฐาน Go ได้ง่าย
  • ไม่ได้พอร์ต reference implementation ของ pq-crystals แต่เขียนตาม สเปก FIPS 203 โดยตรง เพื่อพิสูจน์ว่าสามารถสร้าง implementation ที่ทำงานร่วมกันได้จากสเปกเพียงอย่างเดียวหรือไม่
  • ส่วนที่ยากที่สุดคือ การบีบอัด·คลายบีบอัดและการทำงานแบบเวลาคงที่ โดยใช้ Barrett reduction เพื่อหลีกเลี่ยงความเสี่ยงจากคำสั่ง DIV แบบเวลาผันแปรที่อาจเกิดในสาย reference implementation
  • แม้การปรับจูนประสิทธิภาพจะไม่ใช่เป้าหมายหลัก แต่เส้นทางของ Bob มีความเร็วใกล้เคียงกับ X25519·P-256 ของ Go และเส้นทางของ Alice ก็ช้ากว่าไม่ถึง 2 เท่า แสดงให้เห็นว่าแม้เป็น implementation ที่เรียบง่ายก็ยังเร็วพอใช้งานจริงได้

การอิมพลีเมนต์ ML-KEM-768 แบบ pure Go

  • filippo.io/mlkem768 เป็นการอิมพลีเมนต์ ML-KEM-768 แบบ pure Go โดยให้ความสำคัญกับความถูกต้องและความอ่านง่ายเป็นอันดับแรก
  • ML-KEM เดิมรู้จักกันในชื่อ Kyber และเป็น กลไกการแลกเปลี่ยนกุญแจที่ทนทานต่อควอนตัม ซึ่งอยู่ระหว่างกระบวนการทำมาตรฐานของ NIST
  • แพ็กเกจนี้ประกอบด้วย โค้ดประมาณ 500 บรรทัด, คอมเมนต์ 200 บรรทัด และเทสต์ 650 บรรทัด
  • dependency มีเพียง golang.org/x/crypto/sha3 เท่านั้น
  • เป้าหมายคือการ upstream เข้าไปในไลบรารีมาตรฐาน Go และในช่วงแรกวางแผนให้เป็นแพ็กเกจภายในสำหรับใช้งานเฉพาะในทดลอง crypto/tls แบบ opt-in

แนวทางอิมพลีเมนต์ที่ยึดตาม FIPS 203 ตรง ๆ

  • การอิมพลีเมนต์นี้ไม่ได้พอร์ต reference library ของ pq-crystals แต่เขียนขึ้นใหม่ทั้งหมดตั้งแต่ต้น โดยไม่ได้อ่านโค้ดเบสอื่นอย่างละเอียด
  • เป้าหมายหลักคือการตรวจสอบว่าสามารถสร้าง implementation ที่ทำงานร่วมกันได้จาก สเปกเพียงอย่างเดียว หรือไม่
  • เอกสาร FIPS 203 ให้ทั้ง pseudocode ที่ละเอียด นิยามที่ครบถ้วน และข้อมูลชนิดข้อมูลที่สอดคล้องกัน จึงเหมาะเป็นคู่มือสำหรับการอิมพลีเมนต์
  • ชื่อฟังก์ชัน ชื่อตัวแปร และลำดับการคำนวณสะท้อนสเปก FIPS ให้มากที่สุด เพื่อให้ง่ายต่อการรีวิวและการเรียนรู้
  • พื้นฐานคณิตศาสตร์ที่จำเป็นต่อการอิมพลีเมนต์ ML-KEM ถูกรวบรวมแยกไว้ใน Enough Polynomials and Linear Algebra to Implement Kyber

การบีบอัด·คลายบีบอัดและการอิมพลีเมนต์แบบเวลาคงที่

  • งานอิมพลีเมนต์หลักที่เหลือมีอยู่สามข้อ
    • การอิมพลีเมนต์ modular arithmetic บนจำนวนเฉพาะ 3329
    • การอิมพลีเมนต์ฟังก์ชันบีบอัด·คลายบีบอัดที่แมปค่า [0, 3329) ไปยัง [0, 2ᵈ) และย้อนกลับ
    • การรับประกัน การทำงานแบบเวลาคงที่
  • modular arithmetic ทำได้ค่อนข้างง่าย เพราะมีประสบการณ์สะสมจากการอิมพลีเมนต์ RSA และ elliptic curve และจำนวนเฉพาะที่เล็กก็ช่วยให้โค้ดเรียบง่ายขึ้น
  • การบีบอัดและคลายบีบอัด เป็นส่วนที่ยากที่สุด
    • ในสเปกถูกนิยามแบบนามธรรมด้วยเศษส่วนและกฎการปัดเศษ
    • แต่การอิมพลีเมนต์จริงต้องทำด้วย arithmetic แบบเวลาคงที่และการดำเนินการระดับบิต
  • reference implementation และพอร์ตจำนวนมากใช้การหาร ซึ่งอาจกลายเป็นคำสั่ง DIV แบบเวลาผันแปร ได้ ขึ้นอยู่กับการ optimize ของคอมไพเลอร์และแพลตฟอร์ม
  • แพ็กเกจนี้ใช้ Barrett reduction มาตั้งแต่ต้นจึงไม่ได้รับผลกระทบ และ BoringSSL ก็ใช้แนวทางเดียวกัน

เหตุผลที่โฟกัสเฉพาะ ML-KEM-768

  • การอิมพลีเมนต์นี้รองรับเฉพาะ ML-KEM-768 จากสามระดับความปลอดภัยของ ML-KEM ได้แก่ -512, -768, -1024
  • ทีม Kyber แนะนำให้ใช้ -768 มากกว่า -512 เพื่อมี security margin ที่อนุรักษ์นิยมมากขึ้นต่อการวิเคราะห์การเข้ารหัสแบบใหม่
  • -1024 ถูกอธิบายว่าเป็นตัวเลือกสำหรับระดับความปลอดภัย 256 บิต ด้วยเหตุผลเดียวกับการปฏิบัติตามข้อกำหนดและการจับคู่ระดับความแข็งแกร่ง
  • เนื่องจากโปรโตคอลส่วนใหญ่ที่อยู่ระหว่างการทดลองหรือมาตรฐานต่างมารวมที่ ML-KEM-768 แล้ว การเจาะจงเพียงระดับเดียวแทบไม่เพิ่มต้นทุน
  • การโฟกัสที่เป้าหมายเดียวช่วยลดส่วนที่เคลื่อนไหวได้ จึงเป็นผลดีต่อ ความอ่านง่าย ความปลอดภัย และประสิทธิภาพ
    • ตัวอย่างเช่น การซีเรียลไลซ์จำนวนเต็ม 1·4·10·12 บิต ไม่ได้ใช้ generic encoder ตัวเดียว แต่แยกเป็น encoder·decoder เฉพาะทาง
    • และเพราะรองรับเฉพาะ ML-KEM-768 จึงไม่จำเป็นต้องอิมพลีเมนต์การเข้ารหัส 5 บิตและ 11 บิต

กลยุทธ์การทดสอบและ public test vectors

  • การทดสอบเป็นแกนสำคัญอันดับถัดจากความอ่านง่ายในกลยุทธ์การรับประกันความปลอดภัยของแพ็กเกจนี้
  • การทดสอบพื้นฐานครอบคลุมการทำ roundtrip ของการสร้างกุญแจ การ encapsulation และ decapsulation รวมถึง test coverage มากกว่า 95%
  • ขอบเขตการทดสอบเพิ่มเติมมีดังนี้
    • ตรวจสอบการทำงานร่วมกันกับ test vectors ที่ได้จาก NIST และ implementation อื่น
    • เปรียบเทียบค่าที่คาดหวังจากการคำนวณแบบ variable-time สำหรับทุกชุดอินพุตของการบวก·ลบ·คูณโมดูลัส 3329
    • ทดสอบการบีบอัด·คลายบีบอัดแบบ exhaustive โดยอ้างอิง math/big.Rat
    • ตรวจสอบว่าค่าคงที่ที่ precompute ไว้สอดคล้องกับนิยาม
    • ตรวจสอบว่าฟังก์ชันทั้งหมดคืน error ที่เหมาะสมเมื่ออินพุตยาวหรือสั้นเกินไป
    • รัน test vectors ที่ Sophie Schmieg จัดเตรียมไว้และจะถูกนำไปรวมใน Wycheproof ในอนาคต
  • test vectors ที่สร้างขึ้นเองถูกเผยแพร่เป็นส่วนหนึ่งของ โปรเจกต์ CCTV เพื่อให้ implementation อื่นนำไปใช้ซ้ำได้
  • CCTV vectors มี ค่ากลาง ที่ช่วยให้ทดสอบและดีบักแต่ละขั้นตอนกลางและอัลกอริทึมย่อยได้

ข้อผิดพลาดที่ test vectors แบบพิเศษตรวจจับได้

  • Negative test vectors ให้กุญแจ encapsulation ที่ไม่ถูกต้องซึ่งมีสัมประสิทธิ์มากกว่า 3329
    • vectors จากทีม Kyber และ NIST เน้นอินพุตปกติเป็นหลัก จึงมีการร้องขอ vectors ลักษณะนี้บ่อยครั้ง
    • มีการทดสอบทุกค่าตั้งแต่ 3329 ถึง 2¹²-1 และทุกตำแหน่งของสัมประสิทธิ์แยกกัน
    • โดยใช้สัมประสิทธิ์ที่เหลือร่วมกัน เพื่อลดข้อมูลจาก 1–3MiB ลงเหลือ 12–28KiB
  • “Unlucky” vectors ใช้ทดสอบกรณีที่ต้องอ่าน XOF มากผิดปกติ
    • เป็นกุญแจสาธารณะที่ใน SampleNTT ต้องอ่านมากกว่า 575 ไบต์จาก SHAKE-128 XOF ซึ่งตามปกติเกิดด้วยความน่าจะเป็น 2⁻³⁸
    • vector ของ Sophie ถูก brute-force เพิ่มเติมจนต้องใช้มากสุด 591 ไบต์
  • strcmp vectors ทำให้ implementation ที่ใช้ strcmp() ใน ML-KEM.Decaps ล้มเหลว
    • ถ้ามีไบต์ศูนย์อยู่ระหว่างการเปรียบเทียบ ciphertext กับผลลัพธ์ของ K-PKE.Encrypt ในขั้น decapsulation, strcmp() อาจหยุดเปรียบเทียบก่อนเวลาอันควร
  • Accumulated vectors สร้างมาจาก reference implementation ของ pq-crystals
    • แทนที่จะเก็บเอาต์พุต random vectors ขนาด 300MB จะสร้างใหม่ระหว่างการทดสอบด้วย deterministic RNG แล้วเปรียบเทียบแฮชกับค่าที่คาดหวัง
    • ทำให้สามารถสร้างแฮชของการทดสอบแบบสุ่มได้ถึง 1 ล้านครั้ง ไม่ใช่แค่ 10k ครั้งของ reference implementation
  • ในเทสต์เพิ่มเติมหลายชุดที่เพิ่มเข้ามาภายหลัง ก็ยังไม่พบปัญหาใน filippo.io/mlkem768 และมีอย่างน้อย 1 กรณีรายงาน ที่ negative vector ตรวจพบข้อบกพร่องใน implementation หลัก

ผลลัพธ์ด้านประสิทธิภาพ

  • ประสิทธิภาพไม่ใช่เป้าหมายอันดับแรกของแพ็กเกจนี้หรือของแพ็กเกจเข้ารหัสใน Go แต่ก็ต้องเร็วพอที่จะใช้งานได้จริง
  • ML-KEM เร็วเพียงพอ และแม้ implementation แบบเรียบง่ายนี้ก็ยังแข่งขันได้กับ implementation ของ P-256 และ X25519 ใน Go ที่ optimize ด้วยแอสเซมบลี
  • การเปรียบเทียบควรอิงจากงานทั้งหมดที่แต่ละฝั่งต้องทำในการตั้งค่ากุญแจ
    • ECDH ต้องทำ scalar multiplication 2 ครั้ง รวมถึง fixed basepoint 1 ครั้ง
    • KEM ให้ฝั่งหนึ่งทำการสร้างกุญแจและ decapsulation ส่วนอีกฝั่งทำ encapsulation
    • ECDH มีความสมมาตร แต่การตั้งค่ากุญแจของ ML-KEM เป็นแบบอสมมาตร
  • ใน benchmark, “Alice” ทำการสร้างกุญแจและ decapsulation ส่วน “Bob” ทำ encapsulation
    • decapsulation มีการเข้ารหัสเต็มขั้นเพื่อยืนยันว่า ciphertext อินพุตตรงกับผลลัพธ์หรือไม่
    • Alice จึงใช้เวลานานกว่า Bob เพราะต้องทำทั้งการเข้ารหัส ถอดรหัส และสร้างกุญแจ
  • ผลลัพธ์คือ Bob เร็วพอ ๆ กับ X25519 หรือ P-256 ส่วน Alice ช้ากว่าไม่ถึง 2 เท่า
  • เมื่อเทียบกับ implementation ML-KEM ที่เร็วกว่าอย่าง BoringSSL และ libcrux แพ็กเกจนี้ใช้เวลาประมาณ 2 เท่า

ตัวเลข benchmark และช่องทางการ optimize

  • ค่าที่วัดได้มีดังนี้
    • บน macOS arm64, ECDH/P256-8 อยู่ที่ 49.43µs และ ECDH/X25519-8 อยู่ที่ 77.46µs
    • ในสภาพแวดล้อมเดียวกัน, RoundTrip/Alice-8 อยู่ที่ 109.4µs และ RoundTrip/Bob-8 อยู่ที่ 56.19µs
    • บน Linux amd64, ECDH/P256-4 อยู่ที่ 78.88µs และ ECDH/X25519-4 อยู่ที่ 115.6µs
    • ในสภาพแวดล้อมเดียวกัน, RoundTrip/Alice-4 อยู่ที่ 223.8µs และ RoundTrip/Bob-4 อยู่ที่ 114.7µs
  • การอิมพลีเมนต์นี้ใช้รูปแบบ Go สำหรับงานประสิทธิภาพสูง เช่น การลด heap allocation
  • มีการ ปรับโครงสร้าง x/crypto/sha3 เพื่อให้ใช้งานได้โดยไม่ต้อง heap allocate แต่บน Apple M2 กลับให้ผลลบ จึงยังไม่ได้ merge และไม่รวมอยู่ใน benchmark ด้านบน
  • ช่องทางในการ optimize ที่เหลือยังชัดเจน
    • เนื่องจากการสร้างกุญแจและ decapsulation สุ่มเมทริกซ์จากค่าเดียวกัน หากเก็บเมทริกซ์ไว้เมื่อ Alice ทำสองงานนี้ต่อเนื่องกัน จะช่วย ประหยัดเวลาได้ราว 10%
    • ยังมีโอกาสลดการคัดลอกในเส้นทางการอ่านของ sha3
    • หลังจากนั้นจะต้องไป optimize การอิมพลีเมนต์ field

รองรับ Kyber v3 ด้วยการอิมพลีเมนต์ ML-KEM

  • NIST ได้ทำการเปลี่ยนแปลงเล็กน้อยบางส่วนจากต้นฉบับส่ง Kyber Round 3 ซึ่งสรุปไว้ในหัวข้อ 1.3 ของร่าง FIPS
  • มีโปรโตคอลทดลองบางส่วนที่อิงกับ Kyber v3 หรือ “draft00” รวมถึงการแลกเปลี่ยนกุญแจ PQ TLS ที่มีการใช้งานจริงหลักด้วย
  • สามารถรองรับ Kyber v3 ได้ด้วยการอิมพลีเมนต์ ML-KEM โดยไม่ต้องมีแพ็กเกจแยก
  • หนึ่งในการเปลี่ยนแปลงคือการเพิ่มการตรวจสอบกรณียกเว้นของการเข้ารหัสสัมประสิทธิ์กุญแจสาธารณะแบบไม่ canonical
    • implementation ปกติจะไม่สร้างกุญแจลักษณะนั้นอยู่แล้ว จึงสามารถปฏิเสธได้ตามร่าง FIPS
    • พฤติกรรมนี้ทำให้ implementation แบบ Kyber-on-ML-KEM สามารถถูกแยกแยะได้ แต่ก็ไม่ได้ก่อผลเสียอื่น
  • การเปลี่ยนแปลงอีกข้อคือการเอาขั้นตอนแฮชที่เคยใช้กับอินพุต CSPRNG ออก
    • เนื่องจากไบต์อินพุตเป็นแบบสุ่มอยู่แล้ว จึงไม่มีฝ่ายใดแยกความแตกต่างได้
  • การเปลี่ยนแปลงที่ใหญ่ที่สุดคือพฤติกรรมที่แฮช ciphertext เข้าไปใน shared secret
    • ความต่างนี้อาจทำให้ไม่สามารถทำงานร่วมกันได้
    • หากสร้าง shared secret K ด้วย ML-KEM แล้วตามด้วย SHAKE-256(K || SHA3-256(c))[:32] ก็จะได้ shared secret ของ Kyber
    • โดยไม่จำเป็นต้องทำลาย abstraction ของ ML-KEM
  • ทั้ง Kyber และ ML-KEM ต่างแฮช secret และ ciphertext ในขั้น decapsulation เพื่อทำ implicit rejection
    • หากใช้การ derive กุญแจด้านบนทับบน ML-KEM ก็จะเท่ากับแฮช ciphertext สองครั้งในการทำ implicit rejection
    • แต่เอาต์พุตของ implicit rejection ถูกออกแบบมาให้คาดเดาไม่ได้และไม่ใช่สิ่งที่ต้องทำงานร่วมกันอยู่แล้ว จึงไม่ใช่ปัญหา

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2024-02-02
ความคิดเห็นบน Hacker News

  • จาก Kudelski Security ขอทักทายครับ เรื่องนี้มาทันเวลามาก เพราะเมื่อไม่นานมานี้เราจำเป็นต้องยุติไลบรารี การเข้ารหัสที่ทนทานต่อควอนตัม สำหรับ Go อีกตัวหนึ่งที่แทบจะเป็นตัวเลือกเดียวที่มีอยู่
    เรื่องราวทั้งหมดอยู่ที่ https://research.kudelskisecurity.com/2024/02/01/the-kybersl...

    • Kyber-512 ไม่ใช่ว่าถูก สมาชิกฝั่ง NSA ของ NIST ทำให้อ่อนลงโดยเจตนาหรอกหรือ?

  • สงสัยว่า ควอนตัมคอมพิวติ้ง ในความเป็นจริงไปถึงระดับไหนแล้ว ถึงขั้นต้องมีของแบบนี้
    มันกลายเป็นสถานการณ์ที่เปลี่ยนแค่นิยามเพื่อออกผลิตภัณฑ์ใหม่ภายใต้ชื่อเดิม มากกว่าจะมีอะไรเกิดขึ้นจริงเหมือน AI หรือเปล่า?

    • วิธีที่วิทยาการเข้ารหัสรับมือกับภัยคุกคามจากควอนตัมคอมพิวเตอร์ค่อนข้างพิเศษ เพราะข้อมูลและการเชื่อมต่อบางส่วนที่ถูกเข้ารหัสในวันนี้ต้องไม่สามารถถูกถอดรหัสได้แม้ผ่านไป 30 ปี หรือ 50 ปี
      ดังนั้นคำถามจึงไม่ใช่ “ควอนตัมคอมพิวเตอร์จะมาเร็ว ๆ นี้ไหม” แต่เป็น “ภายในครึ่งศตวรรษข้างหน้า ควอนตัมคอมพิวเตอร์มีโอกาสเกิดขึ้นอย่างสมเหตุสมผลไหม” แม้ยังไม่มีฉันทามติที่แม่นยำ แต่คำตอบก็ไม่ใช่ “ไม่” จึงเกิดกระแสแบบนี้ขึ้นตอนนี้
      นั่นทำให้เห็นความคืบหน้าในฝั่ง การแลกเปลี่ยนกุญแจแบบ PQC มากกว่าฝั่งลายเซ็น การตรวจสอบลายเซ็นในวันนี้จะไม่ได้รับผลกระทบจากควอนตัมคอมพิวเตอร์ในอีก 50 ปี แต่การเข้ารหัสจะได้รับผลกระทบ
    • นี่ไม่ใช่เรื่องการป้องกันควอนตัมคอมพิวเตอร์ในปัจจุบัน
      ความเสี่ยงคือผู้โจมตีสามารถ เก็บ ciphertext ของวันนี้ ไว้ แล้วถอดรหัสในอนาคตได้ ยิ่งย้ายไปใช้การเข้ารหัสที่ปลอดภัยต่อควอนตัมเร็วเท่าไร ก็ยิ่งเหลือ “ciphertext ค้างเก่า” ที่เสี่ยงต่อการโจมตีในอนาคตน้อยลงเท่านั้น
    • ถ้าคำตอบคือ “NSA ใช้การวิเคราะห์รหัสด้วยควอนตัมใน production อยู่แล้ว และควรมองว่า ECDH ถูกทำลายหมดแล้ว” คนที่รู้เรื่องนี้คงเดือดร้อนมหาศาลทันทีที่พูดออกมา
      ในความเป็นจริงโอกาสนั้นดูต่ำ แต่คำถามนี้ตอบได้ยากอยู่ระดับหนึ่ง ตอนนี้ยังไม่ใช่ภัยคุกคามที่เป็นที่รู้กัน แต่จะมองศักยภาพของมันอย่างหวาดระแวงแค่ไหนก็เป็นเรื่องเชิงอัตวิสัย
    • ในช่วงราว 2 ปีที่ผ่านมา NIST ได้กำหนด อัลกอริทึมการเข้ารหัสหลังยุคควอนตัม หลายตัว และหลังจากนั้น implementation ก็เพิ่มขึ้นเรื่อย ๆ ควอนตัมคอมพิวติ้งยังอีกไกล แต่ดูเหมือนเป็นท่าทีว่า “เริ่มตอนนี้ก็ไม่เสียหายอะไรนี่?”
      ไม่แน่ใจนัก แต่เดาว่า elliptic-curve cryptography ก็น่าจะมี implementation ค่อนข้างมากตั้งแต่ก่อนถูกใช้อย่างแพร่หลายมาก ๆ หากใครเคยผ่านยุคนั้นมาและผมเข้าใจผิด ช่วยแก้ให้ด้วย
    • ถ้าควอนตัมคอมพิวเตอร์จะทำลาย RSA-2048 คุณภาพของ physical qubit ในปัจจุบันต้องเพิ่มขึ้นประมาณ 10 เท่า และจำนวนต้องเพิ่มขึ้น 10,000 เท่า เป็นตัวเลขที่หยาบมาก
      หมุดหมายสำคัญถัดไปที่ควรจับตาคือ logical qubit ที่มี fidelity ดีกว่า physical qubit ที่ประกอบกันขึ้นมา 1000 เท่า ถ้าสิ่งนั้นออกมา ก็จะเป็นสัญญาณว่าคุณภาพของ physical qubit เพียงพอแล้ว และเหลือแค่เริ่มขยายจำนวน

  • สำหรับประเด็นที่เกี่ยวข้อง คู่มือเบื้องต้นเกี่ยวกับการ implement ระบบเข้ารหัสด้วย Go เวอร์ชันล่าสุดของ John Arundel อาจช่วยได้ ในส่วนท้ายมีพูดถึง การเข้ารหัสหลังยุคควอนตัม เล็กน้อย และเมื่อ NIST PQ ถูกทำให้เป็นมาตรฐานแล้ว ภายหลัง John อาจอัปเดตหนังสือโดยใส่ไลบรารีนี้เข้าไปด้วยก็ได้
    Explore Go: Cryptography (Go 1.22 edition):
    https://bitfieldconsulting.com/books/crypto

  • ถ้าผมเข้าใจผิดช่วยแก้ด้วย แต่ถ้าเขียนด้วย Go ล้วน ๆ มันจะไม่ทำให้เสี่ยงต่อ การโจมตี side-channel ด้าน timing/พลังงาน หรือ?

    • ยากที่จะบอกว่า Go เสี่ยงกว่า C และอาจจะน้อยกว่าด้วยซ้ำ ความต่างคือ Go มี compiler หลักตัวเดียวและโดยปกติไม่ได้ optimize หนักเกินไป ขณะที่ใน C ต้องใช้กลเม็ดที่ซับซ้อนขึ้นเรื่อย ๆ เพื่อไม่ให้ compiler มองเจตนาออกแล้วเปลี่ยนเป็น branch แบบ variable-time ที่มีประสิทธิภาพกว่า
      implementation นี้เขียนขึ้นเพื่อหลีกเลี่ยง code path ที่เปลี่ยนไปตามค่าลับ ส่วน power side-channel ที่ต้องมีการเข้าถึงทางกายภาพอยู่นอก threat model ของ Go
    • เขียนไว้ว่า “การดำเนินการหลักทั้งหมดทำแบบ constant time”
      น่าจะตามลิงก์ไปถึงเอกสารของโปรเจกต์ก่อน ดูเหมือนเขาพิจารณาประเด็นนี้ไว้แล้ว
    • มีภาษาไหนที่ immune ต่อการโจมตี power side-channel ด้วยหรือ? แนวคิดนั้นเองฟังดูไม่สมเหตุสมผล
      ส่วนเรื่อง timing attack ก็ไม่รู้ว่าอะไรทำให้ Go เสี่ยงต่อ timing side-channel มากกว่าภาษาอื่น

  • มีใครรู้จัก implementation สำหรับภาษาอื่นอย่าง Java, C# บ้างไหม?

    • ขึ้นอยู่กับว่าหมายถึง implementation ทั่วไป หรือหมายถึง “implement เองตั้งแต่ต้น”
      รายการ implementation ทั่วไปอยู่ที่นี่: https://pq-crystals.org/kyber/software.shtml
    • แล้ว liboqs ของ OpenQuantumSafe ล่ะ? มี implementation ของ primitive ส่วนใหญ่ของ PQC ที่เคยถูกเสนอจนถึงตอนนี้
      https://github.com/open-quantum-safe/liboqs

  • เจ๋งที่มันยังทำงานกับ draft00/kyber v3 ได้ด้วย
    ถ้าจะรองรับ Kyber 90’s mode แบบเร็วที่ไม่ใช้ SHA-3 จะยากแค่ไหนนะ? น่าจะต้องทำลาย abstraction ในกรณีนั้น

    • ถ้าจะเปลี่ยน hash ต้อง fork implementation นี้ใช้เวลา CPU แค่ประมาณ 20% ไปกับ SHA-3 ดังนั้นประโยชน์ไม่ได้มากนัก
      ถ้า optimize field implementation สัดส่วนนั้นคงสูงขึ้น แต่ก็คงยังไม่ถึงขั้นคุ้มที่จะใช้โหมดที่ไม่ได้มาตรฐานและผ่านการทดสอบน้อยกว่า

  • ไม่เกี่ยวกันเท่าไร แต่ Filo, ตาราง system call 32-bit ยังเป็น ‘coming soon’ อยู่เลยนะ :')

    • ฮ่า ๆ ยอมรับ ทุกครั้งที่คิดจะไปปรับหน้านั้น ขอบเขตงานมันก็ บานปลายขึ้นเรื่อย ๆ แบบว่าให้สร้างอัตโนมัติจากซอร์สเคอร์เนลด้วย CI ไปเลย :)

  • แม้จะไม่มีความสามารถพอจะตัดสินคุณภาพของอัลกอริทึมหรือการใช้งานนี้ แต่ชอบมากที่ใช้ Unicode ในชื่อตัวแปร
    ρ, σ := G[:32], G[32:]
    รู้สึกว่าดีกว่าการเห็น "rho", "sigma" มาก

    • ไม่ค่อยเห็นด้วย ถึงจะดูเท่ แต่ในโค้ดจริงไม่ค่อยอยากเห็นเท่าไร
      อย่างแรกคือไม่รู้ว่าจะพิมพ์ด้วยคีย์บอร์ดยังไง และคนส่วนใหญ่ก็น่าจะไม่รู้ชื่อของสัญลักษณ์เหล่านี้ด้วย แน่นอนว่าคนที่อ่านโค้ดนั้นมีโอกาสจะรู้มากกว่า แต่ก็ยังคิดว่าไม่ใช่โค้ดที่เป็นมิตร
      ความชัดเจนคือหัวใจสำคัญ และ "rho" หรือ "sigma" ก็ค่อนข้างชัดเจนอยู่แล้ว ยิ่งถ้ามีค่าคงที่ "n" กับค่าคงที่ "η" อยู่ด้วยกัน ก็เหมาะมากที่จะทำให้สับสน
    • ไม่ชอบเลย ตัวอักษรที่ไม่มีบนคีย์บอร์ดของฉันทำให้ต้องเพิ่มขั้นตอนตอนพิมพ์ เกิด friction สูงเกินไป อีกอย่างมีแนวโน้มจะอ่าน ρ ผิดเป็น p แล้วเจอ compile error แปลก ๆ
      แล้วถ้าใส่เครื่องหมาย accent หรือ cedilla ให้ตัวอักษรล่ะ? ก็เพิ่มแต่ความซับซ้อน ควรยึดตามตัวหารร่วมต่ำสุดจะดีกว่า
    • Go อนุญาตให้ใช้ Unicode subscript ในชื่อตัวแปรหรือเปล่า?
      จากภาษาที่ลองตรวจดู Perl, Python, JavaScript ไม่อนุญาตใน Chrome และ Firefox ส่วน PHP อนุญาต

  • คนที่ทำสิ่งนี้คือคนเดียวกับที่ทำ https://github.com/FiloSottile/age
    ชอบเครื่องมือนี้มาก

    • เสียดายที่ไม่มี plausible deniability ในตัว หมายความว่าอย่างน้อยควรเข้ารหัสไฟล์สองไฟล์ และสามารถถอดรหัสไฟล์ใดไฟล์หนึ่งได้ตามคีย์ที่ให้
      ดูเหมือนจะเป็น จุดอ่อนด้านความปลอดภัย ของเครื่องมือประเภทนี้ส่วนใหญ่ ถ้ามีคีย์ที่เป็นไปได้แค่ดอกเดียว คนที่ถือค้อนก็อาจบังคับให้คุณคายคีย์นั้นออกมาได้ แต่ถ้าไม่รู้ว่ามีกี่คีย์ คุณอาจให้ไปสักสองสามดอก แล้วซ่อนไฟล์ที่ปกป้องจริงไว้ พร้อมหวังว่าผู้โจมตีจะจากไป
    • อยากจะชอบเครื่องมือนี้นะ แต่ขาด คู่มือหรือ tutorial ที่อธิบายการใช้งานแบบทั่วไป ไม่ได้หมายถึงวิธีใช้ command line แต่อยากรู้ว่าควรจัดการและแจกจ่ายคีย์อย่างไร และต้องระวังอะไรบ้าง
      ชั้นทางสังคมทั้งหมดที่วางอยู่บนเทคโนโลยีนี้ยังไม่ชัดเจนสำหรับฉัน ถ้ามีเรื่องตัวอย่างที่มี Alice กับ Bob ก็คงดี
    • Age ก็โอเค แต่ดูเหมือนหยุดนิ่งไปแล้ว release ล่าสุดคือปี 2022 และไม่ได้ใช้ password-based key derivation function ที่ทันสมัยกว่าอย่าง argon
      ถ้ากำลังมองหาสิ่งที่ออกแบบมาสำหรับเก็บ/แชร์ความลับ ลองดู rot ก็ได้: https://github.com/candiddev/rot

  • สเปก: https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.203.ipd.pdf มีลิงก์ไว้ในบทความด้วย