AES-256-GCM sering muncul pada dokumen keamanan, tetapi namanya memuat tiga gagasan berbeda: AES sebagai block cipher, 256 sebagai ukuran kunci, dan GCM sebagai mode operasi. Memahami pemisahan ini penting agar developer tidak menganggap sebuah nama algoritma otomatis menjamin implementasi aman.
Bagaimana membaca nama AES-256-GCM?
AES adalah standar enkripsi simetris: pihak yang mengenkripsi dan mendekripsi menggunakan material kunci rahasia yang sesuai. Angka 256 menunjukkan panjang kunci dalam bit, bukan ukuran data, tag, atau nonce. GCM adalah mode yang mengatur bagaimana AES digunakan untuk melindungi pesan yang panjangnya tidak harus sama dengan satu blok.
Pemisahan istilah ini mencegah kesimpulan keliru. AES-256 bukan berarti “256 kali lebih aman”, dan GCM bukan nama hash. Dokumen primer NIST SP 800-38D mendefinisikan GCM sebagai mode authenticated encryption with associated data. Untuk konteks perlindungan kredensial yang lebih luas, baca enkripsi kredensial saja tidak cukup.
Dua jaminan apa yang diberikan?
Kerahasiaan membuat isi pesan tidak dapat dibaca tanpa kunci yang benar. Autentikasi data membantu penerima mendeteksi perubahan pada ciphertext dan associated data. Hasil enkripsi biasanya mencakup ciphertext dan authentication tag. Penerima harus memverifikasi tag sebelum menganggap plaintext sah.
| Komponen | Fungsi | Bukan fungsinya |
|---|---|---|
| Ciphertext | Menyembunyikan plaintext | Membuktikan identitas bisnis pengirim |
| Authentication tag | Mendeteksi manipulasi | Menggantikan kontrol akses |
| Associated data | Mengikat konteks yang tidak dienkripsi | Menjadi tempat rahasia |
Mengapa nonce sangat penting?
Setiap operasi GCM membutuhkan nonce atau initialization vector. Untuk satu kunci yang sama, nilai ini tidak boleh digunakan ulang pada pesan berbeda. Pelanggaran dapat merusak jaminan kerahasiaan dan integritas, sehingga nonce bukan angka pelengkap yang boleh selalu diisi nol atau disalin dari contoh kode.
Strategi nonce harus dirancang bersama batas penggunaan kunci, proses paralel, restart, dan distribusi sistem. Detail ini dibahas dalam artikel khusus nonce. Untuk aplikasi nyata, gunakan API tingkat tinggi dari library matang dan ikuti kontrak library tersebut; jangan merangkai primitive sendiri.
Seperti apa contoh konseptualnya?
Bayangkan aplikasi menyimpan dokumen pembayaran. Plaintext berisi data pembayaran, sedangkan associated data berisi versi format dan identitas record yang boleh terlihat. Proses enkripsi menerima plaintext, associated data, kunci, dan nonce, lalu menghasilkan ciphertext serta tag. Saat membaca, semua komponen yang diperlukan diberikan kembali dan tag diverifikasi.
Jika ciphertext, associated data, atau tag berubah, dekripsi harus gagal tanpa mengembalikan data yang dianggap valid. Kegagalan ini berbeda dari “password salah” dan tidak boleh disiasati dengan mengabaikan verifikasi. Log sebaiknya mencatat konteks operasional secukupnya tanpa mencetak plaintext, kunci, nonce rahasia yang keliru diklasifikasikan, atau seluruh paket terenkripsi.
Kesalahan apa yang paling sering terjadi?
- Menggunakan ulang nonce dengan kunci yang sama.
- Membuat kunci dari password manusia tanpa fungsi derivasi yang sesuai.
- Menyimpan kunci di lokasi yang sama dan dengan izin yang sama seperti ciphertext.
- Mengabaikan kegagalan verifikasi tag atau mencoba memproses plaintext parsial.
- Mengarang format paket sendiri tanpa versi, batas ukuran, dan prosedur migrasi.
- Menyebut enkripsi sebagai solusi untuk otorisasi, backup, atau keamanan endpoint.
Ancaman tersebut sebaiknya dimasukkan ke threat model integrasi, sehingga review tidak berhenti pada pilihan algoritma.
Bagaimana menilai penggunaan yang aman?
Tanyakan sumber kunci, siapa yang dapat mengaksesnya, bagaimana nonce dijamin unik, bagaimana tag diverifikasi, dan apa yang terjadi saat kunci harus diganti. Pastikan format terenkripsi memiliki versi agar data lama dapat dibaca melalui jalur migrasi yang direncanakan. Tambahkan pengujian negatif dengan ciphertext, tag, dan associated data yang sengaja diubah.
Artikel ini tidak menyatakan konfigurasi produk tertentu. Saat mengevaluasi platform seperti NitroNet, minta bukti tentang boundary keamanan dan prosedur operasinya, lalu cocokkan dengan kebijakan organisasi. Lanjutkan dengan siklus hidup kunci kriptografi sebelum membuat keputusan implementasi; nama algoritma hanyalah satu bagian dari sistem perlindungan data.
Review tidak cukup memeriksa apakah fungsi encrypt dan decrypt menghasilkan plaintext yang sama. Pengujian harus membuktikan kegagalan yang aman, format yang dapat dimigrasikan, serta asumsi kunci dan nonce yang eksplisit. Gunakan daftar berikut sebagai bahan diskusi dengan reviewer keamanan yang kompeten.
- Pastikan library dan API yang dipilih masih dipelihara serta tidak meminta developer merangkai primitive tingkat rendah.
- Dokumentasikan sumber kunci, ukuran yang digunakan, tujuan, pemilik, dan pihak yang diizinkan melakukan dekripsi.
- Jelaskan cara nonce dibuat dan mengapa strategi tersebut mencegah penggunaan ulang pada satu kunci.
- Ubah satu byte ciphertext dan pastikan dekripsi gagal tanpa mengembalikan plaintext parsial kepada aplikasi.
- Ubah authentication tag serta associated data secara terpisah dan verifikasi keduanya ditolak dengan tegas.
- Beri versi pada envelope terenkripsi agar perubahan format atau algoritma dapat dimigrasikan secara terencana.
- Tetapkan batas ukuran input, penanganan memory, dan larangan mencetak plaintext atau key material pada error.
- Uji data lama setelah rotasi serta prosedur pemulihan dengan salinan yang benar-benar terisolasi dan terkontrol.
Keputusan produksi sebaiknya dicatat sebagai threat, kontrol, bukti, dan risiko sisa. AES-256-GCM dapat menjadi primitive yang kuat, tetapi keselamatan sistem muncul dari penggunaan yang benar di sepanjang lifecycle. Jika tim tidak dapat menjelaskan salah satu jawaban, hentikan implementasi sementara dan cari review, bukan menutup gap dengan komentar kode.