XAES-256-GCM: AEAD Nonce yang Diperluas

 (words.filippo.io)
1 poin oleh GN⁺ 2024-06-30 | 1 komentar | Bagikan ke WhatsApp
  • XAES-256-GCM adalah spesifikasi AEAD baru yang menggunakan kunci 256-bit dan nonce 192-bit untuk membuat pengelolaan nonce pada API kriptografi tingkat tinggi menjadi lebih aman
  • Nonce yang besar memungkinkan pendekatan pembuatan otomatis nilai baru dari CSPRNG sistem operasi untuk setiap pesan, dengan target risiko tabrakan sekitar 2⁻³² pada 2⁸⁰ pesan
  • Secara internal, ini adalah konstruksi nonce yang diperluas yang menurunkan kunci turunan dan nonce 96-bit dari kunci masukan dan nonce besar, lalu menggunakan AES-256-GCM standar tanpa perubahan
  • Implementasi referensi Go muat dalam kurang dari 100 baris hanya dengan crypto/cipher dan crypto/aes, dan dari 3 pemanggilan AES-256 per pesan, sebagian dapat dihitung sebelumnya
  • Dengan menekankan kepatuhan FIPS 140 dan kompatibilitas pustaka, ini dapat menjadi kandidat API AEAD tanpa nonce bersama XChaCha20Poly1305 dan AES-GCM-SIV

AEAD nonce besar untuk API tingkat tinggi

  • XAES-256-GCM adalah algoritme authenticated encryption with additional data (AEAD) yang menggunakan kunci 256-bit dan nonce 192-bit
  • Tujuan desainnya diringkas menjadi tiga hal
    • dukungan nonce besar yang aman untuk pembuatan acak bahkan pada jumlah pesan yang secara praktis nyaris tak terbatas
    • kepatuhan FIPS 140 yang penuh dan langsung
    • implementasi yang mudah di atas pustaka kriptografi umum
  • Berkat nonce yang besar, dapat dibuat API yang membaca nonce baru dari CSPRNG sistem operasi untuk setiap pesan tanpa mengharuskan pengguna menghitung birthday bound sendiri
  • Dengan memprioritaskan kepatuhan dan kompatibilitas, ini dapat diterapkan di tempat yang memerlukan AEAD bahkan dalam lingkungan yang sulit memakai AEAD nonce besar lainnya

Konstruksi nonce yang diperluas yang memanfaatkan AES-256-GCM apa adanya

  • XAES-256-GCM adalah konstruksi nonce yang diperluas yang dibangun di atas AEAD yang sudah ada, seperti XChaCha20Poly1305
  • Dari kunci masukan dan nonce 192-bit, dihitung kunci turunan dan nonce turunan untuk AES-256-GCM internal
    • kunci masukan dan nonce masing-masing adalah K, N
    • kunci dan nonce turunan AES-256-GCM adalah Kₓ, Nₓ
  • Kₓ dibuat menggunakan pemanggilan AES-256ₖ dan bagian awal nonce, lalu 96 bit terakhir dari nonce masukan digunakan sebagai Nₓ
  • Diperlukan 3 pemanggilan AES-256ₖ per pesan
    • salah satunya dapat dihitung sebelumnya untuk kunci tertentu
    • dua pemanggilan sisanya dapat memakai ulang key schedule yang sama

Implementasi singkat dan dapat dijelaskan dengan komponen standar

  • Implementasi referensi Go kurang dari 100 baris, termasuk optimasi precomputation dan sebagian besar boilerplate
  • Implementasi Go hanya menggunakan crypto/cipher dan crypto/aes dari pustaka standar
  • XAES-256-GCM juga dapat dijelaskan dengan KDF standar NIST SP 800-108r1 dan AEAD NIST AES-256-GCM standar
    • KDF-nya adalah counter-based KDF
    • PRF-nya adalah CMAC-AES256
    • kunci masukan adalah Kin
    • labelnya adalah karakter ASCII X, yaitu 0x58
    • konteksnya adalah 96 bit pertama dari nonce masukan
    • ukuran counter adalah 16-bit
    • field L opsional dihilangkan
    • keluarannya adalah kunci turunan 256-bit
  • Kunci turunan dan 96 bit terakhir dari nonce masukan kemudian dimasukkan ke AES-256-GCM
  • Berkat pilihan parameter ini, jika abstraksi KDF dan CMAC dilepas, pendekatan ini hanya sedikit lebih lambat dan lebih kompleks daripada sekadar memanggil AES-256 pada counter
  • Parameter yang sama juga didukung pada API OpenSSL tingkat tinggi

Implementasi pihak ketiga dan test vector

Meninggalkan /11 dan alternatif

  • Gagasan sebelumnya memakai nama XAES-256-GCM/11, tetapi spesifikasi final meninggalkan /11
  • /11 adalah optimasi performa, dan karena salah satu alasan memakai AES-GCM adalah kepatuhan FIPS 140, mengubah jumlah putaran akan menghilangkan kepatuhan tersebut
  • Jika kepatuhan FIPS 140 bukan tujuan, ada berbagai alternatif
    • AES-GCM-SIV
    • konstruksi AEAD modern berbasis AES core
  • Bagian Alternatives dalam spesifikasi membandingkan tiap alternatif dengan XAES-256-GCM

Posisi dalam Go dan API AEAD tanpa nonce

  • XAES-256-GCM menargetkan AEAD yang aman, membosankan, patuh, dan interoperabel
  • Penggunaan utamanya adalah API tingkat tinggi jenis yang ingin ditambahkan ke Go
  • XAES-256-GCM dirancang sebagai kandidat implementasi untuk API AEAD tanpa nonce hipotetis, melengkapi XChaCha20Poly1305 dan AES-GCM-SIV
  • Karena tidak ingin menambahkan konstruksi khusus Go ke pustaka standar Go, diperlukan masukan dari para maintainer pustaka kriptografi lainnya

Bacaan terkait

1 komentar

 
GN⁺ 2024-06-30
Komentar Hacker News

  • Desainnya sangat cerdas: karena berbasis CMAC, kunci bisa diturunkan dengan AES-CBC tanpa perlu primitif tingkat rendah
    Dari sudut pandang AES-CBC, ini bisa dipahami sebagai mulai dari L = AES-CBC-256ₖ(iv = 0¹²⁸, plaintext = 0¹²⁸)[:16] untuk membuat K1, lalu mengenkripsi M1 dan M2 untuk memperoleh Kₓ, kemudian menggunakan Nₓ = N[12:]
    AES-CBC-256 dapat dianggap hanya mengembalikan blok 128-bit pertama dari ciphertext dan membuang blok padding, dan meskipun padding tidak bisa dimatikan, dibanding implementasi tingkat rendah pun hanya butuh 3 pemanggilan AES tambahan dengan kunci yang sama, jadi tidak terlalu buruk
    Implementasi JS berbasis WebCrypto API yang memanfaatkan sifat ini ada di https://github.com/dchest/xaes, dan juga mendukung karakteristik CryptoKey seperti menerima CryptoKey AES-CBC apa adanya dan menyimpannya ke IndexedDB dengan extractable=false

    • Mungkin ini terlihat seperti notasi standar di bidang ini, tapi sejujurnya saya tidak suka notasi kriptografi
      Dalam pseudocode itu, setengah angkanya tampak menghitung jumlah byte, sisanya jumlah bit, dan kalau belum tahu algoritmenya, hampir mustahil menebak yang mana
      Misalnya N[:12] terlihat seperti 12 byte, tetapi 0¹²⁸ adalah 16 byte, dan X adalah karakter literal 'X', yaitu deretan bit 01011000, sedangkan L bukan deretan bit 01001100 melainkan sebuah variabel
      Jelas para matematikawan tidak menyukai notasi yang tidak ambigu seperti orang ilmu komputer
    • Konstanta yang tampak menyeramkan seperti 0¹²⁰10000111 adalah deretan bit yang merepresentasikan koefisien polinomial pertama secara leksikografis di antara polinomial irreduksibel berderajat b dengan jumlah suku bukan nol minimum, untuk ukuran blok block cipher b yang digunakan CMAC
      Tidak ada maksud tersembunyi di baliknya
    • Saya bukan ahli kriptografi, tetapi ringkasnya saya memahami bahwa AES-GCM AEAD standar akan rusak fatal jika nonce yang sama dipakai dua kali untuk pesan berbeda[1], dan ukuran nonce-nya juga terlalu kecil untuk aman memakai nonce acak dalam banyak kasus
      Pekerjaan ini memudahkan penghindaran masalah itu dengan mengganti bukan hanya nonce tetapi juga kunci pada setiap pemanggilan AES-GCM
      Selain itu, jika AES-GCM tersedia maka biasanya cukup memakai AES “biasa” yang tersedia luas, dan menghindari konstruksi baru yang kompleks yang mungkin masih punya kelemahan yang belum diketahui
      Overhead per pesan kira-kira berupa 2 buffer kecil yang harus dienkripsi/dekripsi dengan AES “biasa” dan nonce 192-bit yang lebih panjang
      [1]: https://frereit.de/aes_gcm/

  • Ini tampaknya menghilangkan jebakan AES-GCM murni yang mengharuskan penggantian kunci tiap sekitar 2^32 pesan saat memakai nonce acak
    Dalam AES-GCM, tabrakan nonce bersifat fatal dan setidaknya memungkinkan penyerang menandatangani pesan arbitrer
    Nonce acak memang tidak wajib, tetapi biasanya direkomendasikan, dan cukup cerdas bahwa ini dibuat patuh FIPS dengan memakai dua blok penyusun dasar: fungsi derivasi kunci berbasis counter dan GCM standar

    • Lebih tepatnya, pendekatan ini justru membuat nonce acak aman sejak awal
      Dalam AES-GCM standar, 96 bit tidak cukup untuk menghindari tabrakan acak, sehingga harus memakai pembangkitan nonce deterministik
      Selain itu, apa pun cara pembuatan nonce-nya, counter akan rollover sehingga blok berikutnya memakai kombinasi nonce+counter yang sama dengan blok pertama, jadi setelah 2^32 blok nonce atau kunci harus diganti

  • Ini benar-benar luar biasa. Andai saja ini sudah ada beberapa tahun lalu saat saya terakhir membuat filesystem terenkripsi
    Dalam deployment filesystem skala besar, tabrakan nonce adalah kekhawatiran besar
    2^32 memang terdengar besar, tetapi jika menulis ke array skala PB pada 100k IOPS per detik sambil mengandalkan keacakan generator pseudorandom, kemungkinan tabrakan praktis nyaris terjamin

    • Kompetisi CAESAR[1] berakhir pada 2019, dan menghasilkan beberapa AEAD dengan ruang nonce yang cukup besar
      [1] https://en.m.wikipedia.org/wiki/CAESAR_Competition
    • Tapi saya penasaran kenapa tabrakan nonce menjadi masalah
      Bukankah itu hanya berarti dua blok berbagi kunci enkripsi yang sama?
      Jika plaintext dari salah satu blok tidak diketahui, saya tidak melihat bagaimana itu melemahkan keamanan sistem

  • Akan bagus jika ini dipakai dalam varian age yang patuh FIPS untuk kebutuhan enkripsi file arsip
    Dalam audit perbankan, age ditolak untuk kasus penggunaan ini karena memakai ChaCha, meskipun mereka menganggap bagian kunci publik X25519 pada age tidak masalah. Saya kira X25519 sudah mendapat persetujuan NIST relatif baru-baru ini
    Saya tidak punya banyak pengalaman dengan Go, tetapi melihat spesifikasi age rasanya ini bisa langsung disisipkan, dan kalau ada waktu saya mungkin akan mencoba
    Namanya bisa saja “cage”, singkatan dari “compliant actually good encryption”
    1: https://github.com/FiloSottile/age

    • “compliant actually good encryption” mungkin justru sebuah oksimoron
    • Saya cek lagi, tampaknya Ed25519 sudah disetujui (FIPS 186-5), tetapi X25519 tampaknya belum
    • Sebagai referensi, pustaka standar Go belum punya implementasi XAES, hanya ada implementasi referensi dari C2SP
    • bge, bureaucratic good encryption

  • Sebagai orang non-kriptografi, saya penasaran kenapa memakai nonce 192-bit alih-alih 256-bit
    Dalam aplikasi praktis, rasanya bit tambahan itu tidak akan dianggap sebagai biaya

    • Tidak ada ruang untuk memasukkan 256 bit. 192 bit terdiri dari 96 bit yang berasal dari ruang subnonce, dan 96 bit yang bersama prefiks yang diperlukan masuk ke dalam blok CMAC 128-bit
      Input CMAC tentu bisa dibuat lebih panjang, tetapi itu berarti fungsi blok AES-256 harus dijalankan lebih banyak kali, dan juga menghadapi masalah kontrol kunci yang merepotkan dalam fungsi derivasi kunci CMAC
      Ini juga mirip alasan XChaCha20Poly1305 memakai nonce 192-bit, dan ada keuntungan kecil karena konsisten dengan AEAD extended-nonce utama lainnya

  • Disebutkan “risiko tabrakan 2⁻³² pada 2⁸⁰ pesan”, tetapi apakah fakta bahwa ukuran blok AES hanya 128 bit tidak menimbulkan masalah lebih dulu?

    • Kalau yang dimaksud adalah birthday bound untuk blok (https://sweet32.info), itu adalah batas pada jumlah blok yang dienkripsi dengan satu kunci
      XAES menurunkan kunci besar untuk setiap pesan, sehingga mencapai apa yang sering disebut jaminan yang lebih baik daripada birthday bound
    • Tidak juga
      Tanpa konteks lebih lanjut tentang kenapa Anda mengira itu akan menjadi masalah, sulit memberi jawaban yang lebih rinci dari ini

  • “Aman, membosankan, bisa dipatuhi, dan interoperabel”
    Ini jenis teknologi favorit saya

  • Bagus. Senang melihat memang ada konstruksi berbasis NIST
    Namun agak disayangkan bahwa beberapa fitur keunggulan fungsi derivasi kunci NIST, seperti label dan konteks, harus dikorbankan
    Saya paham itu dilakukan untuk meminimalkan jumlah pemanggilan AES, tetapi terutama untuk pesan yang lebih panjang dari beberapa ratus byte, saya pribadi mungkin akan lebih memprioritaskan pemisahan kriptografis yang lebih kuat daripada menghemat beberapa kali pemanggilan AES
    Terakhir, nonce GCM acak yang lebih panjang dari 96 bit memang sering disalahpahami, dan sebenarnya memberikan jaminan yang lebih baik daripada nonce 96-bit[1]
    Tentu saja, jika kunci baru bisa diturunkan untuk setiap pesan, itu jelas lebih baik
    [1] https://neilmadden.blog/2024/05/23/galois-counter-mode-and-r...