Mode Enkripsi AES Dijelaskan Mengapa GCM Menangani CBC dalam Kebanyakan Kasus (dan Kapan Tidak)

Ketika dokumentasi mengatakan Anda harus 'menggunakan AES-256', itu adalah saran yang tidak lengkap. AES adalah cipher blok — ia mengenkripsi tepat satu blok 128-bit pada satu waktu. Mode operasi adalah yang menentukan bagaimana AES menangani data nyata yang lebih panjang dari 16 byte, dan seberapa besar perlindungan yang diberikan terhadap penyerang yang dapat mengamati atau mengubah teks terenkripsi. Kesalahan dalam hal ini adalah cara Anda akhirnya mendapatkan data yang terenkripsi yang mengungkap struktur file Anda, atau sistem yang rentan terhadap serangan bit-flipping. mode operasi adalah yang menentukan bagaimana AES menangani data nyata yang lebih panjang dari 16 byte, dan seberapa besar perlindungan yang diberikan terhadap penyerang yang dapat mengamati atau mengubah teks terenkripsi. Kesalahan dalam hal ini adalah cara Anda akhirnya mendapatkan data yang terenkripsi yang mengungkap struktur file Anda, atau sistem yang rentan terhadap serangan bit-flipping.

Spesifikasi algoritma lengkapnya terlihat seperti AES-256-GCM atau AES-128-CBC — ukuran kunci diikuti oleh mode. Artikel ini menjelaskan apa yang dilakukan oleh setiap mode, mengapa GCM adalah default yang tepat, dan kapan Anda mungkin secara sah menggunakan sesuatu yang lain.

Pertama, mengapa ECB adalah meme dan bukan hanya sebuah lelucon

ECB (Electronic Codebook) adalah mode yang sederhana. Setiap blok 16 byte dari teks plain dienkripsi secara terpisah dengan kunci yang sama. Artinya, blok-blok teks plain yang identik menghasilkan blok-blok teks terenkripsi yang identik.

Demonstrasi klasiknya adalah Linux penguin (Tux) yang dienkripsi dengan ECB. Bitmapnya dienkripsi blok demi blok, tetapi karena area besar dari gambar berwarna seragam, versi terenkripsi masih jelas menunjukkan bentuk penguin. Enkripsi secara matematis valid — data telah diacak — tetapi pola tetap terjaga.

Dalam praktiknya, ini penting ketika teks plain Anda memiliki pengulangan: baris database dengan prangkat yang sama, header file, bidang yang diisi. ECB mengungkap struktur. Tidak ada kasus yang sah untuk menggunakan ECB dalam kode baru. Jika Anda memelihara kode yang menggunakan ECB: ganti saja.

Mode-mode yang perlu diketahui

CBC — mode yang paling banyak digunakan oleh kode kuno

Cipher Block Chaining melakukan XOR pada setiap blok teks plain dengan blok ciphertext sebelumnya sebelum dienkripsi. Ini mengatasi masalah pola ECB — blok-blok teks plain yang identik menghasilkan ciphertext yang berbeda karena rantai ini membuat setiap blok terenkripsi tergantung pada apa yang datang sebelumnya.

CBC membutuhkan vector inisialisasi (IV) — nilai 16 byte acak yang menjadi awal rantai untuk blok pertama. IV tidak perlu rahasia, tetapi harus acak dan harus dikirim bersama dengan ciphertext.

Masalah dengan CBC: memberikan kerahasiaan . Banyak orang menemukan hal ini secara langsung. integritas. Seorang penyerang yang dapat mengubah ciphertext saat transit dapat mengubah bit tertentu pada output terdekripsi secara dapat diperkirakan. Ini adalah dasar dari serangan padding oracle, yang telah menghancurkan sistem nyata (POODLE, BEAST, Lucky Thirteen). Jika Anda menggunakan CBC tanpa MAC (Message Authentication Code) terpisah untuk memverifikasi integritas, Anda rentan. Pola ini disebut encrypt-then-MAC — enkripsi terlebih dahulu, lalu HMAC ciphertext, lalu verifikasi MAC sebelum mendekripsi. Kesalahan dalam urutan ini adalah kesalahan klasik.

CBC juga bersifat berurutan — Anda tidak bisa mempercepat enkripsi (setiap blok tergantung pada ciphertext blok sebelumnya) dan dekripsi hanya sebagian dapat dipercepat.

CTR — perilaku cipher aliran dari cipher blok

Mode Counter mengubah AES menjadi cipher aliran. Sebagai gantinya mengenkripsi teks plain secara langsung, ia mengenkripsi nilai-nilai counter berurutan dan melakukan XOR hasilnya dengan teks plain. Artinya, mode CTR tidak membutuhkan padding (fungsi pada data panjang sebarang), sepenuhnya dapat dipercepat dalam kedua arah, dan memungkinkan akses acak ke posisi apa pun dalam ciphertext untuk dekripsi.

CTR menggunakan nonce (nomor yang hanya digunakan sekali) alih-alih IV penuh. Nonce harus unik per pesan untuk kunci tertentu — penggunaan ulang nonce dengan kunci yang sama mengungkap XOR dari dua teks plain, yang sangat kritis. Berbeda dengan CBC, CTR juga tidak memiliki perlindungan integritas. Cerita yang sama: perlu encrypt-then-MAC jika Anda ingin perlindungan terhadap penyusupan.

CTR masuk akal ketika Anda membutuhkan sifat cipher aliran — file besar, dekripsi akses acak, skenario dengan throughput tinggi di mana paralelisme penting — dan Anda menangani lapisan MAC secara terpisah.

GCM — enkripsi terautentikasi, satu langkah

Galois/Counter Mode adalah CTR mode ditambah tag autentikasi bawaan (GHASH). Anda mendapatkan kerahasiaan dan integritas dalam satu primitif. Tag autentikasi — biasanya 128 bit — memungkinkan penerima memverifikasi bahwa ciphertext tidak telah diubah sebelum dekripsi. Tidak ada langkah HMAC terpisah, tidak ada kemungkinan kesalahan urutan encrypt-then-MAC.

GCM juga mendukung Data Autentikasi Tambahan (AAD) — data yang di-autentikasi tetapi tidak dienkripsi. Ini berguna untuk header, metadata, atau data apa pun yang membutuhkan perlindungan integritas tetapi tidak perlu kerahasiaan. AAD diperiksa bersama dengan ciphertext terhadap tag autentikasi.

Nonce untuk GCM adalah 96 bit (12 byte) secara default. Seperti CTR, penggunaan ulang nonce adalah fatal — penggunaan ulang nonce dengan kunci yang sama di bawah GCM mengungkapkan baik teks plain maupun kunci autentikasi (H), sepenuhnya menghancurkan keamanan. Selalu hasilkan nonce dengan RNG yang aman secara kriptografi; jangan turunkan dari penghitungan berurutan kecuali Anda memiliki skema penghitungan terdistribusi yang hati-hati.

GCM dapat dipercepat dan tidak membutuhkan padding. Ini adalah rekomendasi standar dalam TLS 1.3, Signal Protocol, dan kebanyakan perangkat lunak kriptografi modern. Jika Anda menulis kode baru, GCM adalah pilihan default Anda.

Perbandingan mode

Mode	Diperiksa	Dapat dipercepat	Membutuhkan padding	Risiko penggunaan ulang nonce/IV	Putusan
ECB	TIDAK	Ya	Ya	Tidak berlaku (tidak ada IV)	Jangan gunakan
CBC	Tidak (tambahkan MAC)	Enkripsi: Tidak / Dekripsi: Ya	Ya	Moderat	Hanya untuk sistem lama
CTR	Tidak (tambahkan MAC)	Ya	TIDAK	Kritis — penggunaan ulang = kebocoran teks plain	Penggunaan khusus
GCM	Ya (bawaan)	Ya	TIDAK	Kritis — penggunaan ulang = kegagalan total	Pilihan default

AES-256-GCM di Node.js

Berikut adalah implementasi lengkap enkripsi/dekripsi menggunakan modul bawaan Node — tidak membutuhkan ketergantungan: crypto Sebuah hal yang perlu diperhatikan tentang kode ini:

const crypto = require('crypto');

const ALGORITHM = 'aes-256-gcm';
const KEY_LENGTH = 32; // 256 bits
const NONCE_LENGTH = 12; // 96 bits — GCM default
const TAG_LENGTH = 16; // 128-bit auth tag

function encrypt(plaintext, key) {
  const nonce = crypto.randomBytes(NONCE_LENGTH);
  const cipher = crypto.createCipheriv(ALGORITHM, key, nonce, {
    authTagLength: TAG_LENGTH,
  });

  const encrypted = Buffer.concat([
    cipher.update(plaintext, 'utf8'),
    cipher.final(),
  ]);
  const tag = cipher.getAuthTag();

  // Prepend nonce + tag to ciphertext for storage/transmission
  return Buffer.concat([nonce, tag, encrypted]);
}

function decrypt(ciphertext, key) {
  const nonce = ciphertext.subarray(0, NONCE_LENGTH);
  const tag = ciphertext.subarray(NONCE_LENGTH, NONCE_LENGTH + TAG_LENGTH);
  const data = ciphertext.subarray(NONCE_LENGTH + TAG_LENGTH);

  const decipher = crypto.createDecipheriv(ALGORITHM, key, nonce, {
    authTagLength: TAG_LENGTH,
  });
  decipher.setAuthTag(tag);

  // Throws if auth tag doesn't match — do not catch this silently
  return Buffer.concat([decipher.update(data), decipher.final()]).toString('utf8');
}

// Generate a key (do this once; store it securely)
const key = crypto.randomBytes(KEY_LENGTH);

const message = 'Hello, authenticated encryption.';
const ciphertext = encrypt(message, key);
console.log('Encrypted:', ciphertext.toString('hex'));

const plaintext = decrypt(ciphertext, key);
console.log('Decrypted:', plaintext); // Hello, authenticated encryption.

Nonce dihasilkan secara baru setiap kali enkripsi dijalankan

• adalah yang aman secara kriptografi. Jangan ganti dengan penghitungan kecuali Anda memahami masalah keunikan terdistribusi. — crypto.randomBytes Nonce dan tag autentikasi disimpan bersama ciphertext
• — mereka harus bergerak bersama data terenkripsi. Nonce adalah publik; tag adalah publik. Hanya kunci yang rahasia. menolak jika gagal autentikasi
• decipher.final() — ini adalah perilaku yang benar. Jangan tangkap secara diam-diam dan kembalikan plaintext parsial. Gagal autentikasi berarti data telah diubah atau kunci salah. Manajemen kunci adalah bagian yang sulit
• memberikan kunci yang baik, tetapi tempat Anda menyimpan dan memutar kunci lebih penting daripada pilihan algoritma. Gunakan manajemen rahasia, bukan konstanta yang ditulis secara langsung. — crypto.randomBytes(32) Ingin menguji mode enkripsi secara interaktif?

IO Tools’ AES Enkripsi/De-kripsi alat memungkinkan Anda mengenkripsi dan mendekripsi dengan mode CBC dan GCM di browser — berguna untuk memverifikasi interoperabilitas atau memperbaiki integrasi. Untuk menghasilkan kunci 256-bit yang aman secara kriptografi, gunakan Generator Kunci AES IV dan nonce: aturan yang benar-benar penting.

Kesalahan penggunaan nonce/IV menyebabkan lebih banyak kegagalan dunia nyata daripada pilihan algoritma. Aturan-aturan:

Selalu hasilkan nonce/IV dengan CSPRNG

• di Node, — crypto.randomBytes() di Java. Bukan os.urandom() dalam Python, SecureRandom . Bukan waktu. Bukan penghitungan bertambah secara berurutan kecuali itu adalah penghitungan global yang dikelola dengan ketat dan jaminan keunikan. Math.random()Penggunaan ulang nonce di GCM menghancurkan autentikasi secara total
• — dengan kunci dan nonce yang sama, GCM mengungkapkan kunci autentikasi H. Seorang penyerang kemudian dapat membuat tag autentikasi untuk ciphertext yang sembarang. Ini bukan teori: Serangan Forbidden memanfaatkan ini dan telah digunakan terhadap implementasi nyata. Penggunaan ulang IV di CBC kurang kritis tetapi tetap buruk
• — serangan dengan teks plain yang dipilih menjadi mungkin. Dalam praktiknya, selalu hasilkan IV baru per pesan. Jangan turunkan nonce dari konten pesan
• — nonce yang deterministik yang bergantung pada data yang dapat diprediksi menciptakan pola yang dapat diprediksi. Gunakan keacakan. Kapan CBC atau CTR masih pilihan yang tepat

GCM tidak selalu jawabannya:

Interoperabilitas dengan sistem lama

• — jika Anda mengintegrasikan dengan sistem yang hanya berbicara AES-CBC, Anda menggunakan CBC. Dokumentasikan kebutuhan MAC secara jelas dan implementasikan dengan benar (encrypt-then-MAC dengan HMAC-SHA256). Lingkungan terbatas dengan tidak ada perangkat keras GHASH
• — langkah autentikasi GCM menggunakan GHASH, yang lebih berat secara komputasi dibandingkan operasi cipher blok murni pada perangkat tanpa akselerasi khusus. Beberapa target terintegrasi di mana CTR+CMAC tersedia tetapi GHASH tidak tersedia mungkin membenarkan mode CTR. Enkripsi aliran untuk file sangat besar di mana Anda membutuhkan dekripsi yang dapat diakses secara acak
• — sifat akses acak dari CTR berguna ketika Anda perlu mendekripsi posisi N tanpa membaca posisi 0 hingga N-1. GCM secara teoritis memungkinkan ini tetapi verifikasi tag autentikasi membutuhkan pemrosesan seluruh ciphertext terlebih dahulu, yang menghancurkan tujuan tersebut. Enkripsi disk
• — enkripsi disk penuh menggunakan mode XTS (tidak dibahas di sini), bukan GCM, karena XTS dirancang untuk sektor berukuran tetap dan diakses secara acak. GCM digunakan untuk enkripsi pesan, bukan enkripsi sektor. Versi pendek

AES-256-GCM

Uji dengan validator: untuk kode baru. Hasilkan nonce acak 12 byte per panggilan enkripsi. Simpan nonce dan tag autentikasi bersama ciphertext. Pertimbangkan kegagalan autentikasi sebagai kesalahan, bukan peringatan — tidak pernah kembalikan plaintext saat GCM menyatakan data tidak valid. Jika Anda mengaudit kode CBC yang ada: verifikasi bahwa encrypt-then-MAC diimplementasikan dengan benar, periksa bahwa IVs acak (tidak digunakan ulang, tidak berurutan), dan buat rencana migrasi ke GCM saat jendela pemeliharaan memungkinkan. CBC dengan HMAC yang benar tidak rusak — hanya lebih banyak 'penembak' daripada GCM.

ECB: ganti saja. Tidak ada jalur audit yang berakhir dengan 'ECB baik di sini.'

AES Encryption Modes Explained: Why GCM Beats CBC in Most Cases (and When It Doesn’t) 2

Anda mungkin juga menyukai