Enkripsi / Dekripsi AES

Cipher blok. AES (desain Rijndael, distandarkan oleh NIST pada 2001 sebagai FIPS 197) mengenkripsi tepat 16 byte sekaligus. Panjang kunci — 16, 24 atau 32 byte — menentukan AES-128, -192 atau -256 serta jumlah putaran internal (10, 12, 14). Setiap putaran mencampur blok dengan round key yang diturunkan dari kunci melalui tabel substitusi, pergeseran baris, dan pencampuran kolom. Tidak ada serangan praktis yang membobol cipher itu sendiri: kegagalan di dunia nyata hampir selalu berupa kesalahan mode, IV, atau manajemen kunci, dan itulah yang dibahas di sisa halaman ini.

Mengapa perlu mode? Karena pesan jarang berukuran 16 byte. Mode menyatukan enkripsi blok: ECB hanya mengenkripsi blok secara independen; CBC melakukan XOR setiap blok dengan ciphertext sebelumnya; CTR mengenkripsi counter lalu melakukan XOR dengan data seperti cipher stream; GCM dibangun di atas CTR dan menambahkan tag autentikasi. AES tetap sama — mode mengubah semua jaminan yang diperoleh.

Kunci dan kata sandi. Kunci AES adalah 16, 24 atau 32 byte acak. Kata sandi buatan manusia tidak seperti itu: opsi Kata sandi di halaman ini menurunkan kunci yang layak dengan PBKDF2-HMAC-SHA256 (600.000 iterasi secara default, baseline OWASP 2023 — lihat HMAC Generator untuk detail KDF). Jangan pernah memakai string kata sandi langsung sebagai kunci AES: entropinya hanya sebagian kecil dari panjangnya.

Mode	IV / nonce	Integritas	Catatan
GCM	12 byte, unik per pesan	Ya — tag 96..128-bit	AEAD: default yang direkomendasikan di mana saja (TLS 1.3, SSH, format file). Juga menerima AAD.
CBC	16 byte, tidak dapat diprediksi	Tidak	Padding PKCS#7; klasik tetapi memerlukan MAC di sampingnya. Bug padding oracle adalah jebakan klasik CBC.
CTR	Counter awal 16-byte	Tidak	Tanpa padding, bersifat seperti stream, akses acak; penggunaan ulang nonce di bawah satu kunci membocorkan XOR plaintext dengan plaintext.
ECB	tidak ada	Tidak	Blok identik → ciphertext identik. Demonstrasi penguin ECB. Hanya untuk kompatibilitas.

Aturan IV dalam satu paragraf. IV bukan rahasia — kirim bersama ciphertext — tetapi aturan keunikannya berbeda: CBC membutuhkan IV yang tidak dapat diprediksi; GCM dan CTR hanya menuntut nonce yang tidak pernah digunakan ulang dengan kunci yang sama (penggunaan ulang nonce GCM lebih buruk: ia membocorkan kunci autentikasi). Tombol IV acak di halaman ini memakai RNG aman dari browser; tombol Semua nol hanya untuk mereproduksi vektor uji, bukan untuk pesan nyata.

Padding. CBC dan ECB memerlukan blok penuh, sehingga padding PKCS#7 menambahkan 1..16 byte, masing-masing sama dengan panjang padding. Itulah sebabnya ciphertext CBC bertambah hingga 16 byte dan mengapa dekripsi dengan kunci yang salah biasanya gagal dengan error padding. CTR dan GCM bersifat seperti stream dan tidak memerlukan padding — panjang ciphertext persis sama dengan panjang plaintext (coba Contoh dalam mode CTR: 43 byte masuk, 43 byte keluar).

CFB dan OFB (dua mode klasik yang tersisa) tidak diimplementasikan di halaman ini: keduanya bersifat seperti stream seperti CTR tetapi tanpa keunggulan dibanding CTR, dan sebagian besar hanya bertahan di protokol lama.

Enkripsi terotentikasi. GCM = enkripsi CTR + autentikator GHASH atas ciphertext, IV, dan AAD. Tag keluaran adalah sidik jari dari semuanya: ubah satu bit ciphertext, IV, atau AAD dan tag tidak lagi cocok, sehingga penerima dapat membuktikan bahwa pesan utuh dan berasal dari pemegang kunci. CBC+HMAC mencapai hal yang sama hanya jika digabungkan dengan benar (encrypt-then-MAC) — GCM sudah benar sejak desainnya.

AAD. Data terotentikasi tambahan dikirim dalam bentuk terbuka tetapi tercakup oleh tag: header protokol, nama file, pengenal algoritma. Penerima harus menyediakan byte AAD yang identik atau pemeriksaan tag gagal — itulah tujuannya.

Panjang tag. Tag 128-bit default adalah rekomendasinya; tag yang lebih pendek (96..120 bit) menukar ketahanan terhadap pemalsuan dengan ukuran. Di bawah 96 bit, bukti keamanan GCM menurun dengan cepat, itulah sebabnya halaman ini berhenti di situ.

Bencana nonce. Penggunaan ulang nonce GCM 12-byte di bawah kunci yang sama membocorkan XOR plaintext dari dua pesan dan subkunci autentikasi — setelah itu pemalsuan dimungkinkan untuk semua pesan masa depan di bawah kunci tersebut. Sistem yang tidak dapat menjamin keunikan menggunakan varian yang tahan terhadap penyalahgunaan nonce (AES-GCM-SIV, RFC 8452).

Baris pertama adalah contoh blok tunggal FIPS 197 yang terkenal; baris lainnya dihasilkan oleh implementasi native independen (OpenSSL melalui Node.js) dan diverifikasi ulang dengan mesin di halaman ini. Tempelkan kunci, IV, dan input ke halaman untuk mereproduksi setiap baris.

Kasus	Input	Output yang diharapkan
AES-128 blok tunggal (gaya FIPS 197)	key 000102..0f, plaintext 00112233..ff	69c4e0d86a7b0430d8cdb78070b4c55a
AES-128-GCM	key 000102..0f, IV 606162..6b, plaintext 0011..ef ×2	ct 275f095bedfda377063fee326128892188377b410698ed03a022b9971bb4bdbe, tag 87ea7770714048977de2fd8dac645ecf
AES-256-GCM, sama tetapi AAD deadbeef	key 000102..1f	ct eacab966ff15e518f48f5390be502fbc2756ccee0dcfff36a282c50bf5593ae7, tag aead900e895c88252d0388d7aefce5c8
AES-256-CBC	key 000102..1f, IV 101112..1f, plaintext 0011..ef ×2	0e2392dd6f690b44a5a1b4fdff3b7f83cb9ab59d9900119cc5f83e062d95fb643b1a94b514ea2f3b95f84c900b5c98a8
AES-256-CTR (input sama dengan CBC di atas)	43-byte plaintext → 43-byte ciphertext	e9d2cdb9f661359178ed366dfa3a4671f8e20efd723f090eb7d1d524d480fd3c

• Memakai ECB karena tidak memerlukan IV. Kemudahannya adalah jebakannya: pola blok bocor langsung ke ciphertext (enkripsi gambar bitmap dan gambarnya masih terlihat). ECB hanya dapat diterima untuk blok tunggal atau kunci acak tepat 16-byte — dalam praktik, jangan pernah dipilih.
• Menggunakan ulang nonce/IV. Dengan GCM atau CTR di bawah satu kunci, ini adalah satu-satunya kesalahan yang merusak semuanya sekaligus. Sistem berbasis counter (tombol IV acak di halaman ini) ada untuk membuat hal itu mustahil.
• Menganggap IV sebagai rahasia. Bukan. Simpan atau kirim bersama ciphertext. Menyembunyikannya tidak menguntungkan dan justru mendorong penggunaan ulang.
• Menggunakan kata sandi sebagai kunci. "hunter2hunter2hunter2hunter2" berukuran 32 byte tetapi tidak memiliki entropi 256 bit — itu hanyalah kata kamus yang diberi tambahan. Turunkan dengan PBKDF2 (tersedia di halaman ini) atau buat kunci acak.
• Mengira CBC mendeteksi manipulasi. Balik satu bit dalam ciphertext CBC dan dekripsi “berhasil” dengan plaintext yang rusak tanpa peringatan. Hanya tag GCM (atau HMAC eksplisit) yang membuat manipulasi terlihat.
• Membandingkan ciphertext GCM untuk kesamaan. Dengan nonce acak, plaintext yang sama dienkripsi berbeda setiap kali — itu fitur. Enkripsi deterministik adalah alat lain yang khusus.

Apakah AES-128 masih aman, atau perlu 256? Keduanya aman terhadap penyerang yang realistis; serangan terbaik yang diketahui hanya mengurangi sebagian kecil margin. AES-256 terutama penting untuk rahasia jangka panjang dan ketahanan pascakuantum (algoritma Grover membagi dua kekuatan kunci, sehingga AES-256 setara sekitar 128-bit).

Mengapa openssl enc tidak mendukung GCM? Perintah enc lebih lama daripada AEAD dan tidak memiliki cara untuk membawa tag; OpenSSL 3.3 menambahkan perintah khusus aesgcm sebagai gantinya. Output GCM di halaman ini menyimpan tag pada baris tersendiri sehingga kedua bagian dapat dipindahkan secara eksplisit.

Apa itu key wrapping (AES-KW)? Mode khusus untuk mengenkripsi kunci lain dengan potongan 64-bit tetap dan pemeriksaan integritasnya sendiri. Mode ini tidak disediakan di sini karena input dan outputnya berbentuk kunci, bukan pesan — penyalahgunaan adalah hal yang umum.

Mengapa ciphertext CTR panjangnya sama dengan plaintext, tetapi milik CBC lebih panjang? CTR dan GCM bersifat seperti stream (tanpa padding); CBC/ECB menambahkan padding hingga blok 16-byte penuh dengan PKCS#7. Perbedaan panjang ini disengaja, bukan bug.

Bisakah mendekripsi data yang dienkripsi di tempat lain? Bisa, jika mode, kunci, IV (dan untuk GCM, tag) diketahui dengan tepat. Baris output di halaman ini mencatat semuanya secara tepat agar parameter dapat dipindahkan antar alat — kotak OpenSSL di atas menampilkan baris perintah yang sesuai.