การเชื่อมโยงคีย์การเข้ารหัสกับเอกลักษณ์เป็นปัญหาตั้งแต่การเข้ารหัสเทคโนโลยี. ความท้าทายคือการให้บริการและการรักษาการจับคู่ระหว่างเอกสิทธิ์และกุญแจสาธารณะที่เหมือนกัน (ที่เอกสิทธิ์เหล่านั้นมีกุญแจส่วนตัว) โดยไม่มีการจับคู่เช่นนั้น ข้อความที่ต้องการให้เป็นความลับอาจล้มเหลว - บางครั้งอาจมีผลลัพธ์ที่สาหัส ความท้าทายเดียวกันนี้ก็มีอยู่ใน web3
ปัจจุบันมีวิธีแก้ปัญหาที่เป็นไปได้สามวิธี สองวิธีคลาสสิกคือไดเรกทอรีคีย์สาธารณะและการเข้ารหัสตามข้อมูลประจําตัว ประการที่สามคือการเข้ารหัสตามการลงทะเบียนซึ่งจนกระทั่งเมื่อไม่นานมานี้เป็นทฤษฎีทั้งหมด วิธีการทั้งสามมีการแลกเปลี่ยนที่แตกต่างกันระหว่างการไม่เปิดเผยตัวตนการโต้ตอบและประสิทธิภาพซึ่งอาจดูเหมือนชัดเจนในตอนแรก แต่การตั้งค่าบล็อกเชนแนะนําความเป็นไปได้และข้อ จํากัด ใหม่ ๆ เป้าหมายของโพสต์นี้คือการสํารวจพื้นที่การออกแบบนี้และเปรียบเทียบแนวทางเหล่านี้เมื่อปรับใช้บนบล็อกเชน เมื่อผู้ใช้ต้องการความโปร่งใสและไม่เปิดเผยตัวตนโครงการ RBE ที่ใช้งานได้จริงคือผู้ชนะที่ชัดเจนนั่นคือการเอาชนะสมมติฐานความไว้วางใจที่แข็งแกร่งของการเข้ารหัสตามข้อมูลประจําตัว แต่มีค่าใช้จ่าย
วิธีการแบบคลาสสิกในการเชื่อมโยงคีย์การเข้ารหัสกับข้อมูลประจําตัวคือโครงสร้างพื้นฐานคีย์สาธารณะ (PKI) โดยมีไดเรกทอรีคีย์สาธารณะเป็นหัวใจสําคัญ วิธีการนี้กําหนดให้ผู้ส่งที่มีศักยภาพโต้ตอบกับบุคคลที่สามที่เชื่อถือได้ (ผู้ดูแลไดเรกทอรีหรือผู้ออกใบรับรอง) เพื่อส่งข้อความ นอกจากนี้ในการตั้งค่า web2 การบํารุงรักษาไดเรกทอรีนี้อาจมีค่าใช้จ่ายสูงน่าเบื่อและ error prone, และผู้ใช้เสี่ยงต่อการการละเมิดโดยหน่วยงานออกใบรับรอง.
นักเขียนรหัสได้แนะนำทางเลือกเพื่อหลีกเลี่ยงปัญหากับ PKI ในปี 1984,Adi Shamir แนะนำ การเข้ารหัสตามข้อมูลประจําตัว (IBE) ซึ่งตัวระบุของฝ่ายต่างๆ เช่น หมายเลขโทรศัพท์ อีเมล ENS ชื่อโดเมน ทําหน้าที่เป็นคีย์สาธารณะ สิ่งนี้ช่วยลดความจําเป็นในการรักษาไดเรกทอรีคีย์สาธารณะ แต่มีค่าใช้จ่ายในการแนะนําบุคคลที่สามที่เชื่อถือได้ (ตัวสร้างคีย์) Dan Boneh และ Matthew Franklin ให้ การสร้าง IBE ที่ใช้ได้จริงครั้งแรกในปี 2001 แต่ IBE ยังไม่ได้รับการใช้ที่แพร่หลาย ยกเว้นในระบบนิเวศปิดเช่น บริษัท หรือการติดตั้งของรัฐบาลอาจเป็นเพราะสมมติฐานความไว้วางใจที่แข็งแกร่ง ข้อสันนิษฐานนี้สามารถแก้ไขได้บางส่วนโดยอาศัยองค์ประชุมที่เชื่อถือได้ของฝ่ายต่างๆ แทน ซึ่งบล็อกเชนสามารถอํานวยความสะดวกได้อย่างง่ายดาย)
อีกตัวเลือกหนึ่งคือการเข้ารหัสที่ใช้การลงทะเบียน (RBE) ถูกproposed ใน พ.ศ.2561 RBE ยังคงรักษาสถาปัตยกรรมทั่วไปเช่นเดียวกับ IBE แต่แทนที่เครื่องกําเนิดคีย์ที่เชื่อถือได้ด้วย "ภัณฑารักษ์หลัก" ที่โปร่งใสซึ่งดําเนินการคํานวณข้อมูลสาธารณะเท่านั้น (โดยเฉพาะจะสะสมคีย์สาธารณะเป็น "ย่อย" ที่เปิดเผยต่อสาธารณะ) ความโปร่งใสของภัณฑารักษ์หลักนี้ทําให้การตั้งค่าบล็อกเชน — ซึ่งสัญญาอัจฉริยะสามารถเติมเต็มบทบาทของภัณฑารักษ์ — เหมาะอย่างยิ่งสําหรับ RBE RBE เป็นทฤษฎีจนถึงปี 2022 เมื่อผู้เขียนร่วมของฉันและฉันแนะนํา การสร้าง RBE ที่มีประสิทธิภาพในการใช้งานครั้งแรก.
พื้นที่ออกแบบนี้ซับซ้อน และการเปรียบเทียบแผนการนี้ต้องพิจารณามุมมองหลายมิติ หากต้องการให้ง่ายขึ้น ฉันจะทำสมมติฐานสองอย่าง
ฉันจะพูดถึงที่สิ้นสุดว่าแต่ละข้อพิจารณาเพิ่มเติมเหล่านี้สามารถมีผลต่อทางเลือกสามอย่างที่เรามีได้อย่างไร
สรุป: ใครก็ตามสามารถเพิ่มรายการ (id, pk) เข้าสู่ตารางบนเชื่อมโยง (ไดเรกทอรี) โดยเรียกใช้สัญญาอัจฉริยะ หากยังไม่ได้รับการเรียกเก็บ
ระบบ PKI แบบกระจายคือสัญญาอัจฉริยะที่รักษารายการบุคคลและคีย์สาธารณะที่เกี่ยวข้องทะเบียน Ethereum Name Service (ENS) รักษาการแมปชื่อโดเมน ("ข้อมูลประจําตัว") และข้อมูลเมตาที่เกี่ยวข้อง รวมถึงที่อยู่ที่พวกเขาแก้ไข (จากธุรกรรมที่สามารถรับคีย์สาธารณะได้) PKI แบบกระจายอํานาจจะให้ฟังก์ชันการทํางานที่ง่ายกว่า: รายการที่รักษาโดยสัญญาจะจัดเก็บเฉพาะคีย์สาธารณะที่สอดคล้องกับแต่ละ ID
ในการลงทะเบียนผู้ใช้จะสร้างคู่คีย์ (หรือใช้คู่คีย์ที่สร้างขึ้นก่อนหน้านี้) และส่ง ID และคีย์สาธารณะไปยังสัญญา (อาจพร้อมกับการชําระเงินบางส่วน) สัญญาจะตรวจสอบว่ายังไม่มีการอ้างสิทธิ์ ID และหากไม่เป็นเช่นนั้น จะเพิ่ม ID และคีย์สาธารณะลงในไดเรกทอรี ณ จุดนี้ทุกคนสามารถเข้ารหัสข้อความไปยังผู้ใช้ที่ลงทะเบียนโดยขอสัญญาสําหรับคีย์สาธารณะที่สอดคล้องกับ ID (หากผู้ส่งเคยเข้ารหัสบางอย่างกับผู้ใช้รายนี้มาก่อนก็ไม่จําเป็นต้องถามสัญญาอีกครั้ง) ด้วยคีย์สาธารณะผู้ส่งสามารถเข้ารหัสข้อความได้ตามปกติและส่งข้อความเข้ารหัสไปยังผู้รับซึ่งสามารถใช้คีย์ลับที่เกี่ยวข้องเพื่อกู้คืนข้อความได้
มาดูคุณสมบัติของวิธีนี้กัน
ด้านลบของบัญชี:
ด้านบวกคือ:
เมื่อคุณควรใช้ไดเรกทอรีคีย์สาธารณะ? ไดเรกทอรีคีย์สาธารณะแบบกระจายอำนวยความสะดวกในการติดตั้งและการจัดการ ดังนั้นเป็นตัวเลือกที่ดีในเบสไลน์ แต่หากค่าใช้จ่ายในการจัดเก็บหรือความเป็นส่วนตัวเป็นปัญหา ตัวเลือกอื่น ๆ ด้านล่างนี้อาจเป็นตัวเลือกที่ดีกว่า
สรุป: ตัวตนของผู้ใช้คือคีย์สาธารณะของพวกเขา ต้องมีบุคคลที่ไว้วางใจหรือบุคคลหรือหลายบุคคลที่จำเป็นต้องออกคีย์และเก็บความลับหลัก (หลุมลับ) สำหรับชีวิตของระบบ
ใน IBE ผู้ใช้ไม่ได้สร้างคู่คีย์ของตนเอง แต่ลงทะเบียนด้วยตัวสร้างคีย์ที่เชื่อถือได้แทน เครื่องกําเนิดคีย์มีคู่คีย์ "ต้นแบบ" (msk, mpk ในรูป) กําหนด ID ของผู้ใช้ตัวสร้างคีย์จะใช้คีย์ลับหลัก msk และ ID เพื่อคํานวณคีย์ลับสําหรับผู้ใช้ คีย์ลับนั้นจะต้องสื่อสารกับผู้ใช้ผ่านช่องทางที่ปลอดภัย (ซึ่งสามารถสร้างได้ด้วย โปรโตคอลแลกเปลี่ยนคีย์).
IBE ปรับปรุงประสบการณ์ของผู้ส่ง: มันดาวน์โหลดตัวสร้างคีย์ mpk ครั้งเดียวหลังจากนั้นมันสามารถเข้ารหัสข้อความไปยัง ID ใดก็ได้โดยใช้ ID ตนเอง การถอดรหัสก็ง่ายเช่นกัน: ผู้ใช้ที่ลงทะเบียนสามารถใช้คีย์ลับที่ออกให้โดยตัวสร้างคีย์เพื่อถอดรหัสข้อความที่ถูกเข้ารหัส
คีย์เจนเนอเรเตอร์ของคีย์มีความละเอียดสูงกว่า“ขยะพิษ” ที่เกิดขึ้นจากงานพิธีการตั้งค่าที่เชื่อถือได้ใช้สำหรับบาง SNARKs การสร้างกุญแจต้องใช้มันเพื่อออกให้กับกุญแจลับใหม่ ดังนั้นการสร้างกุญแจไม่สามารถลบได้หลังจากติดตั้งเหมือนที่ผู้ร่วมงานในพิธี SNARK ทำได้ นี่ยังเป็นข้อมูลที่อันตราย ผู้ที่มี msk สามารถถอดรหัสข้อความทั้งหมดที่ส่งให้กับผู้ใช้ในระบบได้ นี่หมายความว่ามีความเสี่ยงตลอดเวลาที่จะถูกลักพาตัวออกไปและสร้างผลกระทบที่สาหัส
แม้ว่า msk จะปลอดภัยผู้ใช้ทุกคนที่ลงทะเบียนในระบบจําเป็นต้องไว้วางใจตัวสร้างคีย์ไม่ให้อ่านข้อความเนื่องจากตัวสร้างคีย์สามารถเก็บสําเนาคีย์ลับของผู้ใช้หรือคํานวณใหม่จาก msk ได้ตลอดเวลา อาจเป็นไปได้ที่ตัวสร้างคีย์จะออกคีย์ลับที่ผิดพลาดหรือ "จํากัด" ให้กับผู้ใช้ที่ถอดรหัสข้อความทั้งหมดยกเว้นข้อความต้องห้ามบางอย่างตามที่กําหนดโดยตัวสร้างคีย์
ความเชื่อมั่นนี้สามารถกระจายได้ในกลุ่มของผู้สร้างคีย์ โดยผู้ใช้จะต้องเชื่อมั่นเพียงจำนวนที่มีค่าย่อยอย่างเท่านั้น ในกรณีนั้นจำนวนผู้สร้างคีย์ที่ไม่เป็นธรรมดาจะไม่สามารถกู้คืนคีย์ลับหรือคำนวณคีย์ที่ผิดได้และผู้โจมตีจะต้องแฝงเข้าไปในระบบหลายระบบเพื่อขโมยความลับของตัวเลขหลักฐานทั้งหมด
หากผู้ใช้ยอมรับการสมมติความเชื่อนี้ (threshold) IBE มาพร้อมกับประโยชน์มากมาย:
แต่!
เมื่อคุณอาจต้องการใช้ (threshold) IBE บ้าง? หากมีบุคคลที่สามที่เชื่อถือได้หรือมีการให้บริการ และผู้ใช้พร้อมที่จะเชื่อให้กับพวกเขา IBE ให้ความสามารถในพื้นที่มากกว่า (และจึงถูกกว่า) ตัวเลือกเมื่อเทียบกับทะเบียนกุญแจบนโซน
สรุป: คล้ายกับ IBE การรับรองตัวตนของผู้ใช้เป็นกุญแจสาธารณะของพวกเขา แต่คนที่ไว้วางใจ/คอร์เริ่มที่ไว้วางใจถูกแทนที่ด้วยตัวสะสมที่โปร่งใส (เรียกว่า "ผู้รักษากุญแจ")
ในส่วนนี้ ฉันจะพูดถึงการสร้าง RBE ที่มีประสิทธิภาพจากกระดาษของฉันตั้งแต่ไม่เหมือน (เพื่อความรู้ของฉัน) only other practical construction, ณ ขณะนี้สามารถใช้งานได้บนบล็อกเชน (โดยใช้การจับคู่แบบที่ใช้เครื่องหมายกำกับแทนการใช้ตาราง). เมื่อฉันพูดถึง “RBE” ฉันหมายถึงการสร้างนี้เฉพาะอย่างไรก็ตามคำบางคำอาจจะเป็นความจริงของ RBE โดยทั่วไป
ใน RBE ผู้ใช้จะสร้างคู่คีย์ของตัวเองและคํานวณ "ค่าอัปเดต" (a ในรูป) ที่ได้มาจากคีย์ลับและสตริงอ้างอิงทั่วไป (CRS) แม้ว่าการมี CRS หมายความว่าการตั้งค่านั้นไม่น่าเชื่อถืออย่างสมบูรณ์ แต่ CRS ก็เป็น powers-of-tauconstruction, ซึ่งสามารถคำนวณร่วมกันบนเชืองและปลอดภัยตราบเท่าที่มีการมีส่วนร่วมที่ซื่อสัตย์แค่คนเดียว
สัญญาอัจฉริยะถูกตั้งค่าสําหรับจํานวนผู้ใช้ที่คาดหวัง N ซึ่งจัดกลุ่มเป็นบัคเก็ต เมื่อผู้ใช้ลงทะเบียนในระบบระบบจะส่ง ID คีย์สาธารณะและอัปเดตค่าไปยังสัญญาอัจฉริยะ สัญญาอัจฉริยะรักษาชุดของพารามิเตอร์สาธารณะ pp (แตกต่างจาก CRS) ซึ่งถือได้ว่าเป็น "ย่อย" ที่รวบรัดของคีย์สาธารณะของทุกฝ่ายที่ลงทะเบียนในระบบ เมื่อได้รับคําขอลงทะเบียนจะทําการตรวจสอบค่าการอัปเดตและคูณคีย์สาธารณะลงในบัคเก็ตที่เหมาะสมของ pp
ผู้ใช้ที่ลงทะเบียนยังต้องรักษา "ข้อมูลเสริม" บางอย่างไว้ในเครื่องซึ่งพวกเขาใช้เพื่อช่วยในการถอดรหัสและผนวกเข้ากับเมื่อใดก็ตามที่ผู้ใช้ใหม่ลงทะเบียนในบัคเก็ตเดียวกัน พวกเขาสามารถอัปเดตสิ่งนี้ได้ด้วยตนเองโดยการตรวจสอบบล็อกเชนสําหรับการลงทะเบียนในบัคเก็ตของพวกเขาหรือสัญญาอัจฉริยะสามารถช่วยได้โดยการรักษารายการค่าการอัปเดตที่ได้รับจากการลงทะเบียนล่าสุด (พูดภายในสัปดาห์ที่แล้ว) ซึ่งผู้ใช้สามารถดึงเป็นระยะ (อย่างน้อยสัปดาห์ละครั้ง)
ผู้ส่งในระบบนี้ดาวน์โหลด CRS ครั้งเดียวและบางครั้งดาวน์โหลดเวอร์ชันล่าสุดของพารามิเตอร์สาธารณะ สำหรับพารามิเตอร์สาธารณะนั้น สิ่งที่สำคัญจากมุมมองของผู้ส่งคือว่าพารามิเตอร์สาธารณะรวมถึงคีย์สาธารณะของผู้รับที่ตั้งใจ; ไม่จำเป็นต้องเป็นเวอร์ชันที่อัปเดตล่าสุด จากนั้นผู้ส่งสามารถใช้ CRS และพารามิเตอร์สาธารณะพร้อมกับรหัสผู้รับเพื่อเข้ารหัสข้อความถึงผู้รับ
เมื่อได้รับข้อความผู้ใช้จะตรวจสอบข้อมูลเสริมที่จัดเก็บไว้ในเครื่องเพื่อหาค่าที่ผ่านการตรวจสอบ (หากพบว่าไม่มีก็หมายความว่าจําเป็นต้องดึงการปรับปรุงจากสัญญา) การใช้ค่านี้และรหัสลับผู้ใช้สามารถถอดรหัสข้อความเข้ารหัสได้
เห็นได้ชัดว่าโครงการนี้ซับซ้อนกว่าอีกสองโครงการ แต่ต้องใช้พื้นที่เก็บข้อมูลแบบ on-chain น้อยกว่าไดเรกทอรีคีย์สาธารณะในขณะที่หลีกเลี่ยงสมมติฐานความไว้วางใจที่แข็งแกร่งของ IBE
ด้วยส่วนขยาย:
คุณต้องการใช้ RBE เมื่อใด RBE ใช้ที่เก็บข้อมูลแบบ on-chain น้อยกว่ารีจิสทรีแบบ on-chain ในขณะเดียวกันก็หลีกเลี่ยงสมมติฐานความน่าเชื่อถือที่แข็งแกร่งที่ IBE ต้องการ เมื่อเทียบกับรีจิสทรี RBE ยังให้การรับประกันความเป็นส่วนตัวที่แข็งแกร่งกว่าแก่ผู้ส่ง อย่างไรก็ตามเนื่องจาก RBE เพิ่งกลายเป็นตัวเลือกที่ทํางานได้สําหรับการจัดการคีย์เราจึงไม่แน่ใจว่าสถานการณ์ใดจะได้รับประโยชน์มากที่สุดจากการรวมกันของคุณสมบัตินี้ กรุณา ให้ฉันทราบหากคุณมีความคิดใด ๆ
ฉันประเมินค่าใช้จ่าย (ณ วันที่ 30 กรกฎาคม ค.ศ. 2024) ในการนำแต่ละวิธีสามชั้นเข้าบัญชีบนเครือข่ายสมุดบันทึก Colab นี้. ผลลัพธ์สำหรับความสามารถของระบบประมาณ ~900K ผู้ใช้ (จำนวนของunique domain names registered in ENS at the time of this writingแสดงในตารางด้านล่าง
PKI ไม่มีค่าติดตั้งและค่าลงทะเบียนต่ําต่อผู้ใช้ในขณะที่ IBE มีค่าติดตั้งเล็กน้อยและการลงทะเบียนฟรีต่อผู้ใช้จริง RBE มีค่าใช้จ่ายในการติดตั้งที่สูงขึ้นและยังมีค่าใช้จ่ายในการลงทะเบียนที่สูงอย่างไม่คาดคิดแม้ว่าจะต้องใช้พื้นที่จัดเก็บแบบ on-chain ต่ําก็ตาม
ค่าลงทะเบียนที่ส่วนใหญ่ (ในสมมติฐานว่าการคำนวณทำบน L2) มาจากความจำเป็นที่ผู้เข้าร่วมต้องอัปเดตพารามิเตอร์สาธารณะในการเก็บรักษาในพื้นที่ถาวร ซึ่งเพิ่มค่าลงทะเบียนสูง
แม้ว่า RBE จะมีราคาแพงกว่าทางเลือกอื่น แต่การวิเคราะห์นี้แสดงให้เห็นว่าสามารถปรับใช้บนเมนเน็ต Ethereum ได้ในปัจจุบันโดยไม่มีสมมติฐานความน่าเชื่อถือที่อาจมีความเสี่ยงของ PKI หรือ IBE และนั่นคือก่อนการเพิ่มประสิทธิภาพเช่นการปรับใช้อินสแตนซ์หลายอินสแตนซ์ที่เล็กกว่า (และถูกกว่า) หรือใช้ข้อมูล blob เนื่องจาก RBE มีข้อได้เปรียบเหนือไดเรกทอรีคีย์สาธารณะและ IBE ในรูปแบบของการไม่เปิดเผยตัวตนที่แข็งแกร่งขึ้นและสมมติฐานความน่าเชื่อถือที่ลดลงจึงอาจน่าสนใจสําหรับผู้ที่ให้ความสําคัญกับความเป็นส่วนตัวและการตั้งค่าที่ไม่น่าเชื่อถือ
Noemi Glaeserเป็นนักศึกษาปริญญาเอกในสาขาวิทยาการคอมพิวเตอร์ที่มหาวิทยาลัยเมริแลนด์และสถาบันแม็กซ์แพลงค์เพื่อความปลอดภัยและความเป็นส่วนตัวและเป็นนักวิจัยระหว่างฤดูร้อนของ a16z crypto ในปี '23 เธอเป็นผู้ได้รับทุนสนับสนุนการวิจัยระดับบัณฑิตศึกษาจาก NSF และเป็นนักวิจัยระหว่างฤดูร้อนที่ NTT Research ก่อนหน้านี้
ในกรณีที่มีไดเรกทอรีคีย์สาธารณะ การจัดการการอัปเดตและการเพิกถอนคีย์เป็นเรื่องง่าย: เพื่อเพิกถอนคีย์ ฝ่ายหนึ่งจะขอให้สัญญาลบคีย์นั้นออกจากไดเรกทอรี ในการอัปเดตคีย์ รายการ (id, pk) จะถูกเขียนทับด้วยคีย์ใหม่เป็น (id, pk’)
สําหรับการเพิกถอนใน IBE Boneh และ Franklin แนะนําให้ผู้ใช้อัปเดตคีย์ของตนเป็นระยะ (เช่น ทุกสัปดาห์) และผู้ส่งจะรวมช่วงเวลาปัจจุบันไว้ในสตริงข้อมูลประจําตัวเมื่อเข้ารหัส (เช่น "Bob <สัปดาห์ปัจจุบัน>") เนื่องจากลักษณะการเข้ารหัสแบบไม่โต้ตอบผู้ส่งจึงไม่มีทางรู้ได้ว่าผู้ใช้จะเพิกถอนคีย์เมื่อใดดังนั้นการอัปเดตบางช่วงเวลาจึงมีอยู่จริง Boldyreva, Goyal และ Kumar ให้ กลไกการเพิกถอนที่มีประสิทธิภาพมากขึ้น โดยอ้างอิง “Fuzzy” IBE ซึ่งต้องใช้สองคีย์สําหรับการถอดรหัส: คีย์ "ข้อมูลประจําตัว" และคีย์ "เวลา" เพิ่มเติม ด้วยวิธีนี้จะต้องอัปเดตเฉพาะคีย์เวลาเป็นประจํา คีย์เวลาของผู้ใช้จะถูกสะสมในต้นไม้ไบนารีและผู้ใช้สามารถใช้โหนดใดก็ได้ตามเส้นทาง (ในกรณีพื้นฐานจําเป็นต้องใช้รูทเท่านั้นและเป็นส่วนเดียวที่เผยแพร่โดยตัวสร้างคีย์) การเพิกถอนคีย์ทําได้โดยการไม่เผยแพร่การอัปเดตสําหรับผู้ใช้รายใดรายหนึ่งอีกต่อไป (การลบโหนดตามเส้นทางของผู้ใช้รายนั้นจากต้นไม้) ซึ่งในกรณีนี้ขนาดของการอัปเดตจะเพิ่มขึ้น แต่ไม่เกินลอการิทึมในจํานวนผู้ใช้
การสร้าง RBE ที่มีประสิทธิภาพของเราไม่พิจารณาการอัปเดตและการถอดถอนงานติดตามผลให้คอมไพล์เลอร์ที่สามารถ “อัพเกรด” โปรแกรมของเราเพื่อเพิ่มความสามารถเหล่านี้
การใช้โซลูชันความสามารถในการให้ข้อมูล (DAS) เพื่อย้ายการจัดเก็บบนเชื่อมต่อออกไปจากเชื่อมต่อเพียงแค่ส่วนหนึ่ง จะมีผลต่อการคำนวณสำหรับไดเรกทอรีคีย์สาธารณะและ RBE เพื่อลดทั้งสองไปเหมือนกันในการจัดเก็บบนเชื่อมต่อ RBE ยังคงมีข้อดีในเรื่องความเป็นส่วนตัวมากกว่าสำหรับผู้ส่ง เนื่องจากยังคงหลีกเลี่ยงการรั่วไหลของตัวต้นทางผ่านรูปแบบการเข้าถึง ส่วน IBE มีการจัดเก็บบนเชื่อมต่ออยู่อย่างน้อยและจะไม่ได้รับประโยชน์จาก DAS
การเชื่อมโยงคีย์การเข้ารหัสกับเอกลักษณ์เป็นปัญหาตั้งแต่การเข้ารหัสเทคโนโลยี. ความท้าทายคือการให้บริการและการรักษาการจับคู่ระหว่างเอกสิทธิ์และกุญแจสาธารณะที่เหมือนกัน (ที่เอกสิทธิ์เหล่านั้นมีกุญแจส่วนตัว) โดยไม่มีการจับคู่เช่นนั้น ข้อความที่ต้องการให้เป็นความลับอาจล้มเหลว - บางครั้งอาจมีผลลัพธ์ที่สาหัส ความท้าทายเดียวกันนี้ก็มีอยู่ใน web3
ปัจจุบันมีวิธีแก้ปัญหาที่เป็นไปได้สามวิธี สองวิธีคลาสสิกคือไดเรกทอรีคีย์สาธารณะและการเข้ารหัสตามข้อมูลประจําตัว ประการที่สามคือการเข้ารหัสตามการลงทะเบียนซึ่งจนกระทั่งเมื่อไม่นานมานี้เป็นทฤษฎีทั้งหมด วิธีการทั้งสามมีการแลกเปลี่ยนที่แตกต่างกันระหว่างการไม่เปิดเผยตัวตนการโต้ตอบและประสิทธิภาพซึ่งอาจดูเหมือนชัดเจนในตอนแรก แต่การตั้งค่าบล็อกเชนแนะนําความเป็นไปได้และข้อ จํากัด ใหม่ ๆ เป้าหมายของโพสต์นี้คือการสํารวจพื้นที่การออกแบบนี้และเปรียบเทียบแนวทางเหล่านี้เมื่อปรับใช้บนบล็อกเชน เมื่อผู้ใช้ต้องการความโปร่งใสและไม่เปิดเผยตัวตนโครงการ RBE ที่ใช้งานได้จริงคือผู้ชนะที่ชัดเจนนั่นคือการเอาชนะสมมติฐานความไว้วางใจที่แข็งแกร่งของการเข้ารหัสตามข้อมูลประจําตัว แต่มีค่าใช้จ่าย
วิธีการแบบคลาสสิกในการเชื่อมโยงคีย์การเข้ารหัสกับข้อมูลประจําตัวคือโครงสร้างพื้นฐานคีย์สาธารณะ (PKI) โดยมีไดเรกทอรีคีย์สาธารณะเป็นหัวใจสําคัญ วิธีการนี้กําหนดให้ผู้ส่งที่มีศักยภาพโต้ตอบกับบุคคลที่สามที่เชื่อถือได้ (ผู้ดูแลไดเรกทอรีหรือผู้ออกใบรับรอง) เพื่อส่งข้อความ นอกจากนี้ในการตั้งค่า web2 การบํารุงรักษาไดเรกทอรีนี้อาจมีค่าใช้จ่ายสูงน่าเบื่อและ error prone, และผู้ใช้เสี่ยงต่อการการละเมิดโดยหน่วยงานออกใบรับรอง.
นักเขียนรหัสได้แนะนำทางเลือกเพื่อหลีกเลี่ยงปัญหากับ PKI ในปี 1984,Adi Shamir แนะนำ การเข้ารหัสตามข้อมูลประจําตัว (IBE) ซึ่งตัวระบุของฝ่ายต่างๆ เช่น หมายเลขโทรศัพท์ อีเมล ENS ชื่อโดเมน ทําหน้าที่เป็นคีย์สาธารณะ สิ่งนี้ช่วยลดความจําเป็นในการรักษาไดเรกทอรีคีย์สาธารณะ แต่มีค่าใช้จ่ายในการแนะนําบุคคลที่สามที่เชื่อถือได้ (ตัวสร้างคีย์) Dan Boneh และ Matthew Franklin ให้ การสร้าง IBE ที่ใช้ได้จริงครั้งแรกในปี 2001 แต่ IBE ยังไม่ได้รับการใช้ที่แพร่หลาย ยกเว้นในระบบนิเวศปิดเช่น บริษัท หรือการติดตั้งของรัฐบาลอาจเป็นเพราะสมมติฐานความไว้วางใจที่แข็งแกร่ง ข้อสันนิษฐานนี้สามารถแก้ไขได้บางส่วนโดยอาศัยองค์ประชุมที่เชื่อถือได้ของฝ่ายต่างๆ แทน ซึ่งบล็อกเชนสามารถอํานวยความสะดวกได้อย่างง่ายดาย)
อีกตัวเลือกหนึ่งคือการเข้ารหัสที่ใช้การลงทะเบียน (RBE) ถูกproposed ใน พ.ศ.2561 RBE ยังคงรักษาสถาปัตยกรรมทั่วไปเช่นเดียวกับ IBE แต่แทนที่เครื่องกําเนิดคีย์ที่เชื่อถือได้ด้วย "ภัณฑารักษ์หลัก" ที่โปร่งใสซึ่งดําเนินการคํานวณข้อมูลสาธารณะเท่านั้น (โดยเฉพาะจะสะสมคีย์สาธารณะเป็น "ย่อย" ที่เปิดเผยต่อสาธารณะ) ความโปร่งใสของภัณฑารักษ์หลักนี้ทําให้การตั้งค่าบล็อกเชน — ซึ่งสัญญาอัจฉริยะสามารถเติมเต็มบทบาทของภัณฑารักษ์ — เหมาะอย่างยิ่งสําหรับ RBE RBE เป็นทฤษฎีจนถึงปี 2022 เมื่อผู้เขียนร่วมของฉันและฉันแนะนํา การสร้าง RBE ที่มีประสิทธิภาพในการใช้งานครั้งแรก.
พื้นที่ออกแบบนี้ซับซ้อน และการเปรียบเทียบแผนการนี้ต้องพิจารณามุมมองหลายมิติ หากต้องการให้ง่ายขึ้น ฉันจะทำสมมติฐานสองอย่าง
ฉันจะพูดถึงที่สิ้นสุดว่าแต่ละข้อพิจารณาเพิ่มเติมเหล่านี้สามารถมีผลต่อทางเลือกสามอย่างที่เรามีได้อย่างไร
สรุป: ใครก็ตามสามารถเพิ่มรายการ (id, pk) เข้าสู่ตารางบนเชื่อมโยง (ไดเรกทอรี) โดยเรียกใช้สัญญาอัจฉริยะ หากยังไม่ได้รับการเรียกเก็บ
ระบบ PKI แบบกระจายคือสัญญาอัจฉริยะที่รักษารายการบุคคลและคีย์สาธารณะที่เกี่ยวข้องทะเบียน Ethereum Name Service (ENS) รักษาการแมปชื่อโดเมน ("ข้อมูลประจําตัว") และข้อมูลเมตาที่เกี่ยวข้อง รวมถึงที่อยู่ที่พวกเขาแก้ไข (จากธุรกรรมที่สามารถรับคีย์สาธารณะได้) PKI แบบกระจายอํานาจจะให้ฟังก์ชันการทํางานที่ง่ายกว่า: รายการที่รักษาโดยสัญญาจะจัดเก็บเฉพาะคีย์สาธารณะที่สอดคล้องกับแต่ละ ID
ในการลงทะเบียนผู้ใช้จะสร้างคู่คีย์ (หรือใช้คู่คีย์ที่สร้างขึ้นก่อนหน้านี้) และส่ง ID และคีย์สาธารณะไปยังสัญญา (อาจพร้อมกับการชําระเงินบางส่วน) สัญญาจะตรวจสอบว่ายังไม่มีการอ้างสิทธิ์ ID และหากไม่เป็นเช่นนั้น จะเพิ่ม ID และคีย์สาธารณะลงในไดเรกทอรี ณ จุดนี้ทุกคนสามารถเข้ารหัสข้อความไปยังผู้ใช้ที่ลงทะเบียนโดยขอสัญญาสําหรับคีย์สาธารณะที่สอดคล้องกับ ID (หากผู้ส่งเคยเข้ารหัสบางอย่างกับผู้ใช้รายนี้มาก่อนก็ไม่จําเป็นต้องถามสัญญาอีกครั้ง) ด้วยคีย์สาธารณะผู้ส่งสามารถเข้ารหัสข้อความได้ตามปกติและส่งข้อความเข้ารหัสไปยังผู้รับซึ่งสามารถใช้คีย์ลับที่เกี่ยวข้องเพื่อกู้คืนข้อความได้
มาดูคุณสมบัติของวิธีนี้กัน
ด้านลบของบัญชี:
ด้านบวกคือ:
เมื่อคุณควรใช้ไดเรกทอรีคีย์สาธารณะ? ไดเรกทอรีคีย์สาธารณะแบบกระจายอำนวยความสะดวกในการติดตั้งและการจัดการ ดังนั้นเป็นตัวเลือกที่ดีในเบสไลน์ แต่หากค่าใช้จ่ายในการจัดเก็บหรือความเป็นส่วนตัวเป็นปัญหา ตัวเลือกอื่น ๆ ด้านล่างนี้อาจเป็นตัวเลือกที่ดีกว่า
สรุป: ตัวตนของผู้ใช้คือคีย์สาธารณะของพวกเขา ต้องมีบุคคลที่ไว้วางใจหรือบุคคลหรือหลายบุคคลที่จำเป็นต้องออกคีย์และเก็บความลับหลัก (หลุมลับ) สำหรับชีวิตของระบบ
ใน IBE ผู้ใช้ไม่ได้สร้างคู่คีย์ของตนเอง แต่ลงทะเบียนด้วยตัวสร้างคีย์ที่เชื่อถือได้แทน เครื่องกําเนิดคีย์มีคู่คีย์ "ต้นแบบ" (msk, mpk ในรูป) กําหนด ID ของผู้ใช้ตัวสร้างคีย์จะใช้คีย์ลับหลัก msk และ ID เพื่อคํานวณคีย์ลับสําหรับผู้ใช้ คีย์ลับนั้นจะต้องสื่อสารกับผู้ใช้ผ่านช่องทางที่ปลอดภัย (ซึ่งสามารถสร้างได้ด้วย โปรโตคอลแลกเปลี่ยนคีย์).
IBE ปรับปรุงประสบการณ์ของผู้ส่ง: มันดาวน์โหลดตัวสร้างคีย์ mpk ครั้งเดียวหลังจากนั้นมันสามารถเข้ารหัสข้อความไปยัง ID ใดก็ได้โดยใช้ ID ตนเอง การถอดรหัสก็ง่ายเช่นกัน: ผู้ใช้ที่ลงทะเบียนสามารถใช้คีย์ลับที่ออกให้โดยตัวสร้างคีย์เพื่อถอดรหัสข้อความที่ถูกเข้ารหัส
คีย์เจนเนอเรเตอร์ของคีย์มีความละเอียดสูงกว่า“ขยะพิษ” ที่เกิดขึ้นจากงานพิธีการตั้งค่าที่เชื่อถือได้ใช้สำหรับบาง SNARKs การสร้างกุญแจต้องใช้มันเพื่อออกให้กับกุญแจลับใหม่ ดังนั้นการสร้างกุญแจไม่สามารถลบได้หลังจากติดตั้งเหมือนที่ผู้ร่วมงานในพิธี SNARK ทำได้ นี่ยังเป็นข้อมูลที่อันตราย ผู้ที่มี msk สามารถถอดรหัสข้อความทั้งหมดที่ส่งให้กับผู้ใช้ในระบบได้ นี่หมายความว่ามีความเสี่ยงตลอดเวลาที่จะถูกลักพาตัวออกไปและสร้างผลกระทบที่สาหัส
แม้ว่า msk จะปลอดภัยผู้ใช้ทุกคนที่ลงทะเบียนในระบบจําเป็นต้องไว้วางใจตัวสร้างคีย์ไม่ให้อ่านข้อความเนื่องจากตัวสร้างคีย์สามารถเก็บสําเนาคีย์ลับของผู้ใช้หรือคํานวณใหม่จาก msk ได้ตลอดเวลา อาจเป็นไปได้ที่ตัวสร้างคีย์จะออกคีย์ลับที่ผิดพลาดหรือ "จํากัด" ให้กับผู้ใช้ที่ถอดรหัสข้อความทั้งหมดยกเว้นข้อความต้องห้ามบางอย่างตามที่กําหนดโดยตัวสร้างคีย์
ความเชื่อมั่นนี้สามารถกระจายได้ในกลุ่มของผู้สร้างคีย์ โดยผู้ใช้จะต้องเชื่อมั่นเพียงจำนวนที่มีค่าย่อยอย่างเท่านั้น ในกรณีนั้นจำนวนผู้สร้างคีย์ที่ไม่เป็นธรรมดาจะไม่สามารถกู้คืนคีย์ลับหรือคำนวณคีย์ที่ผิดได้และผู้โจมตีจะต้องแฝงเข้าไปในระบบหลายระบบเพื่อขโมยความลับของตัวเลขหลักฐานทั้งหมด
หากผู้ใช้ยอมรับการสมมติความเชื่อนี้ (threshold) IBE มาพร้อมกับประโยชน์มากมาย:
แต่!
เมื่อคุณอาจต้องการใช้ (threshold) IBE บ้าง? หากมีบุคคลที่สามที่เชื่อถือได้หรือมีการให้บริการ และผู้ใช้พร้อมที่จะเชื่อให้กับพวกเขา IBE ให้ความสามารถในพื้นที่มากกว่า (และจึงถูกกว่า) ตัวเลือกเมื่อเทียบกับทะเบียนกุญแจบนโซน
สรุป: คล้ายกับ IBE การรับรองตัวตนของผู้ใช้เป็นกุญแจสาธารณะของพวกเขา แต่คนที่ไว้วางใจ/คอร์เริ่มที่ไว้วางใจถูกแทนที่ด้วยตัวสะสมที่โปร่งใส (เรียกว่า "ผู้รักษากุญแจ")
ในส่วนนี้ ฉันจะพูดถึงการสร้าง RBE ที่มีประสิทธิภาพจากกระดาษของฉันตั้งแต่ไม่เหมือน (เพื่อความรู้ของฉัน) only other practical construction, ณ ขณะนี้สามารถใช้งานได้บนบล็อกเชน (โดยใช้การจับคู่แบบที่ใช้เครื่องหมายกำกับแทนการใช้ตาราง). เมื่อฉันพูดถึง “RBE” ฉันหมายถึงการสร้างนี้เฉพาะอย่างไรก็ตามคำบางคำอาจจะเป็นความจริงของ RBE โดยทั่วไป
ใน RBE ผู้ใช้จะสร้างคู่คีย์ของตัวเองและคํานวณ "ค่าอัปเดต" (a ในรูป) ที่ได้มาจากคีย์ลับและสตริงอ้างอิงทั่วไป (CRS) แม้ว่าการมี CRS หมายความว่าการตั้งค่านั้นไม่น่าเชื่อถืออย่างสมบูรณ์ แต่ CRS ก็เป็น powers-of-tauconstruction, ซึ่งสามารถคำนวณร่วมกันบนเชืองและปลอดภัยตราบเท่าที่มีการมีส่วนร่วมที่ซื่อสัตย์แค่คนเดียว
สัญญาอัจฉริยะถูกตั้งค่าสําหรับจํานวนผู้ใช้ที่คาดหวัง N ซึ่งจัดกลุ่มเป็นบัคเก็ต เมื่อผู้ใช้ลงทะเบียนในระบบระบบจะส่ง ID คีย์สาธารณะและอัปเดตค่าไปยังสัญญาอัจฉริยะ สัญญาอัจฉริยะรักษาชุดของพารามิเตอร์สาธารณะ pp (แตกต่างจาก CRS) ซึ่งถือได้ว่าเป็น "ย่อย" ที่รวบรัดของคีย์สาธารณะของทุกฝ่ายที่ลงทะเบียนในระบบ เมื่อได้รับคําขอลงทะเบียนจะทําการตรวจสอบค่าการอัปเดตและคูณคีย์สาธารณะลงในบัคเก็ตที่เหมาะสมของ pp
ผู้ใช้ที่ลงทะเบียนยังต้องรักษา "ข้อมูลเสริม" บางอย่างไว้ในเครื่องซึ่งพวกเขาใช้เพื่อช่วยในการถอดรหัสและผนวกเข้ากับเมื่อใดก็ตามที่ผู้ใช้ใหม่ลงทะเบียนในบัคเก็ตเดียวกัน พวกเขาสามารถอัปเดตสิ่งนี้ได้ด้วยตนเองโดยการตรวจสอบบล็อกเชนสําหรับการลงทะเบียนในบัคเก็ตของพวกเขาหรือสัญญาอัจฉริยะสามารถช่วยได้โดยการรักษารายการค่าการอัปเดตที่ได้รับจากการลงทะเบียนล่าสุด (พูดภายในสัปดาห์ที่แล้ว) ซึ่งผู้ใช้สามารถดึงเป็นระยะ (อย่างน้อยสัปดาห์ละครั้ง)
ผู้ส่งในระบบนี้ดาวน์โหลด CRS ครั้งเดียวและบางครั้งดาวน์โหลดเวอร์ชันล่าสุดของพารามิเตอร์สาธารณะ สำหรับพารามิเตอร์สาธารณะนั้น สิ่งที่สำคัญจากมุมมองของผู้ส่งคือว่าพารามิเตอร์สาธารณะรวมถึงคีย์สาธารณะของผู้รับที่ตั้งใจ; ไม่จำเป็นต้องเป็นเวอร์ชันที่อัปเดตล่าสุด จากนั้นผู้ส่งสามารถใช้ CRS และพารามิเตอร์สาธารณะพร้อมกับรหัสผู้รับเพื่อเข้ารหัสข้อความถึงผู้รับ
เมื่อได้รับข้อความผู้ใช้จะตรวจสอบข้อมูลเสริมที่จัดเก็บไว้ในเครื่องเพื่อหาค่าที่ผ่านการตรวจสอบ (หากพบว่าไม่มีก็หมายความว่าจําเป็นต้องดึงการปรับปรุงจากสัญญา) การใช้ค่านี้และรหัสลับผู้ใช้สามารถถอดรหัสข้อความเข้ารหัสได้
เห็นได้ชัดว่าโครงการนี้ซับซ้อนกว่าอีกสองโครงการ แต่ต้องใช้พื้นที่เก็บข้อมูลแบบ on-chain น้อยกว่าไดเรกทอรีคีย์สาธารณะในขณะที่หลีกเลี่ยงสมมติฐานความไว้วางใจที่แข็งแกร่งของ IBE
ด้วยส่วนขยาย:
คุณต้องการใช้ RBE เมื่อใด RBE ใช้ที่เก็บข้อมูลแบบ on-chain น้อยกว่ารีจิสทรีแบบ on-chain ในขณะเดียวกันก็หลีกเลี่ยงสมมติฐานความน่าเชื่อถือที่แข็งแกร่งที่ IBE ต้องการ เมื่อเทียบกับรีจิสทรี RBE ยังให้การรับประกันความเป็นส่วนตัวที่แข็งแกร่งกว่าแก่ผู้ส่ง อย่างไรก็ตามเนื่องจาก RBE เพิ่งกลายเป็นตัวเลือกที่ทํางานได้สําหรับการจัดการคีย์เราจึงไม่แน่ใจว่าสถานการณ์ใดจะได้รับประโยชน์มากที่สุดจากการรวมกันของคุณสมบัตินี้ กรุณา ให้ฉันทราบหากคุณมีความคิดใด ๆ
ฉันประเมินค่าใช้จ่าย (ณ วันที่ 30 กรกฎาคม ค.ศ. 2024) ในการนำแต่ละวิธีสามชั้นเข้าบัญชีบนเครือข่ายสมุดบันทึก Colab นี้. ผลลัพธ์สำหรับความสามารถของระบบประมาณ ~900K ผู้ใช้ (จำนวนของunique domain names registered in ENS at the time of this writingแสดงในตารางด้านล่าง
PKI ไม่มีค่าติดตั้งและค่าลงทะเบียนต่ําต่อผู้ใช้ในขณะที่ IBE มีค่าติดตั้งเล็กน้อยและการลงทะเบียนฟรีต่อผู้ใช้จริง RBE มีค่าใช้จ่ายในการติดตั้งที่สูงขึ้นและยังมีค่าใช้จ่ายในการลงทะเบียนที่สูงอย่างไม่คาดคิดแม้ว่าจะต้องใช้พื้นที่จัดเก็บแบบ on-chain ต่ําก็ตาม
ค่าลงทะเบียนที่ส่วนใหญ่ (ในสมมติฐานว่าการคำนวณทำบน L2) มาจากความจำเป็นที่ผู้เข้าร่วมต้องอัปเดตพารามิเตอร์สาธารณะในการเก็บรักษาในพื้นที่ถาวร ซึ่งเพิ่มค่าลงทะเบียนสูง
แม้ว่า RBE จะมีราคาแพงกว่าทางเลือกอื่น แต่การวิเคราะห์นี้แสดงให้เห็นว่าสามารถปรับใช้บนเมนเน็ต Ethereum ได้ในปัจจุบันโดยไม่มีสมมติฐานความน่าเชื่อถือที่อาจมีความเสี่ยงของ PKI หรือ IBE และนั่นคือก่อนการเพิ่มประสิทธิภาพเช่นการปรับใช้อินสแตนซ์หลายอินสแตนซ์ที่เล็กกว่า (และถูกกว่า) หรือใช้ข้อมูล blob เนื่องจาก RBE มีข้อได้เปรียบเหนือไดเรกทอรีคีย์สาธารณะและ IBE ในรูปแบบของการไม่เปิดเผยตัวตนที่แข็งแกร่งขึ้นและสมมติฐานความน่าเชื่อถือที่ลดลงจึงอาจน่าสนใจสําหรับผู้ที่ให้ความสําคัญกับความเป็นส่วนตัวและการตั้งค่าที่ไม่น่าเชื่อถือ
Noemi Glaeserเป็นนักศึกษาปริญญาเอกในสาขาวิทยาการคอมพิวเตอร์ที่มหาวิทยาลัยเมริแลนด์และสถาบันแม็กซ์แพลงค์เพื่อความปลอดภัยและความเป็นส่วนตัวและเป็นนักวิจัยระหว่างฤดูร้อนของ a16z crypto ในปี '23 เธอเป็นผู้ได้รับทุนสนับสนุนการวิจัยระดับบัณฑิตศึกษาจาก NSF และเป็นนักวิจัยระหว่างฤดูร้อนที่ NTT Research ก่อนหน้านี้
ในกรณีที่มีไดเรกทอรีคีย์สาธารณะ การจัดการการอัปเดตและการเพิกถอนคีย์เป็นเรื่องง่าย: เพื่อเพิกถอนคีย์ ฝ่ายหนึ่งจะขอให้สัญญาลบคีย์นั้นออกจากไดเรกทอรี ในการอัปเดตคีย์ รายการ (id, pk) จะถูกเขียนทับด้วยคีย์ใหม่เป็น (id, pk’)
สําหรับการเพิกถอนใน IBE Boneh และ Franklin แนะนําให้ผู้ใช้อัปเดตคีย์ของตนเป็นระยะ (เช่น ทุกสัปดาห์) และผู้ส่งจะรวมช่วงเวลาปัจจุบันไว้ในสตริงข้อมูลประจําตัวเมื่อเข้ารหัส (เช่น "Bob <สัปดาห์ปัจจุบัน>") เนื่องจากลักษณะการเข้ารหัสแบบไม่โต้ตอบผู้ส่งจึงไม่มีทางรู้ได้ว่าผู้ใช้จะเพิกถอนคีย์เมื่อใดดังนั้นการอัปเดตบางช่วงเวลาจึงมีอยู่จริง Boldyreva, Goyal และ Kumar ให้ กลไกการเพิกถอนที่มีประสิทธิภาพมากขึ้น โดยอ้างอิง “Fuzzy” IBE ซึ่งต้องใช้สองคีย์สําหรับการถอดรหัส: คีย์ "ข้อมูลประจําตัว" และคีย์ "เวลา" เพิ่มเติม ด้วยวิธีนี้จะต้องอัปเดตเฉพาะคีย์เวลาเป็นประจํา คีย์เวลาของผู้ใช้จะถูกสะสมในต้นไม้ไบนารีและผู้ใช้สามารถใช้โหนดใดก็ได้ตามเส้นทาง (ในกรณีพื้นฐานจําเป็นต้องใช้รูทเท่านั้นและเป็นส่วนเดียวที่เผยแพร่โดยตัวสร้างคีย์) การเพิกถอนคีย์ทําได้โดยการไม่เผยแพร่การอัปเดตสําหรับผู้ใช้รายใดรายหนึ่งอีกต่อไป (การลบโหนดตามเส้นทางของผู้ใช้รายนั้นจากต้นไม้) ซึ่งในกรณีนี้ขนาดของการอัปเดตจะเพิ่มขึ้น แต่ไม่เกินลอการิทึมในจํานวนผู้ใช้
การสร้าง RBE ที่มีประสิทธิภาพของเราไม่พิจารณาการอัปเดตและการถอดถอนงานติดตามผลให้คอมไพล์เลอร์ที่สามารถ “อัพเกรด” โปรแกรมของเราเพื่อเพิ่มความสามารถเหล่านี้
การใช้โซลูชันความสามารถในการให้ข้อมูล (DAS) เพื่อย้ายการจัดเก็บบนเชื่อมต่อออกไปจากเชื่อมต่อเพียงแค่ส่วนหนึ่ง จะมีผลต่อการคำนวณสำหรับไดเรกทอรีคีย์สาธารณะและ RBE เพื่อลดทั้งสองไปเหมือนกันในการจัดเก็บบนเชื่อมต่อ RBE ยังคงมีข้อดีในเรื่องความเป็นส่วนตัวมากกว่าสำหรับผู้ส่ง เนื่องจากยังคงหลีกเลี่ยงการรั่วไหลของตัวต้นทางผ่านรูปแบบการเข้าถึง ส่วน IBE มีการจัดเก็บบนเชื่อมต่ออยู่อย่างน้อยและจะไม่ได้รับประโยชน์จาก DAS