Kriptografi untuk Developer: Symmetric, Asymmetric, dan Hashing

"Jangan pernah membuat algoritma kriptografi sendiri" adalah salah satu nasihat paling sering diulang di dunia keamanan siber, dan untuk alasan yang bagus — kriptografi adalah salah satu bidang di mana kesalahan kecil yang terlihat tidak berbahaya bisa meruntuhkan seluruh sistem keamanan. Tapi nasihat ini sering disalahpahami sebagai "developer tidak perlu paham kriptografi sama sekali, cukup pakai library". Padahal justru sebaliknya: developer perlu memahami konsep dasarnya dengan cukup baik untuk tahu library mana yang tepat dipakai, bagaimana memakainya dengan benar, dan yang tidak kalah penting — mengenali kapan sebuah implementasi sudah keliru sejak awal.

Artikel ini adalah pengantar praktis kriptografi untuk developer — bukan untuk membuat Anda ahli kriptografi yang merancang algoritma baru, tapi untuk membuat Anda pengguna kriptografi yang kompeten: memahami symmetric encryption, asymmetric encryption, hashing, dan bagaimana ketiganya bekerja sama dalam sistem nyata seperti TLS, sambil menghindari jebakan implementasi yang paling umum terjadi.

Mengapa Developer Perlu Paham Kriptografi

Hampir setiap aplikasi modern menyentuh kriptografi dalam satu atau lain bentuk: menyimpan password (hashing), mengamankan komunikasi API (TLS), menandatangani token otentikasi (JWT dengan signature), mengenkripsi data sensitif di database, atau memverifikasi integritas file yang diunduh. Kesalahan dalam menerapkan hal-hal ini bukan kesalahan kosmetik — ini bisa berarti password seluruh pengguna bocor dalam bentuk yang mudah dipecahkan, atau komunikasi yang seharusnya rahasia bisa disadap dan dibaca pihak ketiga.

Kabar baiknya, sebagian besar developer tidak perlu memahami matematika di balik algoritma kriptografi secara mendalam. Yang jauh lebih penting adalah memahami properti keamanan yang ditawarkan tiap jenis kriptografi, kapan masing-masing tepat dipakai, dan library standar mana yang sudah teruji untuk mengimplementasikannya dengan benar.

Symmetric Encryption: Kunci yang Sama untuk Enkripsi dan Dekripsi

Symmetric encryption menggunakan kunci yang sama untuk mengenkripsi dan mendekripsi data. Analoginya seperti gembok dengan satu kunci — siapa pun yang punya kunci itu bisa mengunci dan membuka gembok yang sama. Algoritma standar industri saat ini adalah AES (Advanced Encryption Standard), biasanya dengan panjang kunci 256-bit (AES-256), dan ChaCha20 yang populer di lingkungan mobile karena performanya lebih baik pada perangkat tanpa hardware acceleration AES.

Symmetric encryption sangat cepat dan efisien, cocok untuk mengenkripsi data dalam jumlah besar — itulah kenapa ia dipakai untuk enkripsi data at rest (file, database) dan sebagai "workhorse" dalam protokol TLS setelah handshake awal selesai. Kelemahan utamanya: kedua pihak (pengirim dan penerima) harus sama-sama memiliki kunci rahasia yang sama, dan mendistribusikan kunci ini dengan aman ke pihak lain adalah masalah tersendiri yang disebut key distribution problem.

Contoh implementasi AES-256-GCM (mode GCM memberikan enkripsi sekaligus autentikasi/integritas data) menggunakan library standar Node.js:

const crypto = require("crypto");

function encrypt(plaintext, key) {
  const iv = crypto.randomBytes(12); // IV unik untuk setiap enkripsi
  const cipher = crypto.createCipheriv("aes-256-gcm", key, iv);
  const ciphertext = Buffer.concat([
    cipher.update(plaintext, "utf8"),
    cipher.final(),
  ]);
  const authTag = cipher.getAuthTag();
  return { ciphertext, iv, authTag };
}

function decrypt(ciphertext, key, iv, authTag) {
  const decipher = crypto.createDecipheriv("aes-256-gcm", key, iv);
  decipher.setAuthTag(authTag);
  return Buffer.concat([
    decipher.update(ciphertext),
    decipher.final(),
  ]).toString("utf8");
}

Perhatikan penggunaan Initialization Vector (IV) yang unik untuk setiap operasi enkripsi — ini krusial. Menggunakan IV yang sama berulang kali dengan kunci yang sama pada mode seperti GCM bisa membocorkan informasi tentang plaintext, bahkan berpotensi membocorkan kunci autentikasinya. Mode ECB (Electronic Codebook), yang tidak menggunakan IV sama sekali, sebaiknya dihindari sepenuhnya karena pola pada plaintext bisa tetap terlihat pada ciphertext — contoh klasik yang sering dipakai untuk mengilustrasikan ini adalah gambar logo yang dienkripsi dengan ECB tapi bentuk logonya masih bisa dikenali pada hasil enkripsi.

Asymmetric Encryption: Sepasang Kunci yang Berbeda

Asymmetric encryption (juga disebut public-key cryptography) menggunakan sepasang kunci matematis yang saling berkaitan: public key yang bisa disebarluaskan bebas, dan private key yang harus dijaga rahasia. Data yang dienkripsi dengan public key hanya bisa didekripsi dengan private key pasangannya, begitu juga sebaliknya untuk keperluan digital signature.

Algoritma yang umum dipakai: RSA (berbasis kesulitan faktorisasi bilangan besar, umumnya 2048 atau 4096 bit) dan ECC (Elliptic Curve Cryptography) seperti Curve25519 yang menawarkan tingkat keamanan setara dengan ukuran kunci jauh lebih kecil, sehingga lebih efisien secara komputasi dan penyimpanan.

Asymmetric encryption memecahkan masalah key distribution pada symmetric encryption — Anda bisa membagikan public key secara terbuka tanpa risiko, karena hanya pemilik private key yang bisa mendekripsi pesan yang dienkripsi dengannya. Namun, asymmetric encryption jauh lebih lambat dibanding symmetric untuk data besar, sehingga dalam praktik jarang dipakai langsung untuk mengenkripsi payload besar — biasanya hanya dipakai untuk mengenkripsi kunci symmetric yang kemudian dipakai untuk mengenkripsi data sesungguhnya (dikenal sebagai hybrid encryption, persis seperti cara kerja TLS).

Diffie-Hellman Key Exchange

Selain enkripsi langsung, asymmetric cryptography juga memungkinkan dua pihak menyepakati kunci rahasia bersama lewat jaringan yang tidak aman, tanpa pernah mengirim kunci itu sendiri secara eksplisit — ini disebut Diffie-Hellman Key Exchange. Konsep ini jadi dasar bagaimana TLS modern membangun session key symmetric untuk setiap koneksi baru, bahkan dengan properti forward secrecy yang memastikan kompromi satu private key jangka panjang tidak membocorkan percakapan lama yang sudah terjadi sebelumnya.

Hashing: Fungsi Satu Arah untuk Integritas

Hashing sering disalahpahami sebagai bentuk enkripsi, padahal konsepnya berbeda secara fundamental. Fungsi hash mengubah input berukuran berapa pun menjadi output berukuran tetap (disebut hash atau digest), dan proses ini satu arah — tidak ada cara untuk mengembalikan hash menjadi input aslinya (tidak seperti enkripsi yang memang dirancang untuk bisa didekripsi kembali).

Algoritma hash kriptografis yang aman punya beberapa properti penting: deterministic (input sama selalu menghasilkan hash sama), avalanche effect (perubahan sekecil apapun pada input menghasilkan hash yang sangat berbeda), dan collision resistant (sangat sulit menemukan dua input berbeda yang menghasilkan hash sama). Algoritma standar saat ini adalah keluarga SHA-2 (SHA-256, SHA-512) dan SHA-3. Algoritma lama seperti MD5 dan SHA-1 sudah terbukti rentan terhadap collision attack dan tidak boleh lagi dipakai untuk keperluan keamanan (meski MD5 masih kadang dipakai untuk checksum non-keamanan seperti verifikasi integritas file yang diunduh dari sumber tepercaya).

Mengapa Hashing Biasa Tidak Cukup untuk Password

Ini salah satu kesalahan paling umum: menggunakan SHA-256 polos untuk hash password. Masalahnya, fungsi hash umum seperti SHA-256 dirancang untuk cepat — properti yang bagus untuk verifikasi integritas file, tapi justru berbahaya untuk password, karena artinya penyerang yang mendapat database hash password bisa mencoba miliaran kombinasi per detik dengan hardware modern (terutama GPU) untuk brute force atau menggunakan rainbow table.

Untuk password, gunakan fungsi hash yang secara sengaja dibuat lambat dan resource-intensive: bcrypt, scrypt, atau Argon2 (pemenang Password Hashing Competition dan saat ini direkomendasikan sebagai pilihan terbaik oleh OWASP). Fungsi-fungsi ini juga secara otomatis menangani salt — nilai acak unik yang ditambahkan ke setiap password sebelum di-hash, sehingga dua user dengan password sama akan menghasilkan hash yang berbeda, dan mencegah penyerang memakai rainbow table pre-computed.

const argon2 = require("argon2");

async function hashPassword(password) {
  // Argon2id merekomendasikan parameter memory-hardness yang tinggi
  return argon2.hash(password, {
    type: argon2.argon2id,
    memoryCost: 19456, // ~19 MB
    timeCost: 2,
    parallelism: 1,
  });
}

async function verifyPassword(hash, password) {
  return argon2.verify(hash, password);
}

Perhatikan bahwa fungsi verify tidak perlu mengelola salt secara manual — library modern menyimpan salt dan parameter lain langsung di dalam string hash yang dihasilkan, sehingga verifikasi bisa dilakukan tanpa penyimpanan terpisah.

HMAC: Menggabungkan Hashing dengan Kunci Rahasia

HMAC (Hash-based Message Authentication Code) menggabungkan fungsi hash dengan kunci rahasia untuk memverifikasi bahwa sebuah pesan tidak diubah dan berasal dari pihak yang memiliki kunci yang sama — properti yang tidak dimiliki hash biasa (siapa pun bisa menghitung hash SHA-256 dari sebuah pesan, tapi tanpa mengetahui kunci rahasia, tidak ada yang bisa menghitung HMAC yang valid). Ini banyak dipakai untuk memverifikasi keaslian webhook (misalnya payment gateway menandatangani payload webhook dengan HMAC agar penerima bisa memverifikasi permintaan benar-benar berasal dari mereka, bukan pihak yang menyamar), serta sebagai bagian dari algoritma signing token seperti JWT dengan algoritma HS256.

Digital Signature: Autentikasi dan Non-Repudiation

Digital signature memanfaatkan asymmetric cryptography untuk tujuan yang berbeda dari enkripsi: membuktikan keaslian dan integritas sebuah pesan. Prosesnya kebalikan dari enkripsi biasa — pesan (atau lebih tepatnya, hash dari pesan) ditandatangani dengan private key pengirim, dan siapa pun yang punya public key pengirim bisa memverifikasi signature tersebut valid, membuktikan pesan benar berasal dari pemilik private key dan tidak diubah dalam perjalanan.

Digital signature memberikan properti non-repudiation — pengirim tidak bisa menyangkal telah mengirim pesan tersebut, karena hanya mereka yang memiliki private key yang bisa menghasilkan signature valid. Ini jadi fondasi banyak sistem: sertifikat TLS ditandatangani Certificate Authority, commit Git bisa ditandatangani dengan GPG untuk membuktikan keasliannya, dan software release sering ditandatangani agar pengguna bisa memverifikasi file yang diunduh belum dimodifikasi pihak ketiga.

Bagaimana TLS Menggabungkan Ketiganya

TLS (Transport Layer Security), protokol yang mengamankan HTTPS, adalah contoh sempurna bagaimana symmetric encryption, asymmetric encryption, dan hashing bekerja bersama dalam satu sistem:

1. Handshake dimulai — client dan server bertukar informasi kapabilitas kriptografi yang didukung.
2. Autentikasi server (asymmetric + digital signature) — server menunjukkan sertifikat digital yang ditandatangani Certificate Authority tepercaya, client memverifikasi signature ini untuk memastikan benar sedang berkomunikasi dengan server yang sah, bukan penyerang yang melakukan man-in-the-middle.
3. Key exchange (asymmetric, biasanya Diffie-Hellman berbasis elliptic curve) — client dan server menyepakati session key symmetric bersama tanpa pernah mengirim key itu sendiri secara eksplisit di jaringan.
4. Komunikasi data (symmetric, biasanya AES-GCM atau ChaCha20-Poly1305) — setelah handshake selesai, seluruh data aplikasi dienkripsi dengan session key symmetric yang jauh lebih cepat dibanding terus memakai asymmetric encryption.
5. Integritas tiap pesan (HMAC atau AEAD mode seperti GCM) — memastikan data tidak dimodifikasi selama transit.

Pola hybrid ini — asymmetric untuk autentikasi dan key exchange, symmetric untuk bulk data — adalah pola yang berulang di banyak sistem kriptografi praktis lain, bukan hanya TLS.

Kesalahan Umum Implementasi Kriptografi

Encoding Bukan Enkripsi: Kebingungan yang Sering Terjadi

Salah satu miskonsepsi paling umum, terutama di kalangan developer yang baru belajar keamanan, adalah menganggap Base64 sebagai bentuk enkripsi. Padahal Base64 murni skema encoding untuk merepresentasikan data biner dalam format teks yang aman dikirim lewat protokol berbasis teks — tidak ada kunci rahasia yang terlibat, dan siapa pun bisa mendekodekannya kembali ke bentuk asli hanya dengan fungsi decode standar, tanpa memerlukan informasi rahasia apapun.

// Base64 BUKAN enkripsi - siapa pun bisa membalikkannya
const encoded = Buffer.from("password-rahasia").toString("base64");
console.log(encoded); // cGFzc3dvcmQtcmFoYXNpYQ==

// Dekode kembali tanpa perlu kunci apapun
const decoded = Buffer.from(encoded, "base64").toString("utf8");
console.log(decoded); // password-rahasia

Base64 punya kegunaan legitimate — misalnya menyematkan data biner dalam JSON, atau mengirim lampiran lewat protokol email — tapi tidak pernah boleh dianggap sebagai lapisan keamanan. Kesalahan serupa juga sering terjadi dengan URL encoding atau hex encoding yang disalahartikan memberi kerahasiaan, padahal ketiganya murni transformasi representasi data, bukan mekanisme yang menyembunyikan informasi dari pihak yang tidak berwenang.

Key Management: Bagian yang Sering Diabaikan

Algoritma kriptografi yang benar tidak banyak berguna jika key management-nya buruk — seperti mengunci pintu dengan gembok terbaik di dunia tapi menaruh kuncinya di bawah keset. Beberapa prinsip key management yang penting:

• Pisahkan key dari data yang dienkripsi. Jangan simpan encryption key di database yang sama dengan data terenkripsi — jika database bocor, keduanya bocor bersamaan.
• Gunakan key management service. Layanan seperti AWS KMS, Google Cloud KMS, atau HashiCorp Vault menangani penyimpanan, rotasi, dan kontrol akses key secara terpusat dan teraudit.
• Rotasi key secara berkala mengurangi dampak jika sebuah key pernah terkompromi tanpa diketahui.
• Terapkan prinsip least privilege untuk siapa saja yang bisa mengakses key, dan catat log setiap penggunaannya.
• Rencanakan key rotation dan recovery sejak desain awal — sistem yang tidak punya mekanisme rotasi key sering berakhir "terjebak" memakai key lama selamanya karena migrasi terlalu berisiko dilakukan belakangan.

Kesimpulan

Kriptografi untuk developer bukan soal menghafal rumus matematika di balik AES atau RSA, melainkan soal memahami properti keamanan yang ditawarkan tiap alat — symmetric encryption untuk kecepatan dan enkripsi data besar, asymmetric encryption untuk memecahkan masalah distribusi kunci dan autentikasi, hashing untuk integritas dan penyimpanan password yang aman — lalu memakai library standar yang sudah teruji secara benar. Aturan emasnya sederhana: jangan pernah merancang algoritma sendiri, jangan pernah menyimpan password dalam bentuk plaintext atau hash cepat biasa, selalu gunakan CSPRNG untuk apapun yang butuh keacakan kriptografis, dan serahkan pengelolaan key ke sistem yang dirancang khusus untuk itu. Kriptografi yang diimplementasikan dengan benar bekerja diam-diam di latar belakang tanpa pernah disadari user — dan itulah sebenarnya tanda implementasi yang baik: tidak ada yang perlu khawatir karena semuanya sudah ditangani dengan tepat sejak awal.