Post-Quantum Cryptography: Kenapa Aplikasi Lo Harus Siap Sebelum 2027

Ada satu ancaman keamanan yang jarang dibicarakan di kalangan developer Indonesia, padahal deadline-nya sudah di depan mata: komputer kuantum yang mampu memecahkan enkripsi yang kita pakai hari ini. Bukan, ini bukan fiksi ilmiah. NIST sudah memfinalisasi standar Post-Quantum Cryptography (PQC) pertamanya pada Agustus 2024, dan badan keamanan Prancis (ANSSI) baru-baru ini mengumumkan akan menolak sertifikasi produk yang belum PQC-ready mulai 2027. Artinya, window untuk migrasi makin sempit.

Saya pertama kali benar-benar memikirkan ini waktu meng-audit sistem pembayaran seorang klien tahun lalu. Data transaksi yang dienkripsi dengan RSA-2048 hari ini, kalau disadap dan disimpan oleh penyerang, bisa didekripsi 10-15 tahun lagi saat komputer kuantum cryptographically-relevant sudah ada. Konsep ini namanya harvest now, decrypt later — dan untuk data yang harus rahasia selama puluhan tahun (rekam medis, rahasia negara, data finansial jangka panjang), ancamannya sudah nyata sekarang.

Artikel ini bukan paper akademis. Saya akan jelaskan apa yang perlu developer dan sysadmin Indonesia ketahui tentang PQC, algoritma mana yang harus dipakai, dan langkah konkret apa yang bisa lo ambil hari ini tanpa harus jadi ahli kriptografi.

1. Apa Sebenarnya Post-Quantum Cryptography Itu

Kriptografi yang kita pakai sekarang terbagi dua keluarga besar. Pertama, kriptografi kunci publik seperti RSA dan Elliptic Curve (ECC/ECDSA) — yang mengamankan TLS handshake, SSH, dan signing. Kedua, kriptografi simetris seperti AES — yang mengenkripsi data sebenarnya.

Berita buruknya: algoritma Shor yang jalan di komputer kuantum cukup besar bisa memecahkan RSA dan ECC secara efisien. Ini yang bikin seluruh infrastruktur kunci publik kita terancam. Berita baiknya: algoritma simetris seperti AES-256 relatif aman — komputer kuantum cuma memangkas kekuatannya setengah (via algoritma Grover), jadi AES-256 tetap setara AES-128, masih sangat kuat.

Jadi fokus PQC adalah mengganti kriptografi kunci publik dengan algoritma yang tahan terhadap serangan kuantum. Algoritma ini tetap jalan di komputer klasik biasa — tidak butuh hardware kuantum untuk memakainya. Ini poin penting yang sering salah dipahami: PQC adalah software upgrade, bukan hardware revolution.

2. Algoritma yang Distandarkan NIST

Setelah kompetisi bertahun-tahun, NIST memfinalisasi tiga standar utama pada 2024 (FIPS 203, 204, 205), dengan satu lagi menyusul:

Algoritma	Standar	Fungsi	Pengganti
ML-KEM (Kyber)	FIPS 203	Key Encapsulation	RSA/ECDH key exchange
ML-DSA (Dilithium)	FIPS 204	Digital Signature	RSA/ECDSA signing
SLH-DSA (SPHINCS+)	FIPS 205	Signature (hash-based)	Backup signature scheme
FN-DSA (Falcon)	(menyusul)	Signature (ring-based)	ECDSA ukuran kecil

Untuk kebanyakan developer, dua yang paling relevan adalah ML-KEM (dulu namanya Kyber, untuk key exchange di TLS) dan ML-DSA (dulu Dilithium, untuk signing). SLH-DSA berbasis hash dan sangat konservatif keamanannya, tapi ukuran signature-nya besar, jadi biasanya dipakai sebagai skema cadangan. Memilih kombinasi yang tepat tergantung pada kebutuhan lo: kecepatan, ukuran kunci, atau margin keamanan ekstra.

Trade-off yang perlu lo tahu: kunci dan signature PQC lebih besar dari ECC. Public key ML-KEM-768 sekitar 1.2KB (bandingkan ECDH P-256 yang cuma 64 byte), dan signature ML-DSA sekitar 2.4KB. Ini berdampak ke ukuran sertifikat TLS dan bandwidth handshake — tapi untuk koneksi broadband modern, dampaknya minimal.

3. Hybrid: Jangan Buang yang Lama Dulu

Ini prinsip yang paling penting dan paling sering diabaikan: jangan langsung ganti total ke PQC. Praktik terbaik saat ini adalah hybrid cryptography — jalankan algoritma klasik DAN PQC secara bersamaan. Kenapa? Karena algoritma PQC masih relatif baru dan belum teruji waktu selama RSA/ECC. Kalau ternyata ada kelemahan tersembunyi di ML-KEM, lo masih terlindungi oleh ECDH klasik.

Di TLS 1.3, hybrid ini diimplementasikan sebagai X25519MLKEM768 — kombinasi X25519 (ECC klasik) dengan ML-KEM-768. Chrome dan Firefox sudah mengaktifkan hybrid PQC di TLS secara default sejak 2024. Jadi kalau lo mengunjungi situs yang servernya support, koneksi lo sebenarnya sudah hybrid post-quantum. Server-side yang belum tentu siap — dan di situlah tugas lo sebagai developer.

4. Cara Mulai di Server: OpenSSL dan nginx

Dukungan PQC di ekosistem server sudah matang. OpenSSL 3.5 (rilis April 2025) sudah menyertakan ML-KEM, ML-DSA, dan SLH-DSA sebagai provider bawaan, plus support hybrid key exchange di TLS 1.3. Ini berarti lo bisa mengaktifkan PQC di nginx tanpa patch aneh-aneh.

Langkah praktis yang saya lakukan di server uji coba:

1. Upgrade OpenSSL ke 3.5+ (di Ubuntu 24.04 mungkin perlu compile dari source atau pakai PPA, karena versi repo masih 3.0.x).
2. Generate sertifikat dengan ML-DSA: openssl req -new -newkey mldsa65 -x509 ... untuk testing, atau tetap pakai ECDSA untuk kompatibilitas sambil mengaktifkan hybrid key exchange.
3. Di nginx, pastikan ssl_ecdh_curve dan grup TLS mengizinkan X25519MLKEM768.
4. Test dengan openssl s_client atau tool seperti oqs-test untuk verifikasi handshake PQC berhasil.

Untuk hardening TLS secara umum (cipher suite, HSTS, protocol version), pendekatan yang saya pakai tetap sama dengan yang saya tulis di panduan TLS Let's Encrypt self-hosted — PQC adalah layer tambahan di atas fondasi TLS yang sudah benar, bukan pengganti fondasi itu.

5. Library untuk Aplikasi Lo

Kalau lo membangun aplikasi yang melakukan kriptografi sendiri (signing token, enkripsi data at rest), ini peta library yang sudah support PQC:

• liboqs (Open Quantum Safe) — library C reference, basis dari hampir semua implementasi lain. Ada binding untuk Python, Go, Rust, Java.
• Go — crypto/tls di Go 1.24+ sudah support hybrid ML-KEM. Untuk signing, pakai github.com/cloudflare/circl.
• Rust — crate pqcrypto dan rustls (dengan feature post-quantum) sudah production-ready.
• Python — oqs-python atau pynacl untuk binding. Untuk kebanyakan kasus, lebih baik rely ke TLS di level transport daripada implementasi sendiri.
• Java — Bouncy Castle sudah menyertakan algoritma PQC NIST.

Saran saya: kecuali lo punya kebutuhan spesifik, jangan implementasikan kriptografi di level aplikasi. Aktifkan PQC di level TLS/transport dan biarkan library yang sudah diaudit menangani detailnya. Kriptografi yang di-roll sendiri adalah sumber bug keamanan paling umum.

6. SSH Juga Perlu Di-upgrade

SSH bukan cuma TLS. OpenSSH 9.0+ sudah support sntrup761x25519-sha512 (hybrid PQC) sebagai key exchange default, dan OpenSSH 9.9+ menambah support mlkem768x25519-sha256. Kalau lo manage banyak server, memastikan SSH pakai key exchange PQC adalah quick win yang sering terlupakan.

Untuk signing key SSH, lo bisa mulai generate key berbasis ML-DSA di OpenSSH versi terbaru. Tapi ingat kompatibilitas: kalau lo pakai key PQC murni, lo tidak bisa login dari client OpenSSH lama. Hybrid atau tetap ED25519 untuk key auth sambil mengaktifkan PQC di key exchange adalah pendekatan paling pragmatis saat ini. Detail hardening SSH lebih lanjut ada di panduan hardening SSH Ubuntu saya.

7. Prioritas: Data Mana yang Harus Duluan?

Tidak semua data punya urgensi yang sama. Cara saya memprioritaskan migrasi PQC untuk klien:

Jenis Data	Umur Kerahasiaan	Urgensi PQC
Rahasia negara / militer	30+ tahun	Kritis — sekarang
Rekam medis, data genetik	Seumur hidup	Tinggi
Data finansial jangka panjang	10-20 tahun	Tinggi
Kredensial / password hash	Sampai rotasi	Sedang
Session token, data ephemeral	Jam-hari	Rendah

Prinsipnya: data yang harus tetap rahasia melampaui timeline munculnya komputer kuantum cryptographically-relevant (diperkirakan 2030-an, tapi bisa lebih cepat) adalah prioritas utama. Token sesi yang expired besok tidak perlu PQC hari ini.

8. Crypto Agility: Desain untuk Ganti Algoritma

Pelajaran terbesar dari transisi PQC: jangan hardcode algoritma kriptografi di aplikasi lo. Desain sistem dengan crypto agility — kemampuan untuk mengganti algoritma tanpa rewrite besar. Praktiknya: simpan identifier algoritma bersama data terenkripsi, abstraksi di balik interface, dan jangan asumsikan ukuran kunci/signature yang tetap.

Saya pernah melihat sistem yang harus migrate dari MD5 ke SHA-256 dan itu menyakitkan karena hash algorithm di-hardcode di puluhan tempat. Jangan ulangi kesalahan itu untuk PQC. Kalau lo desain dengan agility sekarang, transisi berikutnya (apapun itu) akan jauh lebih murah.

9. Mengukur Kesiapan: Post-Quantum Readiness Assessment

Sebelum mulai migrasi, lo perlu tahu di mana posisi lo sekarang. Saya biasanya melakukan cryptographic inventory dulu: daftar semua tempat kriptografi dipakai di sistem. Ini lebih sulit dari yang terdengar — kriptografi sering tersembunyi di dependency, library pihak ketiga, dan konfigurasi yang tidak lo tulis sendiri. Banyak tim kaget saat menyadari betapa banyak titik kriptografi yang selama ini tidak pernah mereka sentuh atau audit.

Checklist assessment yang saya pakai: inventaris semua sertifikat TLS dan algoritma signing-nya, daftar library kriptografi di setiap service (cek package.json, go.mod, requirements.txt), identifikasi data yang dienkripsi at rest dan algoritmanya, cek versi OpenSSL/OpenSSH di semua server, dan petakan data mana yang butuh kerahasiaan jangka panjang. Dari inventory ini, lo bisa bikin roadmap migrasi yang terprioritas — mulai dari data paling sensitif dan komponen paling mudah di-upgrade.

Ada juga tool otomatis yang membantu. openssl list -providers menunjukkan algoritma PQC yang tersedia. Untuk codebase, ada scanner yang bisa mendeteksi pemakaian algoritma rentan kuantum. Dan jangan lupa dependency tidak langsung — library yang lo pakai mungkin memanggil kriptografi di dalamnya. Prinsipnya sama dengan audit keamanan biasa: lo tidak bisa mengamankan (atau meng-upgrade) apa yang tidak lo ketahui keberadaannya. Inventory dulu, baru migrasi.

Kesimpulan

Post-Quantum Cryptography bukan masalah masa depan — deadline-nya sudah di depan mata, dengan ANSSI menolak produk non-PQC mulai 2027 dan NIST standar yang sudah final sejak 2024. Ancaman harvest-now-decrypt-later nyata untuk data berumur panjang. Kabar baiknya: PQC adalah software upgrade yang bisa lo mulai hari ini. Aktifkan hybrid key exchange di TLS (OpenSSL 3.5+, nginx), upgrade SSH ke OpenSSH 9.9+, pakai library yang sudah diaudit, dan yang terpenting — desain aplikasi lo dengan crypto agility. Mulai dari data paling sensitif, gunakan hybrid (jangan buang algoritma klasik dulu), dan jangan tunggu sampai komputer kuantum benar-benar datang. Saat itu terjadi, sudah terlambat untuk data yang sudah disadap hari ini.