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 dipakai hari ini. Bukan fiksi ilmiah. NIST sudah memfinalisasi standar Post-Quantum Cryptography (PQC) pertamanya pada Agustus 2024, dan badan keamanan siber Prancis (ANSSI) merekomendasikan transisi penuh ke algoritma PQC melalui posisi resmi yang diterbitkannya mulai 2022. Artinya, window untuk migrasi makin sempit.

Skenario nyata yang sering diabaikan: 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 disebut 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, melainkan panduan praktis tentang apa yang perlu developer dan sysadmin Indonesia ketahui soal PQC, algoritma mana yang harus dipakai, dan langkah konkret yang bisa diambil hari ini tanpa harus menjadi ahli kriptografi.

Apa Itu Post-Quantum Cryptography dan Kenapa Harus Peduli Sekarang?

Kriptografi yang dipakai sekarang terbagi dalam 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 berjalan di komputer kuantum cukup besar bisa memecahkan RSA dan ECC secara efisien. Inilah yang membuat seluruh infrastruktur kunci publik terancam. Berita baiknya: algoritma simetris seperti AES-256 relatif aman — komputer kuantum hanya 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 berjalan di komputer klasik biasa — tidak butuh hardware kuantum untuk memakainya. Ini poin penting yang sering salah dipahami: PQC adalah software upgrade, bukan hardware revolution.

Seberapa Nyata Ancaman Komputer Kuantum?

Komputer kuantum yang cukup kuat untuk memecahkan RSA-2048 (cryptographically-relevant quantum computer) belum ada hari ini. Estimasi mainstream menyebut 2030-an, tapi sejarah menunjukkan perkiraan semacam ini sering meleset ke arah yang lebih cepat. Yang lebih penting dari kapan komputer itu lahir adalah fenomena yang sudah terjadi sekarang: harvest now, decrypt later.

Penyerang dengan akses ke traffic terenkripsi — misalnya lewat server proxy, DNS, atau jaringan yang disusupi — bisa menyimpan data itu sekarang dan mendekripsinya nanti saat komputer kuantum tersedia. Untuk data dengan umur kerahasiaan 10-30 tahun (rekam medis, data genetik, rahasia negara, data finansial), eksposurnya sudah terjadi hari ini, bukan 2035. Inilah alasan utama kenapa migrasi PQC tidak bisa menunggu sampai komputer kuantum benar-benar hadir.

Regulator mulai merespons. ANSSI merekomendasikan periode transisi hingga 2030, dan setelah itu sistem baru sebaiknya hanya menggunakan algoritma PQC. NIST mendorong migrasi sistem federal AS ke PQC dengan target bertahap hingga 2030-an. Bagi perusahaan Indonesia yang melayani klien luar negeri, atau yang datanya tunduk pada regulasi internasional, ini bukan isu akademis — ini kepatuhan.

Algoritma Apa yang Sudah 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: kecepatan, ukuran kunci, atau margin keamanan ekstra.

Berapa Besar Dampak Ukuran Kunci dan Signature PQC?

Trade-off yang perlu dipahami: 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.

Dampak yang lebih nyata ada di tiga tempat. Pertama, sertifikat TLS: sertifikat dengan kunci ML-DSA akan lebih besar, jadi pastikan server tidak memotong chain sertifikat secara agresif. Kedua, handshake latency: paket ClientHello dan ServerHello membesar, yang terasa di koneksi lambat atau mobile. Ketiga, storage: kalau ribuan kunci publik disimpan (misalnya untuk device identity), kebutuhan storage naik signifikan. Semua ini manageable — tapi sebaiknya diukur di lingkungan masing-masing sebelum migrasi massal.

Hybrid: Kenapa Jangan Langsung Buang Algoritma Lama?

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, pengguna masih terlindungi oleh ECDH klasik.

Di TLS 1.3, hybrid ini diimplementasikan sebagai X25519MLKEM768 — kombinasi X25519 (ECC klasik) dengan ML-KEM-768. Chrome (mulai 2023) dan Firefox (mulai 2024) sudah mengaktifkan hybrid PQC di TLS secara default. Jadi situs yang servernya mendukung X25519MLKEM768 otomatis memakai koneksi hybrid post-quantum bagi pengunjung yang browsernya mendukung. Server-side yang belum tentu siap — dan di situlah tugas developer.

Bagaimana Cara Mulai di Server dengan OpenSSL 3.5?

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 PQC bisa diaktifkan di nginx tanpa patch aneh-aneh.

Langkah praktis yang umum dilakukan 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.

# Cek provider PQC yang tersedia di OpenSSL 3.5+
openssl list -providers

# Generate key + cert ML-DSA untuk testing
openssl req -new -newkey mldsa65 -x509 -nodes \
  -keyout mldsa-key.pem -out mldsa-cert.pem -days 365

Kalau VPS uji coba belum tersedia, sewa instance murah seperti RackNerd — cukup untuk testing handshake PQC tanpa mengganggu environment produksi.

Bagaimana Mengaktifkan Hybrid PQC di nginx?

Setelah OpenSSL 3.5 terpasang, konfigurasi nginx relatif simpel. Kuncinya ada di directive ssl_ecdh_curve yang mengontrol grup key exchange yang ditawarkan ke client:

# /etc/nginx/conf.d/pqc.conf
ssl_protocols TLSv1.3;
ssl_ecdh_curve X25519MLKEM768:X25519:secp256r1;
ssl_ciphers TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256;

Urutan di ssl_ecdh_curve menentukan preferensi — menaruh X25519MLKEM768 pertama berarti server menawarkan hybrid PQC lebih dulu, dengan fallback ke X25519 murni untuk client lama yang belum support. Inilah esensi hybrid: client modern dapat perlindungan PQC, client lama tetap bisa connect.

Setelah konfigurasi, verifikasi handshake dari luar dengan openssl s_client -groups atau cek di Chrome devtools (Security tab) apakah koneksi menunjukkan grup X25519MLKEM768. Untuk hardening TLS secara umum (cipher suite, HSTS, protocol version), pendekatan yang dipakai tetap sama dengan yang tertulis di panduan TLS Let's Encrypt self-hosted — PQC adalah layer tambahan di atas fondasi TLS yang sudah benar, bukan pengganti fondasi itu.

Library Apa yang Sudah Mendukung PQC di Aplikasi?

Kalau aplikasi melakukan kriptografi sendiri (signing token, enkripsi data at rest), ini peta library yang sudah mendukung 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 umum: kecuali ada 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.

Apakah 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. Bagi yang mengelola banyak server, memastikan SSH memakai key exchange PQC adalah quick win yang sering terlupakan:

# Cek key exchange yang didukung server SSH
ssh -Q kex

# Output yang bagus harus memuat salah satu dari:
#   sntrup761x25519-sha512   (OpenSSH 9.0+)
#   mlkem768x25519-sha256    (OpenSSH 9.9+)

Untuk signing key SSH, key berbasis ML-DSA bisa digenerate di OpenSSH versi terbaru. Tapi ingat kompatibilitas: kalau key PQC murni dipakai, client OpenSSH lama tidak bisa login. 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 server Ubuntu.

Data Mana yang Harus Diprioritaskan Duluan?

Tidak semua data punya urgensi yang sama. Berikut urutan prioritas migrasi PQC berdasarkan umur kerahasiaan data:

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.

Apa Itu Crypto Agility dan Kenapa Penting?

Pelajaran terbesar dari transisi PQC: jangan hardcode algoritma kriptografi di aplikasi. 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.

Banyak sistem pernah harus migrate dari MD5 ke SHA-256 dan itu menyakitkan karena hash algorithm di-hardcode di puluhan tempat. Kesalahan yang sama tidak perlu diulang untuk PQC. Kalau sistem didesain dengan agility sekarang, transisi berikutnya (apapun itu) akan jauh lebih murah.

Bagaimana Mengukur Kesiapan (Post-Quantum Readiness Assessment)?

Sebelum mulai migrasi, perlu diketahui posisi saat ini. Langkah pertama yang umum dilakukan adalah cryptographic inventory: 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 ditulis sendiri. Banyak tim kaget saat menyadari betapa banyak titik kriptografi yang selama ini tidak pernah mereka sentuh atau audit.

Checklist assessment yang umum dipakai: 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, roadmap migrasi yang terprioritas bisa disusun — 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 dipakai mungkin memanggil kriptografi di dalamnya. Prinsipnya sama dengan audit keamanan biasa: sistem tidak bisa mengamankan (atau meng-upgrade) apa yang keberadaannya tidak diketahui. Inventory dulu, baru migrasi.

Setelah inventory, pastikan juga infrastruktur terpantau. Migrasi PQC menyentuh TLS, SSH, dan layanan network lain — kalau ada yang salah konfigurasi, perlu diketahui sebelum user yang melapor. Setup monitoring server dengan Netdata + Grafana bisa membantu mendeteksi anomali handshake dan sertifikat sejak dini.

FAQ: Pertanyaan yang Sering Diajukan

Apakah PQC butuh hardware baru? Tidak. Semua algoritma PQC yang distandarkan NIST berjalan di CPU klasik biasa. Ini murni software upgrade — library, TLS stack, dan tooling. Satu-satunya trade-off adalah ukuran kunci dan CPU overhead yang lebih besar dari ECC, tapi untuk workload modern dampaknya kecil.

Kapan komputer kuantum benar-benar datang? Estimasi mainstream untuk komputer kuantum cryptographically-relevant adalah 2030-an, tapi perkiraan ini sering berubah dan bisa maju. Yang tidak perlu ditunggu adalah risiko harvest now, decrypt later — data yang disadap hari ini sudah terancam, jadi migrasi dimulai sekarang untuk data berumur panjang.

Apakah AES-256 aman dari komputer kuantum? Ya, relatif aman. Algoritma Grover hanya memangkas kekuatan AES-256 menjadi setara AES-128 — masih jauh di luar kemampuan brute-force praktis. Fokus migrasi PQC ada di kunci publik (RSA/ECC), bukan simetris.

Apakah PQC sudah bisa dipakai di production? Untuk key exchange di TLS, ya — mode hybrid (X25519MLKEM768) sudah default di Chrome dan Firefox, dan OpenSSL 3.5 + OpenSSH 9.9 sudah mendukungnya. Untuk signing sertifikat, tetap gunakan ECDSA/RSA di production sambil menguji ML-DSA, karena kompatibilitas CA dan client lama masih bertahap.

Kesimpulan

Post-Quantum Cryptography bukan masalah masa depan — ANSSI merekomendasikan sistem baru hanya memakai PQC setelah 2030, dan standar NIST sudah final pada 2024. Ancaman harvest-now-decrypt-later nyata untuk data berumur panjang. Kabar baiknya: PQC adalah software upgrade yang bisa dimulai 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 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. Dan untuk infrastruktur uji coba, VPS murah seperti RackNerd cukup untuk mulai bereksperimen dengan PQC tanpa risiko di environment produksi.

Sumber dan Validasi

Artikel ini disusun berdasarkan standar resmi NIST (FIPS 203/204/205), dokumentasi OpenSSL 3.5, catatan rilis OpenSSH 9.9, laporan Cloudflare tentang adopsi PQC di TLS, serta posisi resmi ANSSI tentang transisi post-quantum. Estimasi timeline komputer kuantum bersifat proyeksi dan mengikuti perkembangan riset terkini.

• Post-Quantum Cryptography FIPS Approved — NIST CSRC
• NIST Releases First 3 Finalized Post-Quantum Encryption Standards (Agustus 2024)
• FIPS 203 (ML-KEM) — NIST CSRC
• OpenSSL 3.5 Release Notes (April 2025)
• OpenSSH 9.9 Release Notes
• The State of the Post-Quantum Internet — Cloudflare Blog (2024)
• ANSSI — FAQ Cryptographie post-quantique (PQC)

Catatan: Seluruh klaim teknis dalam artikel ini — termasuk timeline standar NIST, kebijakan ANSSI, dukungan OpenSSL 3.5 dan OpenSSH 9.9, serta adopsi hybrid PQC di Chrome dan Firefox — divalidasi terhadap sumber resmi yang tercantum di atas. Estimasi timeline komputer kuantum bersifat proyeksi dan bisa berubah seiring perkembangan riset.