การเชื่อมโยงคีย์การเข้ารหัสกับเอกลักษณ์เป็นปัญหาตั้งแต่การเข้ารหัสเทคโนโลยี. ความท้าทายคือการให้บริการและการรักษาการจับคู่ระหว่างเอกสิทธิ์และกุญแจสาธารณะที่เหมือนกัน (ที่เอกสิทธิ์เหล่านั้นมีกุญแจส่วนตัว) โดยไม่มีการจับคู่เช่นนั้น ข้อความที่ต้องการให้เป็นความลับอาจล้มเหลว - บางครั้งอาจมีผลลัพธ์ที่สาหัส ความท้าทายเดียวกันนี้ก็มีอยู่ใน 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 ที่มีประสิทธิภาพในการใช้งานครั้งแรก.

การประเมินการตัดสินใจ

พื้นที่ออกแบบนี้ซับซ้อน และการเปรียบเทียบแผนการนี้ต้องพิจารณามุมมองหลายมิติ หากต้องการให้ง่ายขึ้น ฉันจะทำสมมติฐานสองอย่าง

1. ผู้ใช้ไม่ได้อัพเดตหรือเพิกถอนคีย์ของพวกเขา
2. สัญญาอัจฉริยะไม่ใช้บริการการให้ข้อมูลจากภายนอก (DAS) หรือข้อมูลบล็อบ

ฉันจะพูดถึงที่สิ้นสุดว่าแต่ละข้อพิจารณาเพิ่มเติมเหล่านี้สามารถมีผลต่อทางเลือกสามอย่างที่เรามีได้อย่างไร

โดยชื่อของหน่วยงาน

สรุป: ใครก็ตามสามารถเพิ่มรายการ (id, pk) เข้าสู่ตารางบนเชื่อมโยง (ไดเรกทอรี) โดยเรียกใช้สัญญาอัจฉริยะ หากยังไม่ได้รับการเรียกเก็บ

ระบบ PKI แบบกระจายคือสัญญาอัจฉริยะที่รักษารายการบุคคลและคีย์สาธารณะที่เกี่ยวข้องทะเบียน Ethereum Name Service (ENS) รักษาการแมปชื่อโดเมน ("ข้อมูลประจําตัว") และข้อมูลเมตาที่เกี่ยวข้อง รวมถึงที่อยู่ที่พวกเขาแก้ไข (จากธุรกรรมที่สามารถรับคีย์สาธารณะได้) PKI แบบกระจายอํานาจจะให้ฟังก์ชันการทํางานที่ง่ายกว่า: รายการที่รักษาโดยสัญญาจะจัดเก็บเฉพาะคีย์สาธารณะที่สอดคล้องกับแต่ละ ID

ในการลงทะเบียนผู้ใช้จะสร้างคู่คีย์ (หรือใช้คู่คีย์ที่สร้างขึ้นก่อนหน้านี้) และส่ง ID และคีย์สาธารณะไปยังสัญญา (อาจพร้อมกับการชําระเงินบางส่วน) สัญญาจะตรวจสอบว่ายังไม่มีการอ้างสิทธิ์ ID และหากไม่เป็นเช่นนั้น จะเพิ่ม ID และคีย์สาธารณะลงในไดเรกทอรี ณ จุดนี้ทุกคนสามารถเข้ารหัสข้อความไปยังผู้ใช้ที่ลงทะเบียนโดยขอสัญญาสําหรับคีย์สาธารณะที่สอดคล้องกับ ID (หากผู้ส่งเคยเข้ารหัสบางอย่างกับผู้ใช้รายนี้มาก่อนก็ไม่จําเป็นต้องถามสัญญาอีกครั้ง) ด้วยคีย์สาธารณะผู้ส่งสามารถเข้ารหัสข้อความได้ตามปกติและส่งข้อความเข้ารหัสไปยังผู้รับซึ่งสามารถใช้คีย์ลับที่เกี่ยวข้องเพื่อกู้คืนข้อความได้

มาดูคุณสมบัติของวิธีนี้กัน

ด้านลบของบัญชี:

• ไม่กระชับ ไดเรกทอรีคีย์เต็มต้องถูกเก็บไว้บนเชื่อมโยงเสมอ เพื่อให้สามารถใช้ได้เสมอสำหรับทุกคน (โปรดจำไว้ในขณะนี้เรากำลังสมมุติว่าไม่มี DAS) สำหรับ ~900Kชื่อโดเมนที่ไม่ซ้ำกันที่ลงทะเบียนใน ENS ในขณะที่เขียนข้อความนี้นี่หมายถึงพื้นที่จัดเก็บที่คงทนเกือบ 90MB หน่วยงานที่ลงทะเบียนต้องชำระค่าเก็บข้อมูลที่รายการของพวกเขาใช้ไปประมาณ 65K gas (ปัจจุบันประมาณ $1 - ดูการประเมินประสิทธิภาพด้านล่าง)
• การเข้ารหัสแบบโต้ตอบค่อนข้าง ผู้ส่งจําเป็นต้องอ่านห่วงโซ่เพื่อดึงคีย์สาธารณะของผู้ใช้ แต่ถ้าเป็นครั้งแรกที่ผู้ส่งเข้ารหัสข้อความไปยังผู้ใช้รายนั้น (โปรดจําไว้ว่าเราสมมติว่าผู้ใช้ไม่ได้อัปเดตหรือเพิกถอนคีย์ของพวกเขา)
• ไม่ระบุชื่อผู้ส่ง เมื่อคุณดึงคีย์สาธารณะของใครบางคน คุณจะเชื่อมโยงตัวเองกับผู้รับ ซึ่งบ่งชี้ว่าคุณมีความสัมพันธ์บางอย่างกับพวกเขา ลองนึกภาพตัวอย่างเช่นคุณดึงคีย์สาธารณะสําหรับ WikiLeaks: สิ่งนี้อาจสร้างความสงสัยว่าคุณกําลังรั่วไหลของเอกสารลับ ปัญหานี้อาจได้รับการแก้ไขด้วย "การรับส่งข้อมูลที่ครอบคลุม" (ดึงคีย์ชุดใหญ่ซึ่งส่วนใหญ่คุณไม่ได้ตั้งใจจะใช้) หรือในทํานองเดียวกันโดยการเรียกใช้โหนดแบบเต็มหรือด้วยการดึงข้อมูลส่วนตัว (PIR)

ด้านบวกคือ:

• การถอดรหัสแบบไม่ต้องปฏิสัมพันธ์ ผู้ใช้ถอดรหัสข้อความด้วยกุญแจลับที่เก็บไว้ในเครื่องของตนเอง ดังนั้นไม่ต้องมีการปฏิสัมพันธ์ใด ๆ
• โปร่งใส รายชื่อผู้ใช้และคีย์ทั้งหมดเป็นสาธารณะอย่างสมบูรณ์ ดังนั้น ไม่ว่าใครก็สามารถตรวจสอบได้ว่าพวกเขาได้ลงทะเบียนถูกต้องหรือไม่
• ตั้งค่า ID อย่างอิสระ โดเมนของ ID ไม่ได้ถูกจำกัดไว้ล่วงหน้าโดยการสร้าง; ในทฤษฎีแล้ว ID สามารถเป็นได้สตริงอย่างสุ่ม (สูงสุดตามข้อจำกัดที่บังคับในการนำไปใช้งานและเก็บรักษาของสัญญาที่ระบุเจาะจง)

เมื่อคุณควรใช้ไดเรกทอรีคีย์สาธารณะ? ไดเรกทอรีคีย์สาธารณะแบบกระจายอำนวยความสะดวกในการติดตั้งและการจัดการ ดังนั้นเป็นตัวเลือกที่ดีในเบสไลน์ แต่หากค่าใช้จ่ายในการจัดเก็บหรือความเป็นส่วนตัวเป็นปัญหา ตัวเลือกอื่น ๆ ด้านล่างนี้อาจเป็นตัวเลือกที่ดีกว่า

(Threshold) การเข้ารหัสด้วย Identity-Based Encryption (IBE)

สรุป: ตัวตนของผู้ใช้คือคีย์สาธารณะของพวกเขา ต้องมีบุคคลที่ไว้วางใจหรือบุคคลหรือหลายบุคคลที่จำเป็นต้องออกคีย์และเก็บความลับหลัก (หลุมลับ) สำหรับชีวิตของระบบ

ใน IBE ผู้ใช้ไม่ได้สร้างคู่คีย์ของตนเอง แต่ลงทะเบียนด้วยตัวสร้างคีย์ที่เชื่อถือได้แทน เครื่องกําเนิดคีย์มีคู่คีย์ "ต้นแบบ" (msk, mpk ในรูป) กําหนด ID ของผู้ใช้ตัวสร้างคีย์จะใช้คีย์ลับหลัก msk และ ID เพื่อคํานวณคีย์ลับสําหรับผู้ใช้ คีย์ลับนั้นจะต้องสื่อสารกับผู้ใช้ผ่านช่องทางที่ปลอดภัย (ซึ่งสามารถสร้างได้ด้วย โปรโตคอลแลกเปลี่ยนคีย์).

IBE ปรับปรุงประสบการณ์ของผู้ส่ง: มันดาวน์โหลดตัวสร้างคีย์ mpk ครั้งเดียวหลังจากนั้นมันสามารถเข้ารหัสข้อความไปยัง ID ใดก็ได้โดยใช้ ID ตนเอง การถอดรหัสก็ง่ายเช่นกัน: ผู้ใช้ที่ลงทะเบียนสามารถใช้คีย์ลับที่ออกให้โดยตัวสร้างคีย์เพื่อถอดรหัสข้อความที่ถูกเข้ารหัส

คีย์เจนเนอเรเตอร์ของคีย์มีความละเอียดสูงกว่า“ขยะพิษ” ที่เกิดขึ้นจากงานพิธีการตั้งค่าที่เชื่อถือได้ใช้สำหรับบาง SNARKs การสร้างกุญแจต้องใช้มันเพื่อออกให้กับกุญแจลับใหม่ ดังนั้นการสร้างกุญแจไม่สามารถลบได้หลังจากติดตั้งเหมือนที่ผู้ร่วมงานในพิธี SNARK ทำได้ นี่ยังเป็นข้อมูลที่อันตราย ผู้ที่มี msk สามารถถอดรหัสข้อความทั้งหมดที่ส่งให้กับผู้ใช้ในระบบได้ นี่หมายความว่ามีความเสี่ยงตลอดเวลาที่จะถูกลักพาตัวออกไปและสร้างผลกระทบที่สาหัส

แม้ว่า msk จะปลอดภัยผู้ใช้ทุกคนที่ลงทะเบียนในระบบจําเป็นต้องไว้วางใจตัวสร้างคีย์ไม่ให้อ่านข้อความเนื่องจากตัวสร้างคีย์สามารถเก็บสําเนาคีย์ลับของผู้ใช้หรือคํานวณใหม่จาก msk ได้ตลอดเวลา อาจเป็นไปได้ที่ตัวสร้างคีย์จะออกคีย์ลับที่ผิดพลาดหรือ "จํากัด" ให้กับผู้ใช้ที่ถอดรหัสข้อความทั้งหมดยกเว้นข้อความต้องห้ามบางอย่างตามที่กําหนดโดยตัวสร้างคีย์

ความเชื่อมั่นนี้สามารถกระจายได้ในกลุ่มของผู้สร้างคีย์ โดยผู้ใช้จะต้องเชื่อมั่นเพียงจำนวนที่มีค่าย่อยอย่างเท่านั้น ในกรณีนั้นจำนวนผู้สร้างคีย์ที่ไม่เป็นธรรมดาจะไม่สามารถกู้คืนคีย์ลับหรือคำนวณคีย์ที่ผิดได้และผู้โจมตีจะต้องแฝงเข้าไปในระบบหลายระบบเพื่อขโมยความลับของตัวเลขหลักฐานทั้งหมด

หากผู้ใช้ยอมรับการสมมติความเชื่อนี้ (threshold) IBE มาพร้อมกับประโยชน์มากมาย:

• การจัดเก็บข้อมูลบนเชื่อมต่ออย่างต่อเนื่อง/ขั้นต่ำ ที่จำเป็นต้องเก็บข้อมูลบนเชื่อมต่ออย่างต่อเนื่อง บนเส้นทางเดียวกัน คือ กุญแจสาธารณะต้นฉบับ (กลุ่มองค์ประกอบเดียว) ที่จำเป็นต้องเก็บบนเชื่อมต่ออย่างต่อเนื่อง น้อยกว่าการจัดเก็บข้อมูลบนเชื่อมต่ออย่างต่อเนื่อง บนเส้นทางเดียวกันสำหรับไดเรกทอรีกุญแจสาธารณะบนเชื่อมต่ออย่างต่อเนื่อง สำหรับ Boneh-Franklin IBE บนเส้นโค้ง BN254 นี้หมายถึงการเพิ่มพื้นที่การจัดเก็บบนเชื่อมต่ออย่างต่อเนื่องเพียง 64 ไบต์ ในระหว่างขั้นตอนการตั้งค่า ทำให้บริการต้องใช้เพียง 40K gas เท่านั้น
• การเข้ารหัสแบบไม่โต้ตอบ ผู้ส่งต้องการคีย์สาธารณะหลักเท่านั้น (ซึ่งจะดาวน์โหลดครั้งเดียวเมื่อเริ่มต้น) และ ID ของผู้รับเพื่อเข้ารหัสข้อความ สิ่งนี้ตรงกันข้ามกับไดเร็กทอรีคีย์สาธารณะซึ่งจะต้องดึงคีย์สําหรับผู้ใช้ใหม่ทุกคนที่ต้องการสื่อสารด้วย
• การถอดรหัสแบบไม่ต้องป้อนข้อมูลใดๆ เพิ่มเติม อีกครั้ง ผู้ใช้ใช้กุญแจลับที่เก็บไว้ในเครื่องเพื่อถอดรหัสข้อความ
• ผู้ส่ง-ไม่ระบุชื่อ ผู้ส่งไม่ต้องเรียกคืนข้อมูลของผู้รับใด ๆ จากเครือข่าย ในกรณีของทะเบียนกุญแจสาธารณะ ผู้ส่งต้องทำการติดต่อกับสัญญาในวิธีที่ขึ้นอยู่กับผู้รับ
• ชุด ID อย่างสมบูรณ์. เช่นในทะเบียนคีย์สาธารณะ IDs สามารถเป็นสตริงอย่างสมบูรณ์

แต่!

• สมมติฐานความไว้วางใจที่แข็งแกร่ง ซึ่งแตกต่างจากรีจิสทรีคีย์สาธารณะที่ผู้ใช้สร้างคีย์ของตนเอง IBE ต้องการฝ่ายที่เชื่อถือได้หรือโควรัมของฝ่ายที่มีความลับหลัก (กับดัก) เพื่อออกคีย์ ความลับหลักจะต้องถูกเก็บไว้ตลอดอายุการใช้งานของระบบและสามารถประนีประนอมข้อความของผู้ใช้ที่ลงทะเบียนทั้งหมดได้หากมีการรั่วไหลหรือนําไปใช้ในทางที่ผิด

เมื่อคุณอาจต้องการใช้ (threshold) IBE บ้าง? หากมีบุคคลที่สามที่เชื่อถือได้หรือมีการให้บริการ และผู้ใช้พร้อมที่จะเชื่อให้กับพวกเขา IBE ให้ความสามารถในพื้นที่มากกว่า (และจึงถูกกว่า) ตัวเลือกเมื่อเทียบกับทะเบียนกุญแจบนโซน

การเข้ารหัสที่ขึ้นอยู่กับการลงทะเบียน (RBE)

สรุป: คล้ายกับ 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

• พารามิเตอร์ที่รวบรัด ขนาดของพารามิเตอร์ที่จะจัดเก็บแบบ on-chain เป็นแบบ sublinear ในจํานวนผู้ใช้ สิ่งนี้มีขนาดเล็กกว่าพื้นที่เก็บข้อมูลทั้งหมดที่จําเป็นสําหรับไดเร็กทอรีคีย์สาธารณะ (เชิงเส้นในจํานวนผู้ใช้) แต่ก็ยังไม่คงที่และแย่กว่าเมื่อเทียบกับ IBE
• การเข้ารหัสแบบประมาณการโต้ตอบ ในการส่งข้อความ ผู้ส่งต้องมีสำเนาของพารามิเตอร์สาธารณะซึ่งประกอบด้วยผู้รับที่ต้องการ นั่นหมายความว่าจะต้องอัปเดตพารามิเตอร์ในบางจุดหลังจากผู้รับที่ตั้งใจลงทะเบียน แต่ไม่จำเป็นต้องอัปเดตสำหรับผู้รับที่ตั้งใจทุกครั้งที่ลงทะเบียน เนื่องจากการอัปเดตหนึ่งครั้งอาจรวมถึงคีย์ของผู้รับหลายราย โดยรวมแล้ว การส่งข้อความเป็นรูปแบบที่มีการโต้ตอบมากกว่า IBE แต่น้อยกว่าไดเรกทอรี
• การถอดรหัสแบบโต้ตอบค่อนข้าง เช่นเดียวกับกรณีการเข้ารหัสผู้รับต้องการสําเนาของข้อมูลเสริมที่ "ตรงกับ" เวอร์ชันของพารามิเตอร์สาธารณะที่ใช้สําหรับการเข้ารหัส โดยเฉพาะอย่างยิ่งทั้งพารามิเตอร์สาธารณะและบัคเก็ต aux จะได้รับการอัปเดตเมื่อใดก็ตามที่ผู้ใช้ใหม่ลงทะเบียนในบัคเก็ตนั้นและค่าที่สามารถถอดรหัสข้อความเข้ารหัสคือค่าที่สอดคล้องกับเวอร์ชัน pp ที่ใช้ในการเข้ารหัส เช่นเดียวกับการอัปเดตพารามิเตอร์สาธารณะผู้ใช้สามารถตัดสินใจดึงการอัปเดต aux เป็นระยะ ๆ เท่านั้นยกเว้นเมื่อการถอดรหัสล้มเหลว ซึ่งแตกต่างจากการอัปเดตพารามิเตอร์สาธารณะการดึงการอัปเดต aux บ่อยขึ้นจะไม่ทําให้ข้อมูลรั่วไหลโดยเนื้อแท้
• ผู้ส่งเป็นไม่ทราบชื่อ ดังเช่นในกรณีของไดเรกทอรี ผู้ส่งสามารถเข้ารหัสข้อความได้โดยสมบูรณ์เอง (หากมีพารามิเตอร์ที่อัปเดต) โดยไม่ต้องสอบถามข้อมูลเฉพาะผู้รับ ข้อมูลที่อ่านจากโซ่เมื่อจำเป็น จะไม่ขึ้นอยู่กับผู้รับที่ตั้งใจ (เพื่อลดการสื่อสาร ผู้ส่งสามารถขอเฉพาะ pp bucket ที่เฉพาะเจาะจงได้ ซึ่งจะเป็นการรั่วไหลข้อมูลบางส่วน)
• ใส แม้ว่าระบบจะต้องได้รับการตั้งค่าโดยใช้พิธีการตั้งค่าที่เชื่อถือได้ (อาจแจกจ่ายและ / หรือจัดการภายนอก) ซึ่งส่งออก CRS ที่เจาะทะลุ แต่ก็ไม่ได้พึ่งพาฝ่ายที่เชื่อถือได้หรือองค์ประชุมเมื่อการตั้งค่าเสร็จสมบูรณ์: แม้ว่าจะอาศัยบุคคลที่สามที่ประสานงาน (สัญญา) แต่ก็มีความโปร่งใสอย่างสมบูรณ์และทุกคนสามารถเป็นผู้ประสานงานหรือตรวจสอบว่าพวกเขาประพฤติตนอย่างซื่อสัตย์โดยยืนยันการเปลี่ยนสถานะ (นั่นคือเหตุผลที่สามารถทําได้ ดําเนินการเป็นสัญญาอัจฉริยะ) นอกจากนี้ผู้ใช้สามารถขอหลักฐานการเป็นสมาชิกที่รวบรัด (ไม่ใช่) เพื่อตรวจสอบว่าพวกเขา (หรือคนอื่น ๆ ) ลงทะเบียน / ไม่ได้ลงทะเบียนในระบบ สิ่งนี้ตรงกันข้ามกับกรณี IBE ซึ่งเป็นเรื่องยากสําหรับฝ่าย / ฝ่ายที่เชื่อถือได้ที่จะพิสูจน์ว่าพวกเขาไม่ได้แอบเปิดเผยคีย์ถอดรหัส (ให้กับตัวเองโดยการทําสําเนาลับหรือให้คนอื่น) ในทางกลับกันไดเรกทอรีคีย์สาธารณะมีความโปร่งใสอย่างสมบูรณ์
• ตั้งค่า ID ที่ถูกจํากัด ฉันได้อธิบายรุ่น "พื้นฐาน" ของการก่อสร้าง RBE ในการกําหนดอย่างโปร่งใสว่า ID อยู่ในบัคเก็ตใดรหัสจะต้องมีการเรียงลําดับแบบสาธารณะและกําหนดได้ หมายเลขโทรศัพท์สามารถสั่งซื้อได้ แต่การสั่งซื้อสตริงโดยพลการนั้นไม่ราบรื่นหากเป็นไปไม่ได้เนื่องจากจํานวนถังอาจมีขนาดใหญ่มากหรือไม่มีขอบเขต สิ่งนี้อาจถูกแก้ไขโดยการเสนอสัญญาแยกต่างหากซึ่งคํานวณการทําแผนที่ดังกล่าวหรือโดยการนําวิธีการแฮชนกกาเหว่าที่เสนอใน งานที่ตามมานี้.

ด้วยส่วนขยาย:

• ผู้รับที่ไม่ระบุชื่อ รูปแบบสามารถขยายได้เพื่อไม่ให้ข้อความเข้ารหัสเปิดเผยตัวตนของผู้รับ

คุณต้องการใช้ 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

การใช้โซลูชันความสามารถในการให้ข้อมูล (DAS) เพื่อย้ายการจัดเก็บบนเชื่อมต่อออกไปจากเชื่อมต่อเพียงแค่ส่วนหนึ่ง จะมีผลต่อการคำนวณสำหรับไดเรกทอรีคีย์สาธารณะและ RBE เพื่อลดทั้งสองไปเหมือนกันในการจัดเก็บบนเชื่อมต่อ RBE ยังคงมีข้อดีในเรื่องความเป็นส่วนตัวมากกว่าสำหรับผู้ส่ง เนื่องจากยังคงหลีกเลี่ยงการรั่วไหลของตัวต้นทางผ่านรูปแบบการเข้าถึง ส่วน IBE มีการจัดเก็บบนเชื่อมต่ออยู่อย่างน้อยและจะไม่ได้รับประโยชน์จาก DAS

คำเตือน:

1. บทความนี้ถูกพิมพ์ซ้ำจาก [ a16zcrypto] ลิขสิทธิ์ทั้งหมดเป็นของผู้เขียนต้นฉบับ [โนเอมิ เกลเซอร์ ]. หากมีการคัดค้านในการพิมพ์ฉบับนี้ กรุณาติดต่อGate Learnทีม และพวกเขาจะดูแลมันโดยรวดเร็ว
2. คำประกาศความรับผิด: มุมมองและความคิดเห็นที่แสดงในบทความนี้เป็นสิ่งที่เป็นของผู้เขียนเท่านั้น และไม่เป็นการให้คำแนะนำทางการลงทุนใดๆ
3. การแปลบทความเป็นภาษาอื่น ๆ ถูกดำเนินการโดยทีม Gate Learn ห้ามคัดลอก แจกจ่าย หรือลอกเลียนแบบบทความที่ถูกแปลนี้ นอกเส้นทางที่ระบุไว้