tools / aes
aes/
Enkripsi dan dekripsi simetris AES. Mode, padding, format kunci dan IV, serta set karakter bisa dipilih. Hasilnya sama dengan Java dan CryptoJS, dan kunci Anda tidak pernah keluar dari browser.
Plaintext
Ciphertext
Riwayat
Setiap enkripsi atau dekripsi yang berhasil otomatis dicatat. Hanya 20 catatan terbaru yang disimpan, dan hanya di browser perangkat ini. Kunci tidak pernah disimpan, tetapi IV dan plaintext hasil dekripsi disimpan, jadi hapus riwayat setelah selesai jika Anda memakai komputer umum.
Apa itu AES, DES, dan RSA, dan apa bedanya
AES dan DES adalah enkripsi simetris: kunci yang sama dipakai untuk mengenkripsi dan mendekripsi, seperti satu kunci yang bisa mengunci sekaligus membuka pintu. Keduanya cepat dan cocok untuk data berukuran besar; kesulitannya ada pada cara mengirim kunci itu ke pihak lain dengan aman.
DES adalah standar lama dari tahun 1970-an dengan panjang kunci efektif hanya 56 bit. Kini perangkat keras khusus atau klaster komputer bisa membobolnya dengan brute force, jadi DES hanya cocok untuk terhubung ke sistem lama yang masih memakainya. AES menggantikan DES sebagai standar. Kuncinya 128, 192, atau 256 bit, saat ini belum ada serangan praktis terhadapnya, dan AES menjadi pilihan utama untuk mengenkripsi data.
RSA adalah enkripsi asimetris: ada sepasang kunci. Kunci publik boleh diberikan kepada siapa saja dan dipakai untuk mengenkripsi; kunci privat Anda simpan sendiri dan dipakai untuk mendekripsi, seperti kotak surat yang bisa dimasuki surat oleh siapa saja tetapi hanya Anda yang punya kuncinya. Keuntungannya, tidak perlu menyepakati kunci terlebih dahulu. Kekurangannya, RSA lambat dan sekali proses hanya bisa mengenkripsi beberapa ratus byte. Sistem sungguhan sering menggabungkan keduanya: RSA mengenkripsi kunci AES acak untuk pihak lain, lalu AES mengenkripsi data yang sebenarnya.
Apa itu mode enkripsi, dan mana yang sebaiknya dipilih?
AES mengenkripsi 16 byte sekali proses; mode menentukan bagaimana data yang lebih panjang dipecah menjadi blok dan bagaimana blok-blok itu dihubungkan. ECB mengenkripsi tiap blok sendiri-sendiri, sehingga isi yang sama menghasilkan ciphertext yang sama dan membocorkan pola data; sebaiknya dihindari. CBC mencampur tiap blok dengan blok ciphertext sebelumnya sebelum dienkripsi, dan blok pertama dicampur dengan IV; ini pilihan yang paling umum. CFB, OFB, dan CTR mengubah AES menjadi aliran kunci (keystream) yang di-XOR dengan data byte demi byte, sehingga tidak perlu padding. GCM menambahkan Tag autentikasi di atas CTR, sehingga ciphertext yang diubah akan gagal didekripsi; inilah mode yang paling disarankan saat ini.
Untuk apa IV dan padding?
IV (initialization vector) membuat isi yang sama menghasilkan enkripsi yang berbeda setiap kali. IV tidak perlu dirahasiakan dan boleh dikirim bersama ciphertext, tetapi jangan pernah memakai IV yang sama dengan kunci yang sama, terutama pada GCM. Semua mode kecuali ECB memerlukan IV: untuk GCM disarankan 12 byte, sedangkan mode lain harus tepat 16 byte.
ECB dan CBC mengharuskan panjang data kelipatan 16 byte, jadi data yang kurang akan diisi sesuai padding yang dipilih. PKCS5Padding dan PKCS7Padding identik untuk AES dan paling umum dipakai. ZeroPadding mengisi dengan nol dan membuang semua byte nol di akhir saat dekripsi, sehingga plaintext yang memang berakhir dengan byte nol ikut terpotong. NoPadding tidak menambah apa pun, jadi Anda harus memastikan panjangnya sendiri. GCM tidak memakai padding.
Padanan dengan penulisan di Java dan CryptoJS
Cipher.getInstance("AES/CBC/PKCS5Padding") di Java berarti CBC dengan PKCS5Padding; jika hanya menulis "AES", defaultnya ECB dengan PKCS5Padding. Di Java, CTR dan GCM hanya bisa memakai NoPadding, dan Tag GCM harus 96 sampai 128 bit. CryptoJS.pad.Pkcs7 di CryptoJS adalah PKCS7Padding, sedangkan ZeroPadding, AnsiX923, Iso10126, dan Iso97971 namanya sama. Jika Anda memberikan passphrase berupa string ke CryptoJS.AES.encrypt, kunci akan diturunkan otomatis dan hasilnya diawali U2FsdGVkX1; cara itu tidak didukung di sini, jadi masukkan kunci 16, 24, atau 32 byte beserta IV.
Apa itu Tag dan AAD pada GCM?
Tag adalah nilai pemeriksa yang dihitung GCM; beberapa byte terakhir hasil enkripsi adalah Tag (16 byte untuk Tag 128 bit). AAD adalah additional authenticated data, misalnya header pesan. AAD tidak dienkripsi tetapi ikut diperiksa, jadi saat dekripsi Anda harus mengisi AAD yang sama, kalau tidak pemeriksaan akan gagal.
Pertanyaan umum
Muncul pesan "Panjang kunci N byte" atau "Panjang IV N byte", apa yang harus dilakukan?
Pertama, periksa apakah formatnya sudah benar: 32 karakter yang sama berukuran 32 byte pada format string, tetapi hanya 16 byte pada format hex. Kunci AES harus 16, 24, atau 32 byte, dan selain ECB dan GCM, IV harus tepat 16 byte. Tidak ada pengisian nol atau pemotongan otomatis, dan jumlah byte saat ini ditampilkan di samping label Kunci dan IV. Pada format string, jumlah byte mengikuti set karakter yang dipilih, jadi satu karakter Mandarin memakai 3 byte di UTF-8. Jika backend Anda lebih dulu memproses passphrase, misalnya dengan mengisi nol atau melakukan hash, hitung dulu byte akhirnya lalu masukkan dalam format hex atau base64.
Apa yang harus dilakukan jika dekripsi menampilkan pesan padding tidak valid?
Artinya blok terakhir hasil dekripsi tidak sesuai dengan aturan padding yang dipilih. Biasanya salah satu dari kunci, IV, mode, atau padding berbeda dengan yang dipakai saat enkripsi, atau ciphertext tersalin tidak lengkap. Bandingkan setiap parameter dengan sisi yang mengenkripsi; format kunci atau format ciphertext (hex atau base64) yang salah juga menimbulkan error yang sama. ZeroPadding dan NoPadding tidak memeriksa padding, jadi tidak akan memunculkan error ini, tetapi hasilnya berupa karakter acak jika parameternya salah.
Awal hasil dekripsi berantakan, atau muncul pesan bahwa hasilnya bukan teks UTF-8 yang valid
Periksa IV lebih dulu. Jika ciphertext lebih panjang dari satu blok, IV yang salah pada mode CBC dan CFB hanya merusak blok 16 byte pertama, sisanya tetap benar dan tidak muncul error padding, sehingga bagian awal berantakan sementara teks sesudahnya benar. Jika pesan menyebutkan hasilnya bukan teks yang valid, set karakter mungkin berbeda dengan yang dipakai saat enkripsi, misalnya pihak lain memakai GBK. Mengubah format output ke hex memungkinkan Anda memeriksa dulu apakah byte hasil dekripsinya sendiri sudah benar.
Apa yang harus dilakukan jika dekripsi GCM menampilkan pesan pemeriksaan Tag tidak lolos?
Artinya salah satu dari kunci, IV, AAD, atau panjang Tag berbeda dengan saat enkripsi, atau ciphertext telah diubah. Byte terakhir input diperlakukan sebagai Tag, dengan panjang sesuai opsi "Panjang Tag" (default 128 bit, yaitu 16 byte), sehingga ciphertext dan Tag harus dimasukkan bersamaan; jika pihak lain memberikan Tag secara terpisah, tambahkan dulu di belakang ciphertext. Format AAD secara default adalah hex, jadi ubah formatnya saat Anda mengisi dengan string, dan jika saat enkripsi tidak memakai AAD, kosongkan juga saat dekripsi.
Hasil enkripsi tidak cocok dengan Java, Python, atau backend lain. Bagaimana cara memeriksanya?
Periksa berurutan: mode dan padding, format dan jumlah byte kunci serta IV, set karakter, lalu format input dan output. Plaintext berformat string tidak dipangkas spasinya, jadi satu baris baru ekstra di akhir sudah membuatnya menjadi data yang berbeda. CTR, CFB, dan OFB di sini juga diberi padding sesuai padding yang dipilih, jadi dengan PKCS5Padding ciphertext lebih panjang daripada plaintext; jika backend memakai NoPadding, pilih NoPadding juga di sini. CFB di sini adalah varian blok penuh 128 bit, jadi tidak akan cocok dengan backend yang memakai CFB8.
Ciphertext sebaiknya hex atau base64, dan apa yang terjadi jika salah memilih?
Ikuti output pihak lain: teks yang hanya terdiri dari 0-9 dan a-f adalah hex, sedangkan teks dengan huruf besar-kecil campuran, +, /, atau = di akhir adalah base64. Salah memilih saat dekripsi tidak selalu langsung gagal, karena setiap karakter hex juga karakter base64 yang valid; Anda hanya mendapat byte yang salah, dan akibatnya muncul belakangan sebagai "bukan kelipatan 16" atau padding tidak valid. Base64 dengan - dan _ (bentuk URL-safe) atau tanpa = tetap diterima, dan spasi, titik dua, serta awalan 0x pada hex diabaikan.
Apa yang disimpan di riwayat, dan apakah diunggah?
Hanya tersimpan di localStorage browser perangkat ini dan tidak pernah diunggah; kode halaman tidak membuat permintaan jaringan apa pun. Satu entri ditambahkan setelah setiap enkripsi atau dekripsi yang berhasil, maksimal 20 entri disimpan, dan input atau hasil yang melebihi 20.000 karakter tidak dicatat. Satu entri berisi parameter, IV, AAD, input, dan hasil, ditambah sidik jari 8 karakter yang diturunkan dari kunci (karakter setelah tanda # di setiap entri, untuk membedakan apakah kuncinya sama), tetapi tidak pernah menyimpan kuncinya, sehingga setelah mengklik "Muat" Anda perlu mengisi kunci lagi. Setiap entri bisa dihapus sendiri-sendiri, dan di komputer umum, klik "Hapus riwayat" setelah selesai.
Bisakah kunci atau IV acak dibuat otomatis?
Tidak bisa. Tidak ada tombol pembuat, jadi kunci dan IV harus Anda isi sendiri. Plaintext, kunci, IV, dan parameter yang sama selalu menghasilkan hasil yang sama; hanya padding ISO10126 yang menyisipkan byte acak sehingga hasilnya berubah. Jika memerlukan nilai acak, buat sendiri, misalnya openssl rand -hex 16 di command line akan mencetak 16 byte, yang bisa Anda masukkan dengan format diatur ke hex.