XAES-256-GCM AEAD แบบ nonce ขยาย

แนะนำ XAES-256-GCM

• XAES-256-GCM เป็นอัลกอริทึมการเข้ารหัสแบบยืนยันความถูกต้อง (AEAD) ที่ใช้คีย์ 256 บิตและ nonce 192 บิต
• เป้าหมายหลัก:
  • รองรับ nonce ที่สร้างแบบสุ่มได้อย่างปลอดภัย
  • เป็นไปตามข้อกำหนด FIPS 140
  • สามารถนำไปใช้ได้ง่ายในไลบรารีเข้ารหัสทั่วไป

เป้าหมายการออกแบบของ XAES-256-GCM

• ใช้ nonce ขนาดใหญ่เพื่อให้สามารถสร้างแบบสุ่มได้อย่างปลอดภัยสำหรับข้อความจำนวนไม่จำกัด
• รองรับการใช้งานในสภาพแวดล้อมที่หลากหลายผ่านการปฏิบัติตาม FIPS 140
• ลดภาระของผู้ใช้ด้วยการติดตั้งใช้งานที่เรียบง่าย

หลักการทำงานของ XAES-256-GCM

• ใช้โครงสร้าง nonce แบบขยายที่อิงจาก AES-256-GCM
• คำนวณคีย์อนุพันธ์จากคีย์อินพุตและ nonce
• ประมวลผลข้อความด้วยการเรียกใช้ AES-256 สามครั้ง

การติดตั้งใช้งานและการปรับแต่งประสิทธิภาพ

• implementation อ้างอิงของ Go มีโค้ดน้อยกว่า 100 บรรทัด
• ใช้เพียง crypto/cipher และ crypto/aes จาก standard library
• สามารถอธิบายได้ด้วย NIST SP 800-108r1 KDF และ NIST AES-256-GCM AEAD

implementation จากภายนอกและความเข้ากันได้

• มี implementation จากภายนอกใน .NET 8+, pyca/cryptography และ Web Cryptography API
• ไม่สามารถเปลี่ยนจำนวนรอบได้เพื่อให้เป็นไปตาม FIPS 140

ทางเลือกอื่นและ test vector

• มีทางเลือกหลากหลาย เช่น AES-GCM-SIV
• มี test vector สำหรับ code path หลัก

สรุป

• XAES-256-GCM ถูกออกแบบให้เป็น AEAD ที่ปลอดภัย เป็นไปตามข้อกำหนด และทำงานร่วมกันได้
• มีบทบาทเสริม XChaCha20Poly1305 และ AES-GCM-SIV
• หวังว่าจะถูกเพิ่มเข้าไปใน Go standard library

ความเห็นของ GN⁺

• XAES-256-GCM น่าสนใจจากการใช้ nonce ขนาดใหญ่เพื่อเพิ่มความปลอดภัย
• ใช้งานได้ในสภาพแวดล้อมที่หลากหลายด้วยการปฏิบัติตาม FIPS 140
• สามารถติดตั้งใช้งานได้ง่ายในภาษาอย่าง Go จึงมีประโยชน์สำหรับนักพัฒนา
• ทางเลือกอย่าง AES-GCM-SIV ก็ควรค่าแก่การพิจารณาเช่นกัน
• เมื่อนำเทคโนโลยีใหม่มาใช้ ควรพิจารณาประสิทธิภาพและความเข้ากันได้อย่างรอบคอบ

[GN⁺]

ความคิดเห็นจาก Hacker News

• การออกแบบฉลาดมาก: อิงกับ CMAC และสามารถใช้ AES-CBC เพื่ออนุมานคีย์ได้เมื่อไม่มี primitive ระดับล่าง

  • หากอธิบายในศัพท์ของ AES-CBC:

    1. L = AES-CBC-256ₖ(iv = 0¹²⁸, plaintext = 0¹²⁸)[:16]
    2. MSB₁(L) = 0이면, K1 = L << 1;
       그렇지 않으면 K1 = (L << 1) ⊕ 0¹²⁰10000111
    3. M1 = 0x00 || 0x01 || X || 0x00 || N[:12]
    4. M2 = 0x00 || 0x02 || X || 0x00 || N[:12]
    5. Kₓ = AES-CBC-256ₖ(iv = K1, plaintext = M1)[:16] || AES-CBC-256ₖ(iv = K1, plaintext = M2)[:16]
    6. Nₓ = N[12:]
    

  • AES-CBC-256 จะคืนค่าบล็อก 128 บิตแรก และทิ้งบล็อกที่ padding แล้ว
  • หลังจากอนุมานคีย์แล้ว ให้นำไปใช้ร่วมกับ AES-GCM มาตรฐาน
  • ตัวอย่าง implementation แบบ JS ที่อิงกับ WebCrypto API: ลิงก์ GitHub
  • รองรับ CryptoKey ที่เหมาะสมซึ่งตั้งใจไว้สำหรับ AES-CBC และสามารถเก็บใน IndexedDB ได้

• งานของ Filippo ยอดเยี่ยมมาก: แก้ปัญหาที่ต้องหมุนคีย์ทุก ๆ 2^32 ข้อความเมื่อใช้ nonce แบบสุ่ม

  • การชนกันของ nonce ใน AES-GCM เป็นเรื่องร้ายแรงถึงขั้นวิกฤต (ทำให้ผู้โจมตีสามารถเซ็นข้อความใดก็ได้)
  • ไม่จำเป็นต้องใช้ nonce แบบสุ่มเสมอไป แต่โดยทั่วไปมักแนะนำให้ใช้
  • ฉลาดมากที่ทำให้สอดคล้องกับ FIPS โดยใช้ primitive สองอย่าง (KDF แบบอิงเคาน์เตอร์และ GCM ปกติ)

• อยากให้ฟีเจอร์นี้มีอยู่เมื่อหลายปีก่อนตอนเขียนระบบไฟล์เข้ารหัส

  • การชนกันของ nonce เป็นปัญหาใหญ่ในการ deploy ระบบไฟล์ขนาดใหญ่
  • 2^32 อาจดูมาก แต่ในชุดอาร์เรย์ระดับ PB ที่เขียน 100k IOPS ต่อวินาที แทบจะการันตีได้เลยว่าจะเกิดการชนหากพึ่งพาความสุ่มของ PRNG

• หวังว่าฟีเจอร์นี้จะถูกนำไปใช้กับ age เวอร์ชันที่สอดคล้องกับ FIPS สำหรับการเข้ารหัสไฟล์ archive[1]

  • ผู้ตรวจสอบในอุตสาหกรรมธนาคารคัดค้าน age เพราะไม่ได้ใช้ AES แทน ChaCha (ส่วน public key X25519 เพิ่งได้รับการอนุมัติจาก NIST เมื่อไม่นานมานี้)
  • ไม่มีประสบการณ์กับ golang แต่ดูเหมือนจะนำไปใช้ได้ง่ายตามสเปกของ age
  • ถ้ามีเวลาจะลองทำดู
  • จะเรียกมันว่า "cage" (ย่อมาจาก "compliant actually good encryption")

• คำถามจากคนที่ไม่ใช่นักเข้ารหัส: สงสัยว่าทำไมถึงใช้ nonce 192 บิต ไม่ใช้ 256 บิต

  • ในการใช้งานจริง ดูเหมือนว่าบิตที่เพิ่มขึ้นไม่น่ามีต้นทุนสูงนัก

• (ความเสี่ยงการชนกัน 2⁻³² ที่ 2⁸⁰ ข้อความ)

  • เนื่องจากขนาดบล็อกของ AES คือ 128 บิต จึงสงสัยว่าจะมีปัญหาเกิดขึ้นก่อนหน้านั้นหรือไม่