Kriptografik anahtarları kimliklerle bağlantılı hale getirmek, Gate.io'ya kadar bir sorun olmuştur.teknolojinin tanıtılması. Zorluk, kimlikler ve ilgili özel anahtarlara sahip olan genel anahtarlar arasında halka açık ve tutarlı bir eşleştirme sağlamaktır. Böyle bir eşleştirme olmadan, gizli kalması amaçlanan mesajlar yanlışlıkla açığa çıkabilir - bazen felaketle sonuçlanabilir. Bu zorluk, web3'te de varlığını sürdürmektedir.

Şu anda üç olası çözüm mevcuttur. İki klasik yaklaşım, ortak anahtar dizini ve kimlik tabanlı şifrelemedir. Üçüncüsü, yakın zamana kadar tamamen teorik olan kayıt tabanlı şifrelemedir. Üç yaklaşım, anonimlik, etkileşim ve verimlilik arasında farklı ödünleşimler sunar, bu ilk başta açık görünebilir, ancak blok zinciri ayarı yeni olasılıklar ve kısıtlamalar sunar. O halde bu yazının amacı, bu tasarım alanını keşfetmek ve bir blok zincirinde konuşlandırıldığında bu yaklaşımları karşılaştırmaktır. Kullanıcılar zincir üzerinde şeffaflığa ve anonimliğe ihtiyaç duyduğunda, pratik bir RBE şeması açık ara kazanandır - kimlik tabanlı şifrelemenin güçlü güven varsayımının üstesinden gelir, ancak bunun bir bedeli vardır.

Kısaca Üç Yaklaşım

Kriptografik anahtarları kimliklerle ilişkilendirmenin klasik yaklaşımı, kalbinde bir genel anahtar dizini olan bir genel anahtar altyapısıdır (PKI). Bu yaklaşım, mesaj göndermek için potansiyel bir göndericinin güvenilen üçüncü bir tarafa (dizinin bakıcısı veya sertifika otoritesi) etkileşimde bulunmasını gerektirir. Ek olarak, web2 ortamında bu dizinin korunması maliyetli, sıkıcı ve ...hata eğilimli, ve kullanıcılar risk altına girersertifika yetkilisi tarafından kötüye kullanım.

Kriptograflar, PKI'ların sorunlarını atlatmak için alternatifler önerdiler. 1984 yılında,Adi Shamir önerdi bir tarafın tanımlayıcısının (telefon numarası, e-posta, ENS alan adı) genel anahtar görevi gördüğü kimlik tabanlı şifreleme (IBE). Bu, bir ortak anahtar dizini tutma ihtiyacını ortadan kaldırır, ancak güvenilir bir üçüncü taraf (anahtar oluşturucu) sunma pahasına gelir. Dan Boneh ve Matthew Franklin verdi ilk pratik IBE yapısı2001'de, ancak IBE, kurumsal veya hükümet dağıtımları, belki de güçlü güven varsayımından kaynaklanmıştır. (Aşağıda göreceğimiz gibi, bu varsayım kısmen, bir blok zinciri kolayca kolaylık sağlayabilirken, güvenilir bir kota partiye güvenmek suretiyle hafifletilebilir.)

Üçüncü bir seçenek olan kayıt tabanlı şifreleme (RBE), önerilen2018'de. RBE, güvenilir anahtar üreteciyi şeffaf bir "anahtar muhafızı" ile değiştirerek IBE ile aynı genel mimariyi korur (özellikle, genel anahtarları bir tür halka açık "özet" olarak biriktirir). Bu anahtar muhafızının şeffaflığı, akıllı bir sözleşmenin muhafızın rolünü doldurabileceği blok zinciri ayarına doğal bir uyum sağlar. RBE, ortak yazarlarım ve benim tanıttığım 2022'ye kadar teorikti. ilk pratik olarak etkili RBE yapı.

Ticaret Dengelerini Değerlendirme

Bu tasarım alanı karmaşık ve bu şemaları karşılaştırmak için birçok boyutu dikkate almak gerekir. Daha basit tutmak için, iki varsayım yapacağım:

1. Kullanıcılar anahtarlarını güncellemez veya iptal etmezler.
2. Akıllı sözleşme off-chain veri erişilebilirlik hizmeti (DAS) veya blok verisi kullanmaz.

Her bir ek düşüncenin üç potansiyel çözümümüzü nasıl etkileyebileceğini sonunda tartışacağım.

Genel Anahtar Dizin

Özet: Kimse henüz talep edilmemişse, herhangi biri akıllı kontratı çağırarak (id, pk) girişini zincir üstü bir tabloya (dizin) ekleyebilir.

Merkezi olmayan bir PKI, kimlikleri ve bunların karşılık gelen genel anahtarlarını içeren bir dizin tutan bir akıllı sözleşmedir. Örneğin, Gate.io, kullanıcıların kimliklerini ve genel anahtarlarını kaydeden bir merkezi olmayan bir borsadır.Ethereum Ad Hizmeti (ENS) Kaydıbir domain adları (“kimlikler”) ve bunların karşılık gelen meta verilerinin, dahil olmak üzere, çözümlenen adreslerini (hangi işlemlerden genel bir anahtar türetilebilir) eşleştirmesini korur. Merkezi olmayan bir PKI, daha da basit bir işlevsellik sağlar: kontrat tarafından korunan liste yalnızca her bir kimliğe karşılık gelen genel anahtarı depolar.

Kayıt olmak için bir kullanıcı anahtar çifti oluşturur (veya önceden oluşturulmuş bir anahtar çiftini kullanır) ve kimlik bilgisini ve genel anahtarını sözleşmeye gönderir (belki bir ödemeyle birlikte). Sözleşme, kimliğin henüz talep edilmediğini kontrol eder ve eğer öyleyse, kimlik bilgisini ve genel anahtarı dizine ekler. Bu noktada, herhangi biri bir ID'ye karşılık gelen genel anahtarı sormak için sözleşmeye başvurarak kayıtlı bir kullanıcıya bir mesajı şifreleyebilir. (Gönderici daha önce bu kullanıcıya bir şeyler şifrelediyse, sözleşmeye tekrar sorması gerekmez.) Gönderici, genel anahtarla mesajını normal şekilde şifreleyebilir ve şifreli metni alıcıya gönderebilir, alıcı ise karşılık gelen gizli anahtarı kullanarak mesajı geri alabilir.

Bu yöntemin özelliklerine bir göz atalım.

Muhasebenin olumsuz tarafında:

• Kısa değil. Tam anahtar dizini on-chain'de saklanmalı, böylece her zaman herkese kullanılabilir durumda olur (unutmayın, şimdilik DAS yokmuş gibi düşünüyoruz). ~900K için.bu yazının yazıldığı sırada ENS'de kaydedilmiş benzersiz alan adları, bu neredeyse 90MB kalıcı depolama anlamına gelir. Kayıt yapan taraflar, girdilerinin kapladığı depolama alanı için ödeme yapmalıdır, yaklaşık 65K gaz (şu anda yaklaşık olarak 1 dolar - performans değerlendirmesine bakın).
• Biraz etkileşimli şifreleme. Gönderici, kullanıcının genel anahtarını almak için zinciri okumalı, ancak yalnızca göndericinin o belirli kullanıcıya bir mesaj şifrelediği ilk kezse. (Unutmayın, kullanıcıların anahtarlarını güncellemediğini veya iptal etmediğini varsayıyoruz.)
• Gönderen anonim değil. Birinin açık anahtarını aldığınızda, kendinizi alıcıya bağlarsınız ve onlarla bir tür ilişkiniz olduğunu gösterirsiniz. Örneğin, WikiLeaks'in açık anahtarını aldığınızı hayal edin: Bu, gizli belgeleri sızdırdığınıza dair bir şüphe yaratabilir. Bu sorun, "kapak trafiği" (çoğunu kullanmayı düşünmediğiniz büyük bir anahtar yığınını alın) veya benzer şekilde tam düğüm çalıştırarak veya özel bilgi alma (PIR) ile hafifletilebilir.

Olumlu yönüyle:

• Etkileşimsiz şifreleme. Kullanıcılar yerel olarak saklanan gizli anahtarlarıyla mesajları şifreler, bu nedenle herhangi bir etkileşim gerektirmez.
• Saydam. Kullanıcıların ve anahtarların listesi tamamen herkese açıktır, böylece herkes doğru kaydedilip kaydedilmediğini kontrol edebilir.
• Keyfi ID kümesi. Kimliklerin alanı kurulu tarafından önceden sınırlı değildir; teoride, kimlik bir olabilir keyfi dize(belirli sözleşmenin uygulaması ve depolaması tarafından getirilen kısıtlamalar dahilinde).

Ne zaman bir ortak anahtar dizini kullanmak isteyebilirsiniz? Merkezi olmayan bir açık anahtar dizininin kurulumu ve yönetimi kolaydır, bu nedenle iyi bir temel seçimdir. Bununla birlikte, depolama maliyetleri veya gizlilik bir endişe kaynağıysa, aşağıdaki diğer seçeneklerden biri daha iyi bir seçim olabilir.

(Eşik) Kimlik Tabanlı Şifreleme (IBE)

Özet: Bir kullanıcının kimliği, onların genel anahtarıdır. Güvenilir bir üçüncü taraf veya taraflar, anahtarları vermek ve sistemın ömrü boyunca bir ana sır (kapı) tutmak için gereklidir.

IBE'de, bir kullanıcı kendi anahtar çiftini oluşturmaz, bunun yerine güvenilir bir anahtar üreticiye kaydolur. Anahtar üreticinin bir 'ana' anahtar çifti vardır (şekilde msk, mpk). Bir kullanıcının kimliği verildiğinde, anahtar üretici, ana gizli anahtarı msk ve kimlik kullanılarak kullanıcı için bir gizli anahtar hesaplar. Bu gizli anahtarın kullanıcıya güvenli bir kanal üzerinden iletilmesi gerekmektedir (bu, bir iletişim kanalı ile kurulabilir).anahtar değişim protokolü.

IBE, gönderenin deneyimini optimize eder: Anahtar oluşturucunun mpk'sını bir kez indirir, ardından kimliğin kendisini kullanarak bir mesajı herhangi bir kimliğe şifreleyebilir. Şifre çözme de basittir: kayıtlı bir kullanıcı, şifreli metnin şifresini çözmek için anahtar oluşturucu tarafından kendisine verilen gizli anahtarı kullanabilir.

Anahtar üretecinin ana gizli anahtarı daha kalıcıdır.güvenilir kurulum törenleri tarafından üretilen “toksik atık”SNARK'lar için kullanılır. Anahtar üreticisi, yeni gizli anahtarları vermek için buna ihtiyaç duyar, bu yüzden SNARK törenlerindeki katılımcılar gibi kurulumdan sonra silemez. Ayrıca, tehlikeli bir bilgidir. Msk'ya sahip olan herkes, sistemdeki herhangi bir kullanıcıya gönderilen tüm mesajları şifre çözebilir. Bu, felaketle sonuçlanabilecek bir dışarıya sızma riski olduğu anlamına gelir.

Msk güvende tutulsa bile, sisteme kaydolan her kullanıcının, anahtar oluşturucunun mesajlarını okumaması için anahtar oluşturucuya güvenmesi gerekir, çünkü anahtar oluşturucu kullanıcının gizli anahtarının bir kopyasını tutabilir veya istediği zaman msk'dan yeniden hesaplayabilir. Anahtar oluşturucunun, kullanıcıya, anahtar oluşturucu tarafından belirlenen bazı yasaklanmış iletiler dışındaki tüm iletilerin şifresini çözen hatalı veya "kısıtlanmış" bir gizli anahtar vermesi bile mümkün olabilir.

Bu güven, bunun yerine bir anahtar üreteci quorumunda dağıtılabilir, böylece bir kullanıcının yalnızca bir eşik sayıda olanlarına güvenmesi gerekir. Bu durumda, az sayıda kötü niyetli anahtar üreticisi gizli anahtarları kurtaramaz veya kötü anahtarlar hesaplayamaz ve bir saldırganın tam ana anahtarı çalmak için birden fazla sisteme girmesi gerekir.

Kullanıcılar bu güven varsayımını kabul ediyorsa, (eşik) IBE'nin birçok avantajı vardır:

• Sürekli / minimum zincir depolama. Yalnızca ana genel anahtar (tek bir grup elemanı) zincir üzerinde depolanması gerekmektedir. Bu, zincir üzerindeki bir genel anahtar dizinine gereksinim duyulan depolamadan çok daha azdır. Boneh-Franklin IBE üzerinde BN254 eğrisi için, bu, kurulum aşamasında yalnızca 64 baytlık kalıcı zincir depolamasının eklenmesi anlamına gelir ve hizmetin yalnızca 40K gaz harcamasını gerektirir.
• Etkileşimsiz şifreleme. Bir gönderici, bir mesajı şifrelemek için sadece başlangıçta bir kez indirdiği ana genel anahtarı ve alıcının kimlik bilgisini gerektirir. Bu, her yeni kullanıcıyla iletişim kurmak istediğinde bir anahtar alması gereken genel anahtar dizinine karşıt olarakdır.
• Etkileşimsiz şifre çözme. Kullanıcılar tekrar mesajları şifrelemek için yerel olarak saklanan gizli anahtarlarını kullanırlar.
• Gönderen-anonim. Gönderenin zincirden herhangi bir alıcıya özel bilgi alması gerekmez. Buna karşılık, bir genel anahtar kaydı durumunda, gönderen alıcıya bağlı olarak sözleşme ile etkileşimde bulunmak zorundadır.
• Rastgele ID kümesi. Genel anahtar kaydında olduğu gibi, ID'ler rastgele dizeler olabilir.

Ama!

• Güçlü güven varsayımı. Kullanıcıların kendi anahtarlarını oluşturduğu genel anahtar kaydının aksine, IBE, anahtarları düzenlemek için güvendiği bir veya birden fazla güvendiği taraf veya parti gerektirir. Anahtarın tamamıyla sistem süresi boyunca saklanması gerekmekte ve eğer sızdırılırsa veya yanlış kullanılırsa tüm kayıtlı kullanıcıların iletilerini tehlikeye atabilir.

Ne zaman (eşik) IBE kullanmak isteyebilirsiniz? Güvenilir bir üçüncü taraf veya taraflar mevcutsa ve kullanıcılar onlara güvenmeye istekliyse, IBE, zincir üzerindeki bir anahtar kaydına kıyasla çok daha yerden tasarruflu (ve bu nedenle daha ucuz) bir seçenek sunar.

Kayıt Tabanlı Şifreleme (RBE)

Özet: IBE'ye benzer şekilde, bir kullanıcının kimliği ortak anahtar görevi görür, ancak güvenilir üçüncü taraf/çekirdek şeffaf bir akümülatör ("anahtar küratör" olarak adlandırılır) ile değiştirilir.

Bu bölümde, verimli RBE yapısını tartışacağım. kağıdım, çünkü benim bildiğim gibi değil, sadece diğer pratik inşaat, şu anda bir blokzincirinde (kafes tabanlı yerine çift tabanlı olarak eşleme yapılan) uygulanabilir durumda. 'RBE' dediğim her zaman bu belirli yapıyı kastederim, ancak bazı ifadeler genel olarak RBE için doğru olabilir.

RBE'de, bir kullanıcı kendi anahtar çiftini oluşturur ve gizli anahtardan ve ortak referans dizesinden (CRS) türetilen bazı "güncelleme değerlerini" (şekilde a) hesaplar. Bir CRS'nin varlığı, kurulumun tamamen güvenilmez olmadığı anlamına gelse de, CRS bir tau güçleri inşaat, hangi olabilir zincir üzerinde işbirlikçi olarak hesaplanmışve tek bir dürüst katkı olduğu sürece güvenlidir.

Akıllı sözleşme, kullanıcıların beklenen sayısı N'ye gruplandığı kovallar için kurulur. Bir kullanıcı sisteme kaydolduğunda, kimlik, genel anahtar ve güncelleme değerlerini akıllı sözleşmeye gönderir. Akıllı sözleşme, sistemde kayıtlı tüm tarafların genel anahtarlarının özlü bir 'özeti' olarak düşünülebilecek genel parametreler pp kümesini (CRS'den farklı) korur. Bir kayıt isteği aldığında, güncelleme değerlerinde bir kontrol yapar ve genel anahtarı pp'nin uygun kovasına çarpar.

Kayıtlı kullanıcıların ayrıca, şifre çözmeye yardımcı olmak için kullandıkları ve aynı pakete yeni bir kullanıcı kaydolduğunda eklenen bazı "yardımcı bilgileri" yerel olarak tutmaları gerekir. Kovalarındaki kayıtlar için blok zincirini izleyerek bunu kendileri güncelleyebilirler veya akıllı sözleşme, kullanıcıların periyodik olarak (en az haftada bir kez) çekebilecekleri en son kayıtlardan (örneğin, geçen hafta içinde) aldığı güncelleme değerlerinin bir listesini tutarak yardımcı olabilir.

Bu sistemdeki gönderenler CRS'yi bir kez indirir ve bazen genel parametrelerin en son sürümünü indirir. Genel parametreler için, gönderenin bakış açısından önemli olan tek şey, hedeflenen alıcının genel anahtarını içermeleridir; En güncel sürüm olmak zorunda değildir. Gönderen daha sonra alıcıya gönderilen bir iletiyi şifrelemek için alıcı kimliğiyle birlikte CRS'yi ve genel parametreleri kullanabilir.

Bir ileti alındığında, kullanıcı bunun için yerel olarak depolanan yardımcı bilgilerini bir kontrolü geçen bir değer için kontrol eder. (Eğer hiçbir şey bulamazsa, bu, sözleşmeden bir güncelleme alması gerektiği anlamına gelir.) Bu değeri ve gizli anahtarını kullanarak, kullanıcı şifreli metni çözebilir.

Açıkça, bu plan diğer ikisinden daha karmaşıktır. Ancak, genel anahtar dizininden daha az on-chain depolama gerektirirken, IBE'nin güçlü güven varsayımından kaçınır.

• Özlü parametreler. Zincir üzerinde depolanacak parametrelerin boyutu kullanıcı sayısına göre sublinear olarak belirlenir. Bu, bir genel anahtar dizini için gereken toplam depolamadan (kullanıcı sayısına göre lineer olarak) çok daha küçük, ancak hala sabit değil ve bu nedenle IBE ile karşılaştırıldığında daha kötüdür.
• Biraz etkileşimli şifreleme. Bir mesaj göndermek için, gönderenin hedeflenen alıcıyı içeren genel parametrelerin bir kopyasına ihtiyacı vardır. Bu, hedeflenen bir alıcı kaydolduktan sonra bir noktada parametreleri güncelleştirmesi gerektiği anlamına gelir, ancak bir güncelleştirme birden çok alıcının anahtarını içerebileceğinden, kaydolan her hedeflenen alıcı için zorunlu değildir. Genel olarak, mesaj gönderme IBE'den daha etkileşimlidir, ancak bir dizinden daha az etkileşimlidir.
• Oldukça etkileşimli deşifreleme. Şifreleme durumuna benzer şekilde, alıcı, şifreleme için kullanılan genel parametrelerin “eşleştiği” bir yardımcı bilgi kopyasına ihtiyaç duyar. Daha spesifik olarak, her iki genel parametre ve yardımcı kovalar, yeni bir kullanıcı o kovada kaydolduğunda güncellenir ve bir şifreli metni deşifre edebilecek olan değer, şifrelemek için kullanılan pp sürümüne karşılık gelen değerdir. Genel parametre güncellemeleri gibi, bir kullanıcı yardımcı güncellemelerini sadece periyodik olarak almayı tercih edebilir, ancak deşifreleme başarısız olduğunda. Genel parametre güncellemelerinin aksine, yardımcı güncellemelerini daha sık almak, doğal olarak bilgi sızdırmaz.
• Gönderen-anonim. Dizin durumunda olduğu gibi, gönderen, alıcıyla ilgili bilgi sorgulamadan (güncel parametrelere sahipse) tamamen kendi başına bir mesajı şifreleyebilir. Gerektiğinde zincirden okunan bilgi, amaçlanan alıcının bağımsızdır. (İletişimi azaltmak için gönderen yalnızca belirli bir pp kovasını isteyebilir, kısmi bilgi sızdırabilir.)
• Saydam. Sistemin, delinmiş bir CRS çıktısı veren (potansiyel olarak dağıtılmış ve/veya harici olarak yönetilen) güvenilir bir kurulum töreni kullanılarak kurulması gerekse de, kurulum tamamlandıktan sonra herhangi bir güvenilir tarafa veya çekirdeğe dayanmaz: koordinasyon sağlayan bir üçüncü tarafa (sözleşme) dayanmasına rağmen, tamamen şeffaftır ve herkes koordinatör olabilir veya durum geçişlerini onaylayarak dürüstçe davranıp davranmadıklarını kontrol edebilir (bu yüzden olabilir akıllı sözleşme olarak uygulanır). Ayrıca, kullanıcılar kendilerinin (veya bir başkasının) sisteme kayıtlı olduklarını/kayıtlı olmadıklarını kontrol etmek için kısa ve öz bir üyelik kanıtı isteyebilirler. Bu, güvenilir tarafın/tarafların bir şifre çözme anahtarını (gizli bir kopya oluşturarak kendilerine veya başka birine) gizlice ifşa etmediklerini kanıtlamalarının zor olduğu IBE davasının aksine. Açık anahtar dizini ise tamamen şeffaftır.
• Kısıtlı Kimlik ayarlandı. RBE yapısının "temel" bir versiyonunu tanımladım. Bir kimliğin hangi pakete girdiğini şeffaf bir şekilde belirlemek için, kimliklerin genel ve belirleyici bir sıralamaya sahip olması gerekir. Telefon numaraları basitçe sıraya konulabilir, ancak kova sayısı son derece büyük veya sınırsız olabileceğinden, rastgele dizeler sipariş etmek imkansız değilse de hantaldır. Bu, böyle bir eşlemeyi hesaplayan ayrı bir sözleşme sunarak veya önerilen guguk kuşu karma yaklaşımını benimseyerek hafifletilebilir. bu takip çalışması.

Uzantılarla:

• Alıcı anonimdir. Şema, şifrelemelerin alıcının kimliğini açığa çıkarmadığı şekilde genişletilebilir.

Ne zaman RBE kullanmak isteyebilirsiniz? RBE, IBE tarafından gerektirilen güçlü güven varsayımlarını aynı anda önlerken, bir zincir dışı kayıt defterinden daha az zincir dışı depolama kullanır. Bir kayıt defterine kıyasla, RBE gönderene daha güçlü gizlilik garantileri sunar. Ancak, RBE yalnızca anahtar yönetimi için geçerli bir seçenek haline geldiğinden, bu özelliklerin kombinasyonundan en çok hangi senaryoların yararlanacağı henüz kesin değil. Lütfen bana haber verherhangi bir fikriniz varsa.

Performans Karşılaştırması

Bu üç yaklaşımı (30 Temmuz 2024 tarihine kadar) zincir üzerinde dağıtmanın maliyetlerini tahmin ettim.bu Colab defteri. ~900 bin kullanıcılı bir sistem kapasitesi için sonuçlar ( Bu yazının yazıldığı sırada ENS'de kayıtlı benzersiz alan adları) aşağıdaki tabloda gösterilmiştir.

PKI'nın kurulum maliyeti yoktur ve kullanıcı başına düşük bir kayıt maliyeti vardır, oysa IBE'nin küçük bir kurulum maliyeti ve neredeyse ücretsiz bir kayıt maliyeti vardır. RBE'nin daha yüksek bir kurulum maliyeti ve düşük zincir üstü depolama gerektirmesi nedeniyle beklenmedik yüksek bir kayıt maliyeti vardır.

Kayıt maliyetinin büyük kısmı (hesaplamanın bir L2'de yapıldığı varsayılarak), tarafların kalıcı depolamada genel parametrelerin bir parçasını güncellemesi gerektiğinden kaynaklanır ve bu da yüksek bir kayıt maliyetine neden olur.

RBE alternatiflerinden daha pahalı olsa da, bu analiz, PKI veya IBE'nin potansiyel olarak riskli güven varsayımları olmadan bugün Ethereum ana ağında uygulanabilir bir şekilde konuşlandırılabileceğini gösteriyor. Ve bu, birden çok, daha küçük (ve dolayısıyla daha ucuz) örnek dağıtma veya blob verilerini kullanma gibi iyileştirmelerden öncedir. RBE'nin açık anahtar dizinine ve IBE'ye göre daha güçlü anonimlik ve azalan güven varsayımları şeklinde avantajları olduğu göz önüne alındığında, gizliliğe ve güvenilmez kurulumlara değer verenler için çekici olabilir.

Noemi GlaeserMaryland Üniversitesi'nde ve Güvenlik ve Gizlilik için Max Planck Enstitüsü'nde Bilgisayar Bilimleri doktora adayıdır ve '23 yazında a16z crypto'da araştırma stajyeriydi. NSF Lisansüstü Araştırma Bursu'nun sahibi olan ve daha önce NTT Research'te araştırma stajyeri olan biridir.

Ek: Ek düşünceler

Anahtar güncellemeleri/iptalleri ile uğraşmak

Genel anahtar dizini durumunda, anahtar güncellemeleri ve iptalleri ele almak basittir: Bir anahtarı iptal etmek için bir tarafın sözleşmeden onu dizinden silmesi istenir. Bir anahtarı güncellemek için giriş (id, pk), yeni bir anahtarı (id, pk’) ile üzerine yazılır.

IBE'de iptal için, Boneh ve Franklin kullanıcıların periyodik olarak anahtarlarını güncellemelerini (örneğin, her hafta) ve gönderenlerin şifrelerken kimlik dizesine geçerli zaman dilimini dahil etmelerini önerdi (örneğin, "Bob "). Şifrelemenin etkileşimsiz doğası nedeniyle gönderenler, bir kullanıcının anahtarını ne zaman iptal ettiğini bilme yoluna sahip değildir, bu nedenle bazı dönem güncellemeleri zorunludur. Boldyreva, Goyal ve Kumar verdi.daha verimli iptal mekanizması Dayalı “Bulanık” IBEşifreleme için iki anahtar gerektiren bir yöntem kullanılır: bir “kimlik” anahtarı ve bir ek “zaman” anahtarı. Bu sayede, yalnızca zaman anahtarı düzenli olarak güncellenmelidir. Kullanıcıların zaman anahtarları bir ikili ağaçta biriktirilir ve bir kullanıcı yol boyunca herhangi bir düğümü kullanabilir (temel durumda yalnızca kök gerekli ve anahtar üreticisi tarafından yayınlanan tek kısımdır). Anahtar iptali, belirli bir kullanıcı için güncellemelerin artık yayınlanmamasıyla gerçekleştirilir (ağaçtaki o kullanıcının yolundan düğümlerin silinmesi durumunda güncelleme boyutu artar, ancak kullanıcı sayısının logaritmik olarak daha fazla olmaz).

Verimli RBE yapımız, güncellemeleri ve iptalleri dikkate almadı, bir Takip ÇalışmalarıBu işlevsellikleri eklemek için şemamızı "yükseltebilen" bir derleyici verir.

DAS ile verileri zincir dışına taşımak

Zincir üstü depolamayı zincir dışına taşımak için bir veri kullanılabilirliği çözümü (DAS) kullanmak, yalnızca açık anahtar dizini ve RBE hesabını etkileyecek ve her ikisini de aynı miktarda zincir içi depolamaya indirgeyecektir. RBE, alıcı kimliğinin erişim kalıpları aracılığıyla sızdırılmasını önlediğinden, gönderen için daha özel olma avantajını koruyacaktır. IBE'nin zaten minimum zincir içi depolama alanı vardı ve DAS'tan yararlanamayacaktı.

Açıklama:

1. Bu makale [den alıntıdıra16zkripto], Tüm hakları orijinal yazarına aittir [ Noemi Glaeser]. Bu yeniden basıma itirazlarınız varsa, lütfen iletişime geçin Gate Öğrenekip ve hızlı bir şekilde bununla ilgilenecekler.
2. Sorumluluk Reddi: Bu makalede yer alan görüşler yalnızca yazarın görüşleridir ve herhangi bir yatırım tavsiyesi teşkil etmez.
3. Makalenin diğer dillere çevirileri, Gate Learn ekibi tarafından yapılır. Belirtilmedikçe, çevrilen makalelerin kopyalanması, dağıtılması veya kopyalanması yasaktır.