Saya sedang membaca beberapa catatan teknis pada suatu malam yang larut, jenis lubang kelinci yang membuat Anda terseret setelah melihat satu tweet yang menarik, dan saya menemukan gagasan ini tentang Newton—bagaimana ia menangani waktu yang bergantung pada rahasia. Reaksi pertama saya jujur saja adalah kebingungan. Lalu rasa ingin tahu. Lalu perasaan lambat yang akhirnya terasa, seperti, "tunggu, ini ternyata jauh lebih penting daripada yang orang kira." Mungkin Anda juga pernah merasakannya: saat menggulir melalui salah satu diskusi rekayasa yang tidak begitu populer dan menyadari bahwa hal-hal yang terdengar membosankan sering kali justru tempat keamanan yang sebenarnya berada.
Timing attacks adalah salah satu hal yang terdengar abstrak sampai Anda benar-benar duduk bersamanya. Gagasan dasarnya adalah: jika sebuah sistem memerlukan waktu yang berbeda tergantung pada data rahasia, seperti kunci privat atau kata sandi, penyerang kadang bisa menginferensikan bit-bit dari rahasia tersebut hanya dengan mengukur seberapa lama operasi berjalan. Itu terdengar hampir terlalu sederhana untuk berhasil. Namun itu telah berfungsi, berulang kali, di sistem-sistem nyata selama puluhan tahun. Jadi ketika sebuah proyek mengklaim mengurangi secret-dependent timing, telinga saya langsung waspada—karena itu bukan bahasa pemasaran, melainkan masalah rekayasa kriptografi yang benar-benar nyata.
Yang menarik bagi saya dari pendekatan Newton adalah bahwa ia tidak memilih solusi brute force yang jelas, yaitu membuat setiap operasi memerlukan jumlah waktu yang persis sama, apa pun kondisinya. Itu terdengar seperti jawaban paling aman di atas kertas: constant time untuk semuanya, bukan? Tapi dalam praktiknya, pendekatan seperti itu mahal. Ia memperlambat semuanya secara keseluruhan, bahkan untuk operasi yang tidak pernah menyentuh apa pun yang sensitif. Pada awalnya, terasa aneh bahwa solusi yang terdengar lebih “aman” justru bisa menjadi yang kurang praktis.
Saya ingat saat pertama kali belajar tentang kriptografi constant time bertahun-tahun lalu. Asumsi yang tertanam dalam banyak penjelasan buku teks adalah bahwa timing yang seragam pada dasarnya adalah standar emas. Setiap cabang dipadding. Setiap loop di-unroll ke panjang yang sama apa pun inputnya. Itu elegan secara teori. Tapi elegan dalam teori dan dapat digunakan dalam jaringan nyata yang memproses ribuan transaksi adalah dua dunia yang sangat berbeda. Siapa pun yang benar-benar pernah mengirimkan kode kripto produksi tahu persis tradeoff-nya.
Jadi pertanyaan yang lebih menarik, yang tampaknya sedang diperjuangkan Newton, adalah bagaimana melindungi secara selektif bagian-bagian dari suatu komputasi yang benar-benar bergantung pada rahasia, tanpa memaksa setiap tugas yang tidak terkait membayar pajak yang sama. Itu jauh lebih sulit daripada yang terdengar. Anda perlu benar-benar mengidentifikasi jalur kode mana yang bergantung pada rahasia dan mana yang tidak, serta disiplin agar batas itu tidak menjadi kabur seiring waktu saat kode berkembang.
Saya bolak-balik memikirkan apakah pendekatan selektif ini benar-benar lebih aman atau hanya lebih efisien dengan risiko sedikit lebih besar yang “dibakar” di dalamnya. Mungkin saya terlalu memikirkan, tetapi ada sesuatu yang tidak nyaman saat menggambar garis dan mengatakan, “hanya bagian ini yang perlu perilaku constant time.” Garis seperti itu bisa bergeser di bawah tekanan, terutama ketika basis kode membesar dan fitur-fitur baru ditempelkan oleh orang-orang yang tidak ada saat threat model awal dirumuskan.
Pada saat yang sama, saya paham mengapa hal ini penting untuk apa pun yang berusaha beroperasi pada skala nyata. Jika Anda menjalankan validator, layanan penandatanganan, atau infrastruktur apa pun yang menangani kunci secara terus-menerus, memangkas padding yang tidak perlu pada operasi yang tidak sensitif bukanlah hal kecil. Kalikan beberapa milidetik keterlambatan yang tidak perlu itu ke jutaan operasi per hari, dan Anda mulai melihat implikasi nyata pada throughput dan biaya. Mudah untuk menganggap beban waktu sebagai kesalahan pembulatan sampai Anda yang membayar tagihan infrastruktur tersebut.
Ada juga lapisan psikologis yang tidak terlalu sering dibahas. Pengembang cenderung bereaksi berlebihan terhadap timing side channel—membungkus semuanya dengan logika constant time karena takut—atau bereaksi terlalu rendah, mengabaikan risikonya sepenuhnya karena terasa teoretis dibanding vektor serangan yang lebih jelas seperti bug reentrancy atau kontrol akses yang buruk. Cara pandang Newton, setidaknya dari yang saya baca, tampaknya mencoba menemukan jalan tengah yang bertumpu pada threat modeling yang benar-benar nyata, bukan paranoia menyeluruh atau pengabaian menyeluruh.
Saya memikirkan sejarah serangan side channel di kripto dan seberapa sering hal itu muncul di tempat-tempat yang tidak terduga. Serangan cache timing pada implementasi AES. Serangan padding oracle pada TLS. Ini bukan keingintahuan akademis yang eksotis; semuanya dieksploitasi di dunia nyata melawan sistem-sistem riil yang dipercaya orang. Jadi ketika seseorang memberi tahu saya sebuah sistem membedakan mana yang benar-benar perlu perlindungan timing yang seragam dan mana yang tidak, saya ingin tahu seberapa percaya diri mereka dalam klasifikasi itu, karena salah menilai—baik dalam arah mana pun—berdampak nyata.
Hal ini juga membuat saya berpikir tentang bagaimana semuanya terhubung dengan tren yang lebih luas dalam infrastruktur kripto menuju model keamanan yang lebih bernuansa, bukan satu ukuran untuk semua. Kita melihatnya pada optimasi gas: kehati-hatian menyeluruh dulu berarti membayar lebih mahal untuk margin keamanan yang tidak selalu diperlukan. Kita melihat hal serupa dalam cara proyek memikirkan audit sekarang—bergeser dari daftar periksa umum menuju threat model yang spesifik untuk apa yang benar-benar dilakukan sebuah protokol. Perlindungan timing yang selektif terasa sebagai bagian dari pematangan yang sama: memperlakukan keamanan sebagai sesuatu yang perlu Anda analisis secara spesifik, bukan menerapkannya secara seragam dan berharap yang terbaik.
Saya akan jujur mengakui bahwa saya belum punya opini teknis yang kuat apakah implementasi spesifik Newton sudah menyeimbangkan hal ini dengan tepat. Saya belum menggali cukup dalam ke kode atau spesifikasi aktual untuk mengambil keputusan secara bertanggung jawab, dan saya lebih memilih mengatakan itu dengan jujur daripada berpura-pura sebaliknya. Yang saya anggap menarik justru cara pandangnya sendiri: gagasan bahwa rekayasa keamanan itu bukan hanya tentang kehati-hatian maksimum di mana-mana, melainkan tentang kehati-hatian yang diterapkan secara tepat di area risiko tersebut benar-benar berada.
Ada versi percakapan ini yang juga membuat tidak nyaman. Perlindungan selektif mengasumsikan bahwa Anda sudah mengidentifikasi setiap jalur yang bergantung pada rahasia hari ini dengan benar, dan asumsi itu tetap berlaku saat sistem berubah besok. Perangkat lunak bisa “membusuk” dengan cara yang aneh. Refactor enam bulan dari sekarang dapat diam-diam memperkenalkan cabang baru yang bergantung pada rahasia, tanpa ada yang menandainya, karena batas awal digambar oleh seseorang yang saat itu berpindah tim. Saya tidak mengatakan itu sebagai kritik spesifik terhadap Newton, lebih sebagai kekhawatiran umum yang saya bawa tentang setiap sistem yang menukar kesederhanaan seragam dengan ketelitian yang ditargetkan.
Yang terus saya ulang-ulang adalah bahwa jenis pekerjaan seperti ini jarang mendapat perhatian di luar lingkaran kecil orang yang memang peduli pada detail implementasi. Sebagian besar percakapan pasar tentang proyek apa pun berfokus pada harga, kemitraan, atau hype roadmap. Sementara itu, postur keamanan yang sebenarnya—hal yang menentukan apakah kunci bocor di bawah analisis yang berkelanjutan—hanya mendapat sebagian kecil dari diskusi yang pantas. Ketidakseimbangan itu selalu sedikit mengganggu saya, meski saya paham kenapa itu terjadi. Grafik harga lebih mudah dibicarakan daripada timing side channel.
Saya tidak merasa ada resolusi yang rapi untuk ditulis di sini, dan jujur saja saya akan curiga pada artikel yang mencoba memberi Anda satu. Mitigasi timing side channel adalah salah satu area di mana tradeoff-nya benar-benar nyata, sejarah kegagalannya terdokumentasi dengan baik, dan solusinya membutuhkan kewaspadaan konstan, bukan perbaikan sekali lalu selesai. Pendekatan Newton yang mempersempit cakupan perlindungan constant time alih-alih menerapkannya di mana-mana adalah arah yang masuk akal untuk dieksplorasi, tetapi “masuk akal” tidak sama dengan “terbukti.”
Kalau ada apa pun, lubang kelinci (rabbit hole) ini justru membuat saya punya lebih banyak pertanyaan daripada jawaban—dan mungkin memang begitulah seharusnya dengan rekayasa keamanan. Saya ingin tahu bagaimana semua ini bertahan dalam audit nyata, dalam peninjauan oleh pihak lawan yang secara aktif mencoba membongkarnya, dan di bawah tekanan penggunaan produksi selama bertahun-tahun, bukan hanya berbulan-bulan. Biasanya, di sanalah ide-ide ini benar-benar diuji: bukan saat pengumuman awal, melainkan pada rentang waktu yang sunyi setelahnya, ketika tidak ada yang mengawasi sedetail itu.
