XAES-256-GCM AEAD dengan nonce yang diperluas

Pengenalan XAES-256-GCM

• XAES-256-GCM adalah algoritma authenticated encryption (AEAD) yang menggunakan kunci 256-bit dan nonce 192-bit
• Tujuan utama:
  • Mendukung nonce yang dibuat secara acak dengan aman
  • Mematuhi FIPS 140
  • Dapat diimplementasikan dengan mudah di pustaka kriptografi umum

Tujuan desain XAES-256-GCM

• Menggunakan nonce besar agar dapat dibuat secara acak dengan aman untuk jumlah pesan tak terbatas
• Dapat digunakan di berbagai lingkungan melalui kepatuhan FIPS 140
• Mengurangi beban pengguna melalui implementasi yang sederhana

Cara kerja XAES-256-GCM

• Menggunakan struktur nonce yang diperluas berbasis AES-256-GCM
• Menghitung kunci turunan menggunakan kunci masukan dan nonce
• Memproses pesan dengan tiga kali pemanggilan AES-256

Implementasi dan optimisasi

• Implementasi referensi Go terdiri dari kurang dari 100 baris kode
• Hanya menggunakan crypto/cipher dan crypto/aes dari pustaka standar
• Dapat dijelaskan menggunakan NIST SP 800-108r1 KDF dan NIST AES-256-GCM AEAD

Implementasi pihak ketiga dan kompatibilitas

• Terdapat implementasi pihak ketiga di .NET 8+, pyca/cryptography, dan Web Cryptography API
• Jumlah ronde tidak dapat diubah demi kepatuhan FIPS 140

Alternatif dan vektor uji

• Tersedia berbagai alternatif seperti AES-GCM-SIV
• Menyertakan vektor uji untuk jalur kode utama

Ringkasan

• XAES-256-GCM dirancang sebagai AEAD yang aman, patuh, dan interoperabel
• Berperan melengkapi XChaCha20Poly1305 dan AES-GCM-SIV
• Diharapkan dapat ditambahkan ke pustaka standar Go

Opini GN⁺

• XAES-256-GCM menonjol karena meningkatkan keamanan dengan menggunakan nonce besar
• Dapat digunakan di berbagai lingkungan melalui kepatuhan FIPS 140
• Berguna bagi pengembang karena mudah diimplementasikan dalam bahasa seperti Go
• Alternatif seperti AES-GCM-SIV juga layak dipertimbangkan
• Saat mengadopsi teknologi baru, kinerja dan kompatibilitas perlu ditinjau dengan cermat

[GN⁺]

Komentar Hacker News

• Desainnya sangat cerdas: berbasis CMAC, sehingga dapat menurunkan kunci menggunakan AES-CBC ketika primitive level rendah tidak tersedia

  • Jika dijelaskan dengan istilah 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 mengembalikan blok 128-bit pertama, dan blok yang di-padding dibuang
  • Digunakan bersama AES-GCM standar setelah kunci diturunkan
  • Contoh implementasi JS berbasis WebCrypto API: tautan GitHub
  • Menerima CryptoKey yang sesuai dan ditujukan untuk AES-CBC, serta dapat disimpan di IndexedDB

• Pekerjaan Filippo sangat bagus: ini menyelesaikan masalah bahwa saat menggunakan nonce acak, kunci harus dirotasi setiap sekitar 2^32 pesan

  • Dalam AES-GCM, tabrakan nonce bersifat fatal (penyerang bisa menandatangani pesan arbitrer)
  • Tidak harus menggunakan nonce acak, tetapi secara umum itu direkomendasikan
  • Sangat cerdas karena dibuat tetap patuh FIPS dengan memakai dua primitive (KDF berbasis counter dan GCM biasa)

• Andai fitur ini sudah ada beberapa tahun lalu saat menulis file system terenkripsi

  • Tabrakan nonce adalah masalah besar dalam deployment file system berskala besar
  • 2^32 terlihat besar, tetapi pada array PB yang menulis 100k IOPS per detik, jika bergantung pada keacakan PRNG, kemungkinan tabrakan hampir terjamin

• Semoga fitur ini digunakan dalam age[1] varian patuh FIPS untuk keperluan enkripsi file arsip

  • Auditor industri perbankan menolak age karena tidak menggunakan AES dan memakai ChaCha sebagai gantinya (bagian kunci publik X25519 baru-baru ini disetujui oleh NIST)
  • Saya tidak punya pengalaman dengan golang, tetapi menurut spesifikasi age sepertinya bisa diterapkan dengan mudah
  • Jika ada waktu, saya akan mencobanya
  • Akan saya sebut "cage" (singkatan dari "compliant actually good encryption")

• Pertanyaan dari non-kriptografer: penasaran mengapa memakai nonce 192-bit dan bukan 256-bit

  • Dalam aplikasi praktis, bit tambahan itu tampaknya tidak akan terlalu mahal

• (risiko tabrakan 2⁻³² pada 2⁸⁰ pesan)

  • Karena ukuran blok AES adalah 128-bit, saya penasaran apakah masalah bisa muncul lebih dulu sebelum itu