Прив'язка криптографічних ключів до профілів з тих пір є проблемою впровадження технології. Виклик полягає в забезпеченні та підтримці загальнодоступного та послідовного відображення ідентичностей та відкритих ключів (до яких ці ідентичності мають особистий ключ). Без такого відображення повідомлення, призначені для збереження в секреті, можуть піти не так — іноді з трагічними наслідками. Цей самий виклик існує в web3.

Наразі існує три можливі рішення. Двома класичними підходами є каталог з відкритим ключем і шифрування на основі ідентифікаційних даних. По-третє, шифрування на основі реєстрації, яке до недавнього часу було суто теоретичним. Ці три підходи пропонують різні компроміси між анонімністю, інтерактивністю та ефективністю, що спочатку може здатися зрозумілим, але налаштування блокчейну вносить нові можливості та обмеження. Отже, мета цієї публікації полягає в тому, щоб дослідити цей простір дизайну та порівняти ці підходи при розгортанні на блокчейні. Коли користувачам потрібна прозорість та анонімність ончейн, практична схема RBE є явним переможцем — подолання сильного припущення про довіру шифрування на основі ідентифікаційних даних, але за це доведеться заплатити.

Три підходи в кількох словах

Класичним підходом до зв'язування криптографічних ключів з профілями є інфраструктура відкритих ключів (PKI), в основі якої лежить каталог відкритих ключів. Цей підхід вимагає, щоб потенційний відправник взаємодіяв з довіреною третьою стороною (супроводжуючим каталогу або центром сертифікації) для надсилання повідомлень. Крім того, у налаштуваннях web2 підтримка цього каталогу може бути дорогою, виснажливою та помилковий, і користувачі підлягають ризику зловживання від ім'я видачі сертифікатів.

Криптографи запропонували альтернативи, щоб обійти проблеми з PKI. У 1984 році,Аді Шамір запропонувавшифрування на основі ідентифікації (IBE), в якому ідентифікатор сторони - номер телефону, електронна пошта, доменне ім'я ENS - виступає у вигляді відкритого ключа. Це усуває потребу у веденні каталогу відкритих ключів, але при цьому вводить довіру до третьої сторони (генератора ключів). Ден Бонех та Метью Франклін надали перша практична конструкція IBEin 2001, but IBE has not received widespread adoption except in closed ecosystems such as corporate or установки уряду, можливо, через сильну довіру. (Як ми побачимо нижче, це припущення може бути частково зменшене за допомогою спирання на довірений кворум сторін, який блокчейн легко може сприяти.)

Третя опція, шифрування на основі реєстрації (RBE), булапропонованийу 2018 році. RBE зберігає ту саму загальну архітектуру, що й IBE, але замінює надійний генератор ключів прозорим «куратором ключів», який виконує обчислення тільки на публічних даних (конкретно, він накопичує публічні ключі в своєрідний вид публічно доступного «дайджесту»). Прозорість цього куратора ключів робить блокчейн-середовище - де роль куратора може виконувати розумний контракт - природнім варіантом для RBE. RBE залишався теоретичним до 2022 року, коли мої співавтори і я представили перша практично ефективна конструкція RBE.

Оцінка компромісів

Цей дизайн-простір складний, і порівняння цих схем потребує врахування багатьох вимірів. Щоб спростити речі, я зроблю дві припущення:

1. Користувачі не оновлюють або відкликають свої ключі.
2. Розумний контракт не використовує жодного сервісу доступності даних поза ланцюжком (DAS) або даних у вигляді блобів.

На кінці я розгляну, як кожна з цих додаткових моментів може вплинути на наші три потенційні рішення.

Довідник публічного ключа

Опис: Будь-хто може додати запис (id, pk) до ланцюгової таблиці (довідник) за допомогою виклику розумного договору, якщо ID ще не був заявлений.

Децентралізована PKI являє собою, по суті, розумний контракт, який підтримує каталог ідентифікаторів та відповідних публічних ключів. Наприклад, Реєстр Ethereum Name Service (ENS) Підтримує прив'язку доменних імен («ідентичностей») та відповідних метаданих, включно з адресами, які вони вирішують (з транзакцій яких може бути отримано відкритий ключ). Децентралізований PKI забезпечив би ще простішу функціональність: список, який підтримується контрактом, зберігав би лише публічний ключ, що відповідає кожному ідентифікатору.

Для реєстрації користувач генерує пару ключів (або використовує раніше згенеровану пару ключів) та надсилає його ідентифікатор та публічний ключ контракту (можливо, разом з деяким платежем). Контракт перевіряє, чи не був той самий ідентифікатор вже використаний, і, якщо ні, додає ідентифікатор та публічний ключ до каталогу. На цьому етапі будь-хто може зашифрувати повідомлення для зареєстрованого користувача, звернувшись до контракту за публічним ключем, що відповідає ідентифікатору. (Якщо відправник вже раніше зашифрував щось для цього користувача, йому не потрібно знову звертатися до контракту.) За допомогою публічного ключа відправник може зашифрувати своє повідомлення, як зазвичай, і надіслати шифротекст одержувачу, який може використати відповідний секретний ключ для відновлення повідомлення.

Давайте розглянемо властивості цього методу.

На негативній стороні грифелю:

• Не лаконічно. Повний каталог ключів повинен зберігатися в мережі, щоб він завжди був доступний для всіх (пам'ятайте, що зараз ми припускаємо, що DAS відсутній). За ~900K унікальні доменні імена, зареєстровані в ENS на момент написання цього, це означає майже 90 МБ постійного сховища. Реєструючі сторони повинні платити за обсяг сховища, який займає їх запис, приблизно 65 тис. газу (зараз приблизно 1 долар - див. нижче оцінку продуктивності).
• Дещо інтерактивного шифрування. Відправник повинен прочитати ланцюг, щоб отримати публічний ключ користувача, але тільки у разі, якщо це перший раз, коли відправник шифрує повідомлення саме цьому користувачеві. (Пам'ятайте, ми припускаємо, що користувачі не оновлюють або скасовують свої ключі.)
• Не анонімний відправник. Коли ви отримуєте чийсь публічний ключ, ви пов'язуєте себе з одержувачем, вказуючи на те, що у вас є якісь стосунки з ним. Уявіть, наприклад, що ви отримуєте публічний ключ для WikiLeaks: це може створити підозру, що ви зливаєте секретні документи. Цю проблему можна пом'якшити за допомогою «трафіку покриття» (отримати велику партію ключів, більшість з яких ви не збираєтеся використовувати) або аналогічним чином, запустивши повний вузол, або за допомогою приватного пошуку інформації (PIR).

З позитивних моментів:

• Невзаємодійне дешифрування. Користувачі розшифровують повідомлення за допомогою локально збереженого секретного ключа, тому це не вимагає жодної взаємодії.
• Прозорий. Список користувачів та ключів є повністю публічним, тому будь-хто може перевірити, чи були вони зареєстровані правильно.
• Довільний набір ідентифікаторів. Домен ID апріорі не обмежений конструкцією; теоретично ідентифікатор може бути довільний рядок(до обмежень, накладених реалізацією конкретного контракту та зберігання).

Коли можна використовувати каталог з відкритим ключем? Децентралізований каталог відкритих ключів простий у налаштуванні та управлінні, тому це хороший базовий вибір. Однак, якщо витрати на зберігання або конфіденційність викликають занепокоєння, один з інших варіантів, наведених нижче, може бути кращим вибором.

(Поріг) Ідентифікація на основі шифрування (IBE)

Опис: Ідентифікатор користувача - це його публічний ключ. Для видачі ключів і зберігання головного секрету (пастки) на протязі життєвого циклу системи потрібна довірена третя сторона або сторони.

У IBE користувач не генерує власну пару ключів, а замість цього реєструється у довіреного генератора ключів. Генератор ключів має "мастер" пару ключів (msk, mpk на малюнку). Заданий ідентифікатор користувача генератор ключів використовує майстер-секретний ключ msk та ідентифікатор для обчислення секретного ключа для користувача. Цей секретний ключ має бути сповіщений користувачеві через захищений канал (який може бути встановлений з,протокол обміну ключами.

IBE оптимізує досвід відправника: він завантажує mpk генератора ключів один раз, після чого може шифрувати повідомлення до будь-якого ІД, використовуючи сам ІД. Дешифрування також просте: зареєстрований користувач може використовувати секретний ключ, виданий йому генератором ключів, для розшифрування шифротексту.

Майстер-секретний ключ генератора ключів є більш стійким, ніж«токсичні відходи», що виникають під час церемоній надійної настройки відкритих ключіввикористовується для деяких SNARKs. Генератор ключів потребує його для видачі будь-яких нових секретних ключів, тому генератор ключів не може стерти його після налаштування, як це роблять учасники церемоній SNARK. Це також небезпечна інформація. Будь-хто з msk може розшифрувати всі повідомлення, відправлені будь-якому користувачеві в системі. Це означає, що існує постійний ризик витоку з катастрофічними наслідками.

Навіть якщо msk зберігається в безпеці, кожен користувач, який реєструється в системі, повинен довіряти генератору ключів, щоб він не читав його повідомлення, оскільки генератор ключів може зберегти копію секретного ключа користувача або повторно обчислити його з msk у будь-який час. Можливо, генератор ключів навіть видасть користувачеві помилковий або «обмежений» секретний ключ, який розшифровує всі повідомлення, крім деяких заборонених, як визначено генератором ключів.

Натомість ця довіра може бути розподілена між кворумом генераторів ключів, так що користувач повинен довіряти лише пороговій кількості з них. У цьому випадку невелика кількість шкідливих генераторів ключів не може відновити секретні ключі або обчислити пошкоджені ключі, і зловмиснику доведеться зламати кілька систем, щоб викрасти повний головний секрет.

Якщо користувачі погоджуються з цим довірчим припущенням, (порогове) IBE надає багато переваг:

• Постійне/мінімальне зберігання on-chain. На ланцюжку даних потрібно зберігати лише основний відкритий ключ (один елемент групи). Це набагато менше, ніж потрібно для зберігання відкритого ключа на ланцюжку даних. Для Boneh-Franklin IBE на кривій BN254 це означає додавання 64 байтів постійного зберігання on-chain під час фази налаштування, що потребує витрати лише 40К газу для сервісу.
• Невзаємодійне шифрування. Відправнику потрібен лише загальний публічний ключ (який він завантажує один раз на початку) та ідентифікатор одержувача, щоб зашифрувати повідомлення. Це відмінно від каталогу публічних ключів, де він мусив би отримати ключ для кожного нового користувача, з яким він хоче спілкуватися.
• Неінтерактивне розшифрування. Знову, користувачі використовують свої збережені локально секретні ключі для розшифрування повідомлень.
• Відправник-анонім. Відправнику не потрібно отримувати будь-яку інформацію про кожного одержувача з ланцюжка. Для порівняння, у випадку реєстру з відкритим ключем відправник повинен взаємодіяти з контрактом у спосіб, який залежить від одержувача.
• Произвольный набор ID. Как и в реестре открытых ключей, ID могут быть произвольными строками.

Але!

• Міцне припущення про довіру. На відміну від реєстру з відкритим ключем, де користувачі генерують власні ключі, IBE вимагає наявності довіреної сторони або кворуму сторін з майстер-секретом (западним ходом), щоб видавати ключі. Майстер-секрет повинен зберігатися протягом усього терміну служби системи і може скомпрометувати всі повідомлення зареєстрованих користувачів, якщо він буде розкритий або зловживаний.

Коли можна використовувати (пороговий) IBE? Якщо доступна довірена третя сторона або сторони, і користувачі готові їм довіряти, IBE пропонує набагато компактніший (і, отже, дешевший) варіант порівняно з реєстром ключів у мережі.

Реєстраційне шифрування (RBE)

У своєму розумінні, подібно до ІБЕ, ідентичність користувача служить їхнім відкритим ключем, але довірена третя сторона / кворум замінена прозорим накопичувачем (званим "куратором ключів").

У цьому розділі я розповім про ефективну побудову RBE від моя стаття, оскільки, на відміну від (наскільки мені відомо) лише інша практична конструкція, в даний час його можна розгорнути на блокчейні (на відміну від гратового) замість на основі решітки. Коли я кажу “RBE”, я маю на увазі саме цю конструкцію, хоча деякі твердження можуть бути правдивими для RBE взагалі.

У RBE користувач генерує власну пару ключів і обчислює деякі «значення оновлення» (a на малюнку), отримані з секретного ключа та загального еталонного рядка (CRS). Хоча наявність CRS означає, що налаштування не є повністю ненадійним, CRS є потужності-тауконструкція, яка може бутиобчислений колективно в ланцюжкуі залишається безпечним, доки існувала хоча б одна чесна внесок.

Смарт-контракт налаштовується на очікувану кількість користувачів N, згрупованих у сегменти. Коли користувач реєструється в системі, він надсилає смарт-контракту свій ID, публічний ключ і значення оновлення. Смарт-контракт підтримує набір публічних параметрів pp (відмінних від CRS), які можна розглядати як стислий «дайджест» публічних ключів усіх сторін, зареєстрованих у системі. Отримавши запит на реєстрацію, він виконує перевірку значень оновлення та множить відкритий ключ у відповідний сегмент pp.

Зареєстрованим користувачам також потрібно зберігати деяку «допоміжну інформацію» локально, яку вони використовують для розшифровки і яка додається щоразу, коли новий користувач реєструється у своєму тому самому сегменті. Вони можуть оновлювати це самостійно, відстежуючи блокчейн на наявність реєстрацій у своєму сегменті, або смарт-контракт може допомогти, підтримуючи список значень оновлень, отриманих від останніх реєстрацій (скажімо, протягом останнього тижня), які користувачі можуть періодично отримувати (принаймні раз на тиждень).

Відправники в цій системі завантажують CRS один раз і час від часу завантажують найновішу версію публічних параметрів. Що стосується публічних параметрів, все, що має значення з точки зору відправника, це те, що вони включають публічний ключ призначеного отримувача; вони не обов'язково повинні бути найновішою версією. Потім відправник може використовувати CRS та публічні параметри разом з ідентифікатором отримувача, щоб зашифрувати повідомлення отримувачеві.

При отриманні повідомлення користувач перевіряє свою локально збережену додаткову інформацію на наявність значення, що проходить певну перевірку. (Якщо він не знаходить нічого, це означає, що йому потрібно отримати оновлення з контракту.) Використовуючи це значення та його секретний ключ, користувач може дешифрувати шифротекст.

Зрозуміло, що ця схема складніша, ніж дві інші. Але він вимагає менше ончейн-сховища, ніж каталог з відкритим ключем, уникаючи при цьому сильного припущення про довіру IBE.

• Лаконічні параметри. Розмір параметрів, які будуть зберігатися в ланцюжку, є сублінійним за кількістю користувачів. Це набагато менше, ніж загальний обсяг пам'яті, необхідний для каталогу з відкритим ключем (лінійний за кількістю користувачів), але все одно не постійний і тому гірший у порівнянні з IBE.
• Дещо інтерактивне шифрування. Щоб надіслати повідомлення, відправнику потрібна копія публічних параметрів, яка містить передбачуваного одержувача. Це означає, що потрібно оновити параметри в певний момент після реєстрації призначеного одержувача, але не обов'язково для кожного призначеного одержувача, який реєструється, оскільки одне оновлення може містити кілька ключів одержувачів. В цілому, відправка повідомлень більш інтерактивна, ніж IBE, але менш інтерактивна, ніж каталог.
• Дещо інтерактивна розшифровка. Подібно до випадку шифрування, одержувачу потрібна копія допоміжної інформації, яка «збігається» з версією публічних параметрів, що використовуються для шифрування. Точніше, як публічний параметр, так і допоміжні сегменти оновлюються щоразу, коли новий користувач реєструється в цьому сегменті, а значення, здатне розшифрувати зашифрований текст, відповідає версії pp, яка використовується для шифрування. Подібно до оновлень публічних параметрів, користувач може вирішити отримувати допоміжні оновлення лише періодично, за винятком випадків, коли розшифрування не вдається. На відміну від оновлень загальнодоступних параметрів, отримання додаткових оновлень частіше за своєю суттю не призводить до витоку інформації.
• Відправник-анонім. Як і у випадку з каталогом, відправник може повністю зашифрувати повідомлення самостійно (за умови, що воно має актуальні параметри), не запитуючи інформацію про одержувача. Інформація, зчитана з ланцюжка, при необхідності, не залежить від передбачуваного одержувача. (Щоб зменшити зв'язок, відправник міг запросити лише певний сегмент pp, що призвело до часткового витоку інформації.)
• Прозорі. Незважаючи на те, що система повинна бути налаштована за допомогою (потенційно розподіленої та/або зовнішньо адміністрованої) довіреної церемонії налаштування, яка виводить пробитий CRS, вона не покладається на будь-яку довірену сторону чи кворум після завершення налаштування: хоча вона покладається на координуючу третю сторону (контракт), вона є абсолютно прозорою, і будь-хто може бути координатором або перевірити, чи поводиться він чесно, підтвердивши свої переходи станів (саме тому це може бути реалізований у вигляді смарт-контракту). Крім того, користувачі можуть попросити стислий (не)членський документ, щоб перевірити, чи вони (або хтось інший) зареєстровані/не зареєстровані в системі. Це контрастує зі справою IBE, де довіреній стороні/сторонам важко фактично довести, що вони таємно не розкрили ключ розшифровки (собі, зробивши секретну копію або комусь іншому). Каталог з відкритим ключем, з іншого боку, є повністю прозорим.
• Обмежений набір ідентифікаторів. Я описав «базову» версію конструкції RBE. Щоб прозоро визначити, в який ковш попадає ідентифікатор, ідентифікатори мають мати публічне та визначальне упорядкування. Номери телефонів можна просто впорядкувати, але упорядкування довільних рядків незручне, якщо не неможливо, оскільки кількість ковшів може бути дуже великою або необмеженою. Це можна пом'якшити, пропонуючи окремий договір, який обчислює таке відображення, або прийняттям запропонованого підходу до глухого хешування.ця наступна робота.

З розширеннями:

• Отримувач-анонімний. схему можна розширити так, щоб шифротексти не розкривали ідентифікацію отримувача.

Коли можна використовувати RBE? RBE використовує менше ончейн-сховища, ніж ончейн-реєстр, одночасно уникаючи сильних припущень про довіру, яких вимагає IBE. У порівнянні з реєстром, RBE також пропонує відправнику сильніші гарантії конфіденційності. Однак, оскільки RBE лише нещодавно став життєздатним варіантом для управління ключами, ми ще не впевнені, які сценарії найбільше виграють від цієї комбінації властивостей. Будь ласка дайте мені знатиякщо у вас є якісь ідеї.

Порівняння продуктивності

Я оцінив витрати (на 30 липня 2024 року) на розгортання кожного з цих трьох підходів on-chain в цей блокнот Colab. Результати для потужності системи ~900 тис. користувачів (кількість унікальні доменні імена, зареєстровані в ENS на момент написання цього) показані в таблиці нижче.

У PKI немає вартості налаштування та низької вартості реєстрації на кожного користувача, тоді як у IBE є невелика вартість налаштування та практично безкоштовна реєстрація на кожного користувача. У RBE вища вартість налаштування та несподівано висока вартість реєстрації, незважаючи на низький обсяг зберігання на ланцюжку.

Більшість вартості реєстрації (з урахуванням обчислень на L2) походить з того факту, що сторони мають оновлювати частину загальних параметрів у постійному сховищі, що призводить до високої вартості реєстрації.

Хоча RBE дорожче за альтернативи, цей аналіз показує, що його можна впровадити на головну мережу Ethereum сьогодні - без потенційно ризикованих довірчих припущень PKI або IBE. І це до оптимізацій, таких як розгортання кількох менших (і, отже, дешевших) екземплярів або використання даних у формі блобів. Оскільки RBE має переваги перед каталогом публічних ключів та IBE у формі більш сильної анонімності та зменшених довірчих припущень, воно може бути привабливим для тих, хто цінує приватність та недовірчі налаштування.

Noemi Glaeser є кандидатом наук у галузі комп'ютерних наук в Університеті штату Меріленд та Інституті безпеки та конфіденційності Макса Планка, а також був стажером-дослідником у a16z crypto влітку 23 року. Вона є стипендіатом NSF Graduate Research Fellowship, а раніше була стажером-дослідником у NTT Research.

Додаток: Додаткові врахування

Робота з ключовими оновленнями/відкликаннями

У випадку каталогу відкритих ключів обробка оновлень ключів та відкликань є простою: для відкликання ключа сторона просить контракт видалити його з каталогу. Для оновлення ключа запис (id, pk) перезаписується новим ключем на (id, pk’).

Для відкликання в IBE Боне і Франклін запропонували, щоб користувачі періодично оновлювали свої ключі (наприклад, щотижня), а відправники включали поточний часовий період у рядок ідентифікації при шифруванні (наприклад, «Боб <поточний тиждень>»). Через невзаємодіючу природу шифрування відправники не мають способу знати, коли користувач відкликає свій ключ, тому деякі оновлення періоду є необхідними. Болдирева, Гойял та Кумар дали. більш ефективний механізм анулюванняна основі“Розмитий” IBEяке потребує двох ключів для розшифрування: «ідентифікаційного» ключа та додаткового ключа «часу». Таким чином, потрібно регулярно оновлювати лише ключ часу. Ключі часу користувачів накопичуються в бінарному дереві, і користувач може використовувати будь-який вузол по шляху (в базовому випадку потрібен лише кореневий вузол, який публікується генератором ключів). Відкликання ключа досягається шляхом припинення публікації оновлень для певного користувача (видалення вузлів по шляху цього користувача з дерева), в такому випадку розмір оновлення збільшується, але ніколи не перевищує логарифмічного відносно кількості користувачів.

Наша ефективна конструкція RBE не враховувала оновлення та анулювання,подальша роботанадає компілятор, який може «оновити» нашу схему, щоб додати ці функціональності.

Переміщення даних поза ланцюжком з DAS

Використання рішення для доступності даних (DAS) для переміщення ончейн-сховища поза мережею вплине лише на обчислення каталогу з відкритим ключем і RBE, зменшуючи обидва до однакового обсягу ончейн-сховища. RBE збереже перевагу в тому, що він є більш приватним для відправника, оскільки він все одно уникає витоку особистості одержувача через шаблони доступу. IBE вже мав мінімальне ончейн-сховище і не отримав би вигоди від DAS.

Застереження:

1. Ця стаття передрукована з [a16zcrypto], Усі авторські права належать оригінальному автору [Noemi Glaeser ]. Якщо є заперечення до цього повторного друку, будь ласка, зв'яжіться з Gate Learnкоманда, і вони оперативно цим займуться.
2. Відмова від відповідальності: Погляди та думки, висловлені в цій статті, є виключно тими автора і не становлять жодної інвестиційної поради.
3. Переклади статті на інші мови виконуються командою Gate Learn. Якщо не зазначено інше, копіювання, поширення або плагіат перекладених статей заборонено.