XAES-256-GCM AEAD với nonce mở rộng

Giới thiệu về XAES-256-GCM

• XAES-256-GCM là một thuật toán mã hóa có xác thực (AEAD) sử dụng khóa 256 bit và nonce 192 bit
• Mục tiêu chính:
  • hỗ trợ an toàn cho nonce được tạo ngẫu nhiên
  • tuân thủ FIPS 140
  • có thể dễ dàng triển khai trong các thư viện mã hóa phổ biến

Mục tiêu thiết kế của XAES-256-GCM

• Sử dụng nonce lớn để có thể tạo ngẫu nhiên một cách an toàn cho số lượng thông điệp không giới hạn
• Có thể sử dụng trong nhiều môi trường khác nhau nhờ tuân thủ FIPS 140
• Giảm gánh nặng cho người dùng nhờ triển khai đơn giản

Nguyên lý hoạt động của XAES-256-GCM

• Sử dụng cấu trúc nonce mở rộng dựa trên AES-256-GCM
• Tính toán khóa dẫn xuất bằng khóa đầu vào và nonce
• Xử lý thông điệp bằng ba lần gọi AES-256

Triển khai và tối ưu hóa

• Bản triển khai tham chiếu bằng Go gồm chưa đến 100 dòng mã
• Chỉ sử dụng crypto/cipher và crypto/aes của thư viện chuẩn
• Có thể mô tả bằng NIST SP 800-108r1 KDF và NIST AES-256-GCM AEAD

Triển khai của bên thứ ba và khả năng tương thích

• Có các triển khai của bên thứ ba trên .NET 8+, pyca/cryptography và Web Cryptography API
• Không thể thay đổi số vòng lặp để tuân thủ FIPS 140

Các lựa chọn thay thế và test vector

• Có nhiều lựa chọn thay thế như AES-GCM-SIV
• Bao gồm test vector cho các đường dẫn mã chính

Tóm tắt

• XAES-256-GCM được thiết kế như một AEAD an toàn, tuân thủ và có khả năng tương tác
• Đóng vai trò bổ sung cho XChaCha20Poly1305 và AES-GCM-SIV
• Hy vọng sẽ được bổ sung vào thư viện chuẩn của Go

Ý kiến của GN⁺

• Điểm đáng chú ý của XAES-256-GCM là tăng độ an toàn nhờ sử dụng nonce lớn
• Có thể dùng trong nhiều môi trường khác nhau nhờ tuân thủ FIPS 140
• Hữu ích cho nhà phát triển vì có thể dễ dàng triển khai trong các ngôn ngữ như Go
• Các lựa chọn thay thế như AES-GCM-SIV cũng đáng để cân nhắc
• Khi đưa công nghệ mới vào sử dụng, cần xem xét cẩn thận hiệu năng và khả năng tương thích

[GN⁺]

Ý kiến trên Hacker News

• Thiết kế rất khéo léo: dựa trên CMAC, có thể dùng AES-CBC để dẫn xuất khóa khi không có primitive cấp thấp

  • Diễn giải theo thuật ngữ 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 trả về khối 128 bit đầu tiên, còn khối đã được padding thì bị bỏ
  • Sau khi dẫn xuất khóa, dùng cùng AES-GCM tiêu chuẩn
  • Ví dụ triển khai JS dựa trên WebCrypto API: liên kết GitHub
  • Chấp nhận CryptoKey phù hợp vốn được thiết kế cho AES-CBC và có thể lưu trong IndexedDB

• Công việc của Filippo rất xuất sắc: giải quyết vấn đề phải xoay vòng khóa sau mỗi khoảng 2^32 thông điệp khi dùng nonce ngẫu nhiên

  • Trong AES-GCM, va chạm nonce là thảm họa (khiến kẻ tấn công có thể ký các thông điệp tùy ý)
  • Không bắt buộc phải dùng nonce ngẫu nhiên, nhưng nhìn chung đây là cách được khuyến nghị
  • Việc làm cho nó tuân thủ FIPS bằng cách dùng hai primitive (KDF dựa trên bộ đếm và GCM thông thường) là cực kỳ thông minh

• Ước gì tính năng này đã tồn tại vài năm trước khi tôi viết một file system mã hóa

  • Va chạm nonce là vấn đề lớn trong các triển khai file system quy mô lớn
  • 2^32 trông có vẻ lớn, nhưng với các mảng PB ghi 100k IOPS mỗi giây, nếu phụ thuộc vào tính ngẫu nhiên của PRNG thì khả năng va chạm gần như chắc chắn

• Mong rằng tính năng này sẽ được dùng cho một biến thể age[1] tuân thủ FIPS dành cho mã hóa file archive

  • Các kiểm toán viên trong ngành ngân hàng phản đối age vì không dùng AES thay cho ChaCha (phần khóa công khai X25519 gần đây đã được NIST phê duyệt)
  • Tôi không có kinh nghiệm với golang, nhưng có vẻ có thể áp dụng dễ dàng theo đặc tả age
  • Nếu có thời gian tôi sẽ thử
  • Tôi sẽ gọi nó là "cage" (viết tắt của "compliant actually good encryption")

• Câu hỏi từ người không chuyên về mật mã: tại sao lại dùng nonce 192 bit mà không phải 256 bit?

  • Trong các ứng dụng thực tế, có vẻ số bit bổ sung đó không tốn kém bao nhiêu

• (rủi ro va chạm 2⁻³² ở 2⁸⁰ thông điệp)

  • Vì kích thước khối AES là 128 bit, tôi tự hỏi liệu có vấn đề nào có thể xuất hiện trước mốc đó không