- Dalam perangkat lunak local-first, Homomorphic Encryption dan CRDTs digabungkan untuk menjaga keamanan dokumen kolaboratif
- Enkripsi end-to-end saja tidak memungkinkan server menggabungkan data, sehingga muncul batasan pada efisiensi sinkronisasi dan pembaruan
- Homomorphic Encryption adalah teknologi yang memungkinkan eksekusi program agar server dapat menggabungkan pembaruan CRDT tanpa mengetahui isi datanya
- Namun, karena keterbatasan mendasar Homomorphic Encryption (penurunan performa, peningkatan kebutuhan ruang dan komputasi, kebutuhan agar kode selalu berjalan pada skenario terburuk), terdapat tantangan besar dalam penerapan nyata
- Berbagai pendekatan untuk mewujudkan koeksistensi antara CRDTs dan komputasi aman sedang diteliti, dan solusi yang sepenuhnya tuntas masih terus dicari
Tantangan local-first dan kolaborasi yang aman
- Dalam kolaborasi jarak jauh, dokumen disimpan sebagai CRDT dengan pendekatan local-first, lalu pengalaman penyuntingan bersama diberikan melalui sinkronisasi
- Jika ada kebutuhan keamanan bahwa isi dokumen sama sekali tidak boleh terekspos ke pihak ketiga seperti pengembang aplikasi, maka enkripsi end-to-end adalah pendekatan yang umum digunakan
- Enkripsi end-to-end memang sederhana, tetapi karena server sinkronisasi tidak dapat menggabungkan data, kerja asinkron dalam jangka lama akan menimbulkan komunikasi data yang tidak efisien
Apa itu Homomorphic Encryption?
- Homomorphic Encryption adalah bentuk enkripsi khusus yang memungkinkan algoritme dijalankan langsung pada data terenkripsi
- Dengan memanfaatkannya, server sinkronisasi dapat melakukan penggabungan pembaruan CRDT tanpa mengetahui isi data
- Berdasarkan jenis operasi yang didukung, Homomorphic Encryption dibagi menjadi partially homomorphic (hanya penjumlahan atau perkalian), somewhat/leveled homomorphic (keduanya tetapi hanya beberapa kali), dan fully homomorphic (tanpa batasan)
- Semakin banyak operasi yang dilakukan, semakin banyak noise yang menumpuk di ciphertext dan membuat dekripsi menjadi sulit, sehingga diperlukan teknik lanjutan seperti bootstrapping
- Pada level bit terenkripsi (0/1), rangkaian gerbang operasi dasar seperti XOR dan AND sudah cukup untuk mengimplementasikan sirkuit Boolean umum
Contoh implementasi CRDT dengan Homomorphic Encryption
- Pustaka berbasis Rust TFHE-rs digunakan untuk mengimplementasikan CRDT representatif bernama Last Write Wins Register dengan Homomorphic Encryption
- Field dan method (enkripsi/dekripsi) pada struct plaintext dan struct terenkripsi hampir sama, tetapi perbedaan penting muncul pada logika merge yang sebenarnya
- Karena percabangan jalur eksekusi seperti if/else dan match dapat memberi petunjuk untuk mendekripsi ciphertext, lingkungan terenkripsi mewajibkan evaluasi langsung atas semua percabangan dan loop
- Perbandingan kondisi utama dan operasi merge semuanya diproses melalui operator FheBool tingkat bit dan method select, sehingga pihak luar tidak dapat mendeteksi pada kondisi apa nilai berubah
Keterbatasan mendasar Homomorphic Encryption
- Ketidakseimbangan ukuran antara kunci enkripsi dan data: pada contoh, data 32 byte memerlukan server key 123MB (bahkan setelah dikompresi masih 27MB), sehingga inefisiensi ruang sangat serius
- Penurunan performa: merge CRDT yang dienkripsi secara homomorfik diukur sekitar 1 detik, kira-kira 2 miliar kali lebih lambat dibanding versi tanpa enkripsi
- Jika loop atau percabangan berubah sesuai nilai input, maka kebocoran informasi dapat terjadi; karena itu, jumlah operasi dan memori harus selalu dikonsumsi berdasarkan skenario terburuk
- Misalnya, pada last-write-wins map dengan key-value yang jarang sekalipun, semua key tetap harus digabungkan dalam ukuran tetap yang terisi penuh, sehingga skalabilitas praktis menurun
- Struktur ciphertext maupun riwayat perubahan harus dirancang agar pengamat eksternal tidak dapat menyimpulkan apakah nilai berubah atau bagian mana yang diperbarui
Kesimpulan dan prospek
- CRDTs dan Homomorphic Encryption secara teoretis dapat dipadukan secara alami, tetapi dalam kenyataannya ada batasan fatal pada efisiensi ruang/waktu serta struktur program
- Sampai saat ini belum ada solusi praktis yang benar-benar matang, tetapi CRDTs sendiri juga merupakan teknologi yang relatif muda dan masih menjadi bidang riset berkelanjutan
- Dalam aplikasi kolaborasi local-first, kemungkinan solusi inovatif untuk menyeimbangkan keamanan dan kegunaan masih tetap terbuka
1 komentar
Komentar Hacker News
Memang benar bahwa bidang fully homomorphic encryption sangat lambat dan tidak efisien, tetapi perlu disebutkan bahwa bidang ini sendiri merupakan area yang relatif baru yang muncul pada 2009; perkembangan selama 15 tahun terakhir benar-benar luar biasa. Skema homomorphic encryption pertama membutuhkan kunci sebesar TB/PB, dan bootstrapping (operasi yang wajib ketika operasi perkalian dalam homomorphic encryption menjadi banyak) memerlukan ribuan jam. Sekarang kuncinya berada di kisaran 30MB, dan bootstrapping bisa dilakukan dalam kurang dari 0,1 detik. Saya berharap bidang ini terus berkembang hingga suatu hari bisa dipakai secara praktis.
CRDT awal (CRDT: Conflict-free Replicated Data Type) juga sangat tidak praktis, seperti WOOT, tetapi database CRDT modern saat ini performanya tidak jauh tertinggal dibanding LSM biasa. Misalnya, RDX CRDT bekerja dengan algoritme yang mirip merge sort sehingga semuanya O(N). Pada sebagian besar implementasi, overhead metadata juga terkontrol dengan baik. Lihat WOOT, librdx, go-rdx.
Karena karakteristik arsitektur CRDT, sistem ini memang tidak bisa tidak menjadi lambat, dan bahkan algoritme terbaik pun secara struktural mahal. Jika ditambah homomorphic encryption, tingkat kesulitannya jadi jauh lebih tinggi. Ini memang sangat mengesankan, tetapi saya penasaran apakah benar-benar layak dipakai. Sebagai dasar untuk klaim tersebut, dikutip penjelasan: "agar server dapat menghitung map baru, ia harus menggabungkan semua key satu per satu, lalu mengirim seluruh map ke setiap peer—karena dari sudut pandang server, seluruh map selalu berbeda setiap saat."
CRDT adalah singkatan dari Conflict-free Replicated Data Type, yaitu tipe data khusus yang memungkinkan sinkronisasi terdistribusi tanpa konflik. Lihat tautan Wikipedia CRDT.
Ada bagian artikel yang menyebut performanya kurang memadai; pada praktiknya, jika register last write wins dijalankan secara biasa di M4 MacBook Pro, merge memerlukan 0,52 nanodetik, tetapi versi homomorphic encryption memerlukan 1,06 detik. Artinya, kecepatan operasinya berbeda 2 miliar kali. Angka ini benar-benar mengejutkan.
FHE(Full Homomorphic Encryption) memang sangat lambat, tetapi sejak 2009 sudah ada kemajuan yang menakjubkan. Kecepatan bootstrapping saja sudah meningkat puluhan juta kali. Dengan tfhe-rs, AES-128 berbasis homomorphic encryption juga sudah pernah didemonstrasikan. Saya merasa kemungkinan adopsi FHE real-time untuk inferensi/pelatihan AI makin meningkat. Lihat tautan GitHub tfhe-aes-128.
Saya tidak setuju dengan pernyataan bahwa server tidak lagi bisa memahami perubahan milik klien. Server cukup mengirim perubahan yang belum dilihat pengguna, lalu pengguna mendekripsi dan menggabungkannya untuk membentuk versi terbaru dokumen. Homomorphic encryption memang menarik, tetapi hampir tidak cocok untuk situasi yang memerlukan performa atau bandwidth yang masuk akal. Dulu saya pernah melihat makalah tentang komputasi sepenuhnya rahasia berbasis homomorphic encryption (CPU+RAM kustom dienkode sebagai cipher, lalu satu instruksi diproses pada setiap sinyal clock). Itu memang benar-benar bekerja, tetapi hanya di tingkat sekitar 1 instruksi CPU virtual per detik. Jika kecepatan dan biaya seperti itu masih dianggap dapat diterima, lebih masuk akal menjalankannya secara lokal saja, atau jika benar-benar kaya, membeli perangkat keras sendiri dan memprosesnya secara lokal.
Makalah ilmu komputer dan kriptografi sering kali berisi penelitian yang jauh dari praktis, misalnya hal-hal absurd yang sangat tidak realistis seperti menurunkan kompleksitas serangan dari 2^250 menjadi 2^230. Penelitian seperti ini tetap bermakna untuk R&D nyata atau untuk memperluas batas area yang memungkinkan.
Jika server tidak bisa menangani isi secara langsung, ia tidak bisa menggabungkan dokumen CRDT, dan setiap kali harus menerima lalu mengirim seluruh status CRDT. Jika teman sedang online bersamaan, hasil operasi dapat dikirim sehingga merge real-time dimungkinkan, tetapi jika tidak, ini menjadi sangat tidak efisien.
Saya ragu apakah akan tetap bisa dipercaya jika mahasiswa menjalankan kode penilaian WASM atau JS yang dienkripsi dengan FHE secara langsung di Chromebook mereka melalui kombinasi JupyterLite dan ottergrader. Saya juga penasaran hubungan code signing dengan screensaver SETI@home.
Sebaiknya jangan memakai THFE-rs, karena pihak Zama meminta lisensi komersial untuk penggunaan selain prototipe, dan syarat lisensinya merepotkan. Sebagai gantinya saya merekomendasikan library openFHE(C++) dan lattigo(golang), dan keduanya bisa digunakan bebas untuk keperluan komersial.
Saya rasa FHE pada dasarnya bukan alat yang cocok untuk dipakai di sini. FHE cocok untuk menangani data yang dimiliki atau diketahui oleh server pusat. Di sini, beberapa pengguna harus memproses data terdistribusi bersama-sama, sehingga MPC(multi-party computation: metode komputasi bersama oleh beberapa peserta, misalnya menjumlahkan data rahasia masing-masing) jauh lebih efisien.
Saya kurang memahami asumsi yang diajukan artikel ini. Saya mengerti konsep CRDT dan homomorphic encryption, tetapi saya mempertanyakan mengapa untuk sinkronisasi kedua sisi harus online secara bersamaan. Dengan pendekatan asynchronous "store-and-forward", bukankah data yang sedang transit pun bisa tetap dikirim dalam keadaan terenkripsi? Saya penasaran mengapa server harus menyimpan state (dan itu pun dalam bentuk terenkripsi), serta mengapa perlu dimodifikasi seperti yang diusulkan.
Menarik melihat kelambatan dan inefisiensi FHE berpadu dengan pemborosan ruang penyimpanan CRDT.