- Local-first yazılımda işbirlikçi belgelerin güvenliğini korumak için homomorfik şifreleme ve CRDT'ler birleştiriliyor
- Uçtan uca şifreleme tek başına sunucunun verileri birleştirmesine izin vermediğinden, senkronizasyon ve güncelleme verimliliğinde kısıtlar ortaya çıkıyor
- Homomorfik şifreleme, sunucunun içeriği bilmeden CRDT güncellemelerini birleştirebilmesini sağlayan bir program yürütme tekniği
- Ancak homomorfik şifrelemenin temel sınırlamaları (performans düşüşü, alan ve hesaplama maliyetinin artması, kodun en kötü durum davranışına ihtiyaç duyması) nedeniyle pratik uygulamada ciddi zorluklar bulunuyor
- CRDT'ler ile güvenli hesaplamanın bir arada var olabilmesi için çeşitli yaklaşımlar araştırılıyor ve hâlâ tam bir çözüm aranıyor
Local-first ve güvenli işbirliğinin zorlukları
- Uzak işbirliğinde belgeler local-first yaklaşımıyla CRDT içinde saklanıyor, ardından senkronizasyon yoluyla ortak düzenleme deneyimi sunuluyor
- Belge içeriğinin uygulama geliştiricileri gibi üçüncü taraflara kesinlikle gösterilmemesi gereken güvenlik gereksinimlerinde, yaygın yöntem olarak uçtan uca şifreleme kullanılıyor
- Uçtan uca şifreleme basit çalışsa da, senkronizasyon sunucusu verileri birleştiremediği için uzun süre asenkron çalışıldığında verimsiz veri iletişimi ortaya çıkıyor
Homomorfik şifreleme nedir?
- Homomorfik şifreleme, şifrelenmiş veri üzerinde doğrudan algoritma çalıştırmayı mümkün kılan özel bir şifreleme yöntemi
- Bu sayede senkronizasyon sunucusu, verinin içeriğini bilmeden CRDT güncelleme birleştirmesi yapabiliyor
- Homomorfik şifrelemede desteklenen işlem türlerine göre kısmi homomorfik (yalnızca toplama veya çarpmadan biri), bir ölçüde homomorfik / katmanlı homomorfik (ikisinin de sınırlı sayıda uygulanabildiği) ve tam homomorfik (sınırsız) olarak ayrılıyor
- İşlem arttıkça şifreli metinde gürültü birikiyor ve çözme zorlaştığı için bootstrapping gibi gelişmiş teknikler gerekiyor
- Şifrelenmiş bit (0/1) düzeyinde XOR, AND gibi temel işlem kapılarının birleşimiyle genel amaçlı Boolean devreleri uygulanabiliyor
Gerçek homomorfik şifreleme CRDT uygulama örneği
- Rust tabanlı TFHE-rs kütüphanesiyle, temsilî bir CRDT olan Last Write Wins Register homomorfik şifreleme ile uygulanmış
- Düz metin struct'ı ile şifreli struct'ın alanları ve metotları (şifreleme/şifre çözme) neredeyse aynı olsa da, asıl birleştirme mantığında önemli farklar ortaya çıkıyor
- if/else, match gibi yapılardaki yürütme yolu dallanmaları şifreli verinin çözümüne dair ipucu verebileceğinden, şifreli ortamda tüm dalların ve döngülerin hemen değerlendirilmesi zorunlu hale geliyor
- Başlıca koşul karşılaştırmaları ve birleştirme işlemlerinin tamamı bit düzeyinde FheBool operatörleri ve
select metodu gibi araçlarla işleniyor; böylece hangi koşulda değerin değiştiği dışarıdan anlaşılamıyor
Homomorfik şifrelemenin temel sınırlamaları
- Şifreleme anahtarı ile veri boyutu arasındaki dengesizlik: örnekte 32 baytlık veri için 123 MB sunucu anahtarı gerekiyor (sıkıştırılsa bile 27 MB); bu da ciddi alan verimsizliği yaratıyor
- Performans düşüşü: homomorfik şifrelenmiş CRDT birleştirmesi, şifrelenmemiş sürüme göre yaklaşık 2 milyar kat daha yavaş ve yaklaşık 1 saniye seviyesinde ölçülmüş
- Döngü ve dallanmalar giriş değerine göre değişirse bilgi sızıntısı oluşabileceğinden, her zaman en kötü durum temel alınarak işlem sayısı ve bellek tüketilmek zorunda
- Örneğin last-write-wins map gibi anahtar-değer yapıları seyrek olsa bile, tüm anahtarlar sabit boyutta tamamen doldurulmuş halde birleştirilmek zorunda olduğundan pratik ölçeklenebilirlik düşüyor
- Şifreli metin yapısı veya değişiklik geçmişinden, değerin değişip değişmediği ya da hangi kısmın güncellendiği konusunda dış gözlemcinin çıkarım yapamaması sağlanacak şekilde tasarım yapılması gerekiyor
Sonuç ve görünüm
- CRDT'ler ve homomorfik şifreleme teoride doğal biçimde birleştirilebilse de, pratikte alan/zaman verimliliği ve program yapısı açısından ölümcül kısıtlar barındırıyor
- Şu an için tam anlamıyla pratik bir çözüm ortaya çıkmış değil; ancak CRDT'ler de nispeten genç bir teknoloji olduğundan sürekli araştırma sürüyor
- Local-first işbirliği uygulamalarında güvenlik ile kullanılabilirlik arasında denge kuracak yenilikçi çözümler için hâlâ olasılık var
1 yorum
Hacker News görüşleri
Tam homomorfik şifreleme alanının gerçekten yavaş ve verimsiz olduğu doğru, ancak bunun 2009'da ortaya çıkmış, nispeten yeni bir alan olduğunu belirtmek isterim; son 15 yıldaki ilerleme gerçekten olağanüstü düzeyde. İlk homomorfik şifreleme şemaları TB/PB düzeyinde anahtarlar gerektiriyordu ve bootstrapping (homomorfik şifrelemede çarpma işlemleri arttığında zorunlu hale gelen işlem) binlerce saat sürüyordu. Şimdi ise anahtarlar 30MB seviyesinde ve bootstrapping 0,1 saniyenin altında yapılabiliyor. Umarım ilerleme sürer ve bir gün pratikte kullanılabilir hale gelir.
İlk dönem CRDT'ler de, WOOT gibi, son derece kullanışsızdı; ama güncel CRDT veritabanları artık sıradan LSM'lere kıyasla performans açısından çok da geri kalmıyor. Örneğin RDX CRDT'leri merge sort benzeri algoritmalarla çalışıyor ve hepsi O(N). Çoğu uygulamada metadata overhead'i de iyi kontrol ediliyor. Bkz. WOOT, librdx, go-rdx
CRDT'lerin mimari özellikleri gereği yavaş olması kaçınılmaz ve en iyi algoritmaların bile yapısal maliyeti yüksek. Buna bir de homomorfik şifreleme eklenince iş çok daha zorlaşıyor. Gerçekten etkileyici ama pratikte kullanılabilir mi emin değilim. Dayanak olarak şu açıklama alıntılanmış: "Sunucunun yeni haritayı hesaplayabilmesi için tüm anahtarları tek tek merge etmesi ve ardından tüm haritayı her peer'e göndermesi gerekiyor — çünkü sunucu açısından tüm harita her seferinde farklı."
CRDT, Conflict-free Replicated Data Type'ın kısaltmasıdır; çakışmasız dağıtık senkronizasyon yapabilen özel bir veri tipidir. Bkz. CRDT Wikipedia bağlantısı
Yazıda performansın yetersiz olduğundan bahsedilen bir bölüm var; gerçekten de M4 MacBook Pro'da last write wins register'ı normal şekilde çalıştırdığınızda merge 0,52 nanosaniye sürerken, homomorfik şifrelemeli sürüm 1,06 saniye sürüyor. Yani işlem hızı arasında 2 milyar kat fark var. Gerçekten sarsıcı bir rakam.
FHE (Full Homomorphic Encryption) gerçekten çok yavaş ama 2009'dan bu yana inanılmaz ilerleme kaydedildi. Sadece bootstrapping hızları bile on milyonlarca kat arttı. tfhe-rs kullanılarak homomorfik şifreleme tabanlı AES-128 bile zaten gösterildi. Yapay zeka çıkarımı/eğitimi için gerçek zamanlı FHE kullanımının giderek daha olası hale geldiğini düşünüyorum. Bkz. tfhe-aes-128 GitHub bağlantısı
Sunucunun artık istemci değişikliklerini anlayamayacağı yönündeki ifadeye katılmıyorum. Sunucu, kullanıcının henüz görmediği değişiklikleri gönderir; kullanıcı da bunları çözüp merge ederek belgenin güncel sürümünü oluşturur. Homomorfik şifreleme ilginç olsa da, makul performans veya bant genişliği gereken durumlarda neredeyse hiç uygun değil. Daha önce, özel CPU+RAM'i şifre içine kodlayıp her clock sinyalinde bir komut işleyen homomorfik şifreleme tabanlı tam gizli hesaplama üzerine bir makale görmüştüm. Gerçekten çalışıyordu ama saniyede yalnızca 1 sanal CPU komutu işleyebiliyordu. Bu hız ve maliyet kabul edilebilir düzeydeyse, ya yerelde çalıştırmak ya da gerçekten çok zenginseniz donanımı satın alıp yerelde işlemek daha mantıklı.
Bilgisayar bilimi ve kriptografi makaleleri çoğu zaman pratiklikten uzak oluyor; örneğin saldırı karmaşıklığını 2^250'den 2^230'a indirmek gibi absürt derecede gerçek dışı çalışmalar çok yaygın. Yine de bunların gerçek Ar-Ge açısından ve mümkün olan alanı genişletmek bakımından anlamı var.
Sunucu içeriği doğrudan işleyemiyorsa CRDT belgelerini birleştiremez; bu durumda her seferinde CRDT'nin tüm durumunu alıp tekrar göndermek zorunda kalır. Arkadaşınız aynı anda çevrimiçiyse işlemler (operations) gönderilerek gerçek zamanlı merge yapılabilir, ama değilse çok verimsiz olur.
Öğrenciler FHE ile şifrelenmiş WASM veya JS notlandırma kodunu JupyterLite ve ottergrader kombinasyonuyla kendi Chromebook'larında doğrudan çalıştırsa bile buna güvenilip güvenilemeyeceğinden emin değilim. Kod imzalama ile SETI@home screensaver arasındaki ilişkinin ne olduğunu da merak ediyorum.
THFE-rs kullanmamak daha iyi olabilir; çünkü Zama, prototip amaçları dışında ticari lisans talep ediyor. Lisans şartları rahatsız edici. Bunun yerine openFHE (C++) ve lattigo (golang) kütüphanelerini öneririm; ikisi de ticari kullanım için serbest.
Bence FHE burada kullanılmak için özünde yanlış araç. FHE, merkezi sunucunun sahip olduğu ya da bildiği verileri işlemek için uygun. Burada ise birden fazla kullanıcının dağıtık verileri birlikte işlemesi gerekiyor; bu yüzden MPC (çok taraflı hesaplama: birden fazla katılımcının kendi gizli verileriyle ortak hesap yapması) çok daha verimli.
Yazıda sunulan varsayımları tam anlayamadım. CRDT ve homomorfik şifreleme kavramlarını biliyorum ama senkronizasyon için neden iki tarafın da aynı anda çevrimiçi olması gerektiğini merak ediyorum. Güncellemeleri eşzamansız olarak ileten bir "store-and-forward" modeli olsa, hareket halindeki veri de şifreli kalabilir; o halde sunucunun neden durum tutması gerekiyor (üstelik şifreli halde) ve neden önerildiği gibi değiştirilmesi gerektiği belirsiz.
FHE'nin yavaşlığı ve verimsizliğiyle CRDT'lerin depolama alanı israfının birleşimi ilginç görünüyor.