Джерело: Noemi Glaeser, a16z криптовалют
У криптографії завжди існувала проблема, яка полягала в тому, як правильно пов’язати Відкритий ключ (наприклад, для конкретної особи або організації) з Секретним ключем (наприклад, Відкритим ключем). Ключовим аспектом цієї проблеми є необхідність мати відкритий та однозначний спосіб відображення зв’язку між особою та Відкритим ключем, щоб усі могли спокійно використовувати ці Відкриті ключі для шифрування інформації.
Якщо немає такого явного відношення, інші, можливо, не зможуть визначити, кому саме належить цей відкритий ключ, що може призвести до надсилання шифрування інформації неправильній особі, що може призвести до витоку інформації або інших серйозних наслідків. У Web3 ця проблема все ще існує.
Щодо вищезазначених проблем, наразі існують три рішення: Public Key Directory, IBE (ідентичність заснована на шифруванні) та RBE (реєстрована заснована на шифруванні). Кожен з цих методів має свої переваги в Анонімності, взаємодії та ефективності. Наприклад, IBE потребує потужної бази довіри, але у деяких випадках воно проявляється краще в плані Анонімності та ефективності. Ця стаття спрямована на вивчення застосування цих трьох методів у Блоку блокчейні та порівняння їх переваг та недоліків.
Три методи
Зазвичай, пошифрування сполучення інформації про особу з Відкритий ключ інфраструктура (PKI) є поширеним методом, де основною частиною є каталог Відкритий ключ. У цьому методі особа, яка надсилає інформацію, повинна спілкуватися з довіреною третьою стороною (тобто установою, яка підтримує цей каталог, зазвичай це видаючий орган сертифікатів), щоб надсилати зашифровану інформацію.
Проте в умовах Web2 підтримка цього каталогу Відкритий ключ вимагає високих витрат та незручних операцій. Крім того, користувачі також стикаються з ризиком зловживання владою від видачі сертифікатів.
Деякі альтернативні рішення, запропоновані криптографами, для вирішення проблеми інфраструктури відкритих ключів (PKI). У 1984 році Аді Шамир запропонував ідентифікацію на основі шифрування (IBE), де ідентифікатор однієї сторони (наприклад, номер телефону, електронна пошта або домен ENS) може безпосередньо використовуватися як відкритий ключ. Цей підхід усуває потребу у підтримці каталогу відкритих ключів, але вводить нову проблему: потрібно покладатися на довірену сторону (генератор закритих ключів) для генерації закритого ключа.
У 2001 році Дан Бонех та Меттью Франклін запропонували першу практичну конструкцію IBE, але ця технологія не була широко використана, переважно використовувалася в закритих екосистемах, таких як корпоративне або урядове середовище. Однією з можливих причин незастосування IBE є залежність від потужного припущення про довіру, а саме довіри до Секретного ключа, отриманого від третьої сторони.
Однак, як буде обговорено в наступних розділах цієї статті, це питання довіри можна вирішити шляхом полагодження на лонгуючий, який може бути довіреною особою (тобто групою учасників) та технології блокчейн можна легко досягти цього.
Переваги та недоліки
Порівнюючи ці шифрування, потрібно враховувати багато різних факторів, я роблю два припущення:
Користувачі не оновлюють або не відкликають своїх Секретний ключ: це означає, що при обговоренні припускається, що ключі кожного користувача є фіксованими і не змінюються.
Смарт-контракт не використовує будь-які поза блокчейном доступні послуги (DAS) або blob дані: іншими словами, припустимо, що смарт-контракт повністю залежить від даних у блокчейні, не використовує зовнішніх послуг або додаткового зберігання даних.
![]()
Довідник відкритих ключів
Будь-хто може додати запис (id, pk), який не зайнятий іншими, до каталогу у блокчейні, викликавши смартконтракт.
![]()
Децентралізація PKI означає підтримку каталогу ідентифікаторів (ID) та відповідних відкритих ключів через смарт-контракт. Цей каталог є публічним і не залежить від централізованої третьої сторони. Наприклад, візьмемо ENS, вона підтримує відображення між доменним іменем (тобто ідентифікатором) та відповідними метаданими, включаючи адреси (з транзакцій з цих адрес можна вивести відкриті ключі). ENS - це складніша система, яка зберігає не тільки відкриті ключі, але й інші метадані. Функціональність децентралізованої PKI відносно проста: смарт-контракт просто підтримує список, в якому записані відповідні відкриті ключі для кожного ідентифікатора.
Коли користувач хоче зареєструвати ідентифікатор, спочатку потрібно створити пару ключів (Відкритий ключ і Закритий ключ), або використовувати вже створену пару ключів, щоб відправити свій ідентифікатор та Відкритий ключ до смартконтракту (можливо, з оплатою певної комісії). Смартконтракт перевірить, чи цей ідентифікатор вже зайнятий. Якщо його ніхто не використовує, Смартконтракт додасть цей ідентифікатор та Відкритий ключ до каталогу. Після реєстрації будь-хто зможе запитати Смартконтракт про Відкритий ключ, що відповідає певному ідентифікатору, щоб зашифрувати повідомлення для цього користувача. Якщо відправник вжешифрував повідомлення для цього користувача раніше та вже має Відкритий ключ цього користувача, йому не потрібно знову запитувати Відкритий ключ у Смартконтракту. Після отримання Відкритого ключа відправник може використовувати його, як завгодно, дляшифрування повідомлення, а потім відправити зашифроване повідомлення отримувачу, який використовує відповідний Закритий ключ для розшифрування повідомлення та відновлення тексту.
Давайте розглянемо переваги та недоліки цього методу:
Переваги та недоліки непередбачуваного розшифрування: процес розшифрування не вимагає взаємодії з іншими сторонами, розшифровувач може самостійно завершити розшифрування. Не лаконічний: система може бути недостатньо лаконічною в деяких аспектах, що може означати високу складність, великий обсяг даних або потребу в більшій кількості ресурсів. Прозорість: система може бути прозорою в деяких аспектах, що означає, що операції є відкритими та можуть бути перевірені. Інтерактивне шифрування: процес шифрування може потребувати певної взаємодії з іншими сторонами, що збільшує складність. Довільний ідентифікатор: користувачі можуть вільно обирати або використовувати довільний ідентифікатор, не обмежуючись конкретним форматом або правилами. Відправник неанонімний: ідентифікація відправника може бути недостатньо анонімною у системі.
Основане на ідентифікації шифрування (IBE)
Ідентифікація користувача здійснюється за допомогою їх Відкритого ключа, що означає, що Відкритий ключ використовується не тільки для шифрування, але й як єдиний ідентифікатор користувача. Однак цей метод потребує залежності від одного або кількох довірених сторін, які відповідають за генерацію та видачу Секретного ключа. Крім того, ці довірені сторони повинні зберігати головний Секретний ключ протягом усього життєвого циклу системи, який у деяких випадках може використовуватись для розшифрування або інших важливих операцій.
![]()
У системі IBE користувачі не створюють пару Відкритий ключ та Закритий ключ, як у традиційних системах шифрування. Натомість користувачам потрібно зареєструватися з допомогою довіреної генератора Секретний ключ. Генератор Секретний ключ має основну пару Секретний ключ (включаючи основний Закритий ключ msk та основний Відкритий ключ mpk). Коли користувач надає свій ідентифікатор, генератор Секретний ключ використовує основний Закритий ключ msk та ідентифікатор користувача для обчислення власного Закритий ключ. Згенерований Закритий ключ потрібно передати користувачу через безпечний канал, як правило, використовуючи протокол обміну Секретний ключ.
Для відправника IBE-система спрощує процес шифрування. Він повинен лише один раз завантажити головний відкритий ключ (mpk) генератора секретних ключів, а потім може використовувати ID для шифрування повідомлення. Для отримувача розшифрування також просте. Зареєстрований користувач може використовувати отриманий від генератора секретних ключів закритий ключ для розшифрування отриманого шифротексту.
Головний ключ генератора ключів (msk) повинен зберігатися тривалий час, оскільки під час роботи системи постійно потрібно генерувати нові ключі користувачів. Це відрізняється від деяких систем SNARK, де вони генеруються під час довіреної установки, але можуть бути видалені після завершення налаштування. У IBE системах, головний ключ не може бути видалений після ініціалізації, як у SNARK.
Навіть якщо головний Закритий ключ (msk) зберігається належним чином, кожен зареєстрований користувач все одно повинен довіряти генератору ключів, що він не буде читати їхні повідомлення. Це тому, що генератор ключів може в будь-який момент зберегти копію Закритого ключа користувача або використовувати головний Закритий ключ для повторного обчислення Закритого ключа користувача.
Генератор секретних ключів також може надати користувачеві неправильний або обмежений Закритий ключ, який може розшифрувати більшість повідомлень, але не може розшифрувати деякі конкретні повідомлення, встановлені Генератором секретних ключів. Це означає, що Генератор секретних ключів має здатність контролювати здатність користувача до розшифрування, тим самим можливо обмежуючи або контролюючи комунікацію користувача.
Переваги та недоліки у блокчейні
Зберігання постійне / мінімальне: система вимагає мало або постійний обсяг зберігання в Блоці у блокчейні, який не збільшується з часом.
Припущення про сильну довіру: система залежить від одного або декількох довірених сторін, що означає необхідність міцної довіри до цих сторін. Якщо ці сторони піддаються атакам або є ненадійними, безпека системи під загрозою.
Неінтерактивне шифрування: процес шифрування не вимагає взаємодії з іншими сторонами, відправник може самостійно виконувати шифрування.
Анонімність відправника: система може зберігати анонімність відправника, що захищає конфіденційність.
Довільний ідентифікатор: користувач може вільно обирати або використовувати довільний ідентифікатор, не обмежений певним форматом або правилами.
На основі зареєстрованого шифрування (RBE)
Так само, як у IBE, у цій системі ідентичність користувача (наприклад, електронна пошта Адреса або телефонний номер) безпосередньо виступає як їх відкритий ключ. Але на відміну від IBE, ця система вже не залежить від довіреної третьої сторони або групи кворуму для управління секретним ключем. Натомість ця довірена третя сторона заміщена куратором ключів.
Я буду обговорювати ефективний спосіб побудови RBE в цьому розділі, оскільки, наскільки мені відомо, він має помітну перевагу порівняно з іншими практичними способами побудови RBE. Це може бути розгорнуто в у блокчейні блоку, оскільки воно базується на парних функціях, а не на решетках.
![]()
У RBE системі кожен користувач генерує свою пару ключів - Відкритий ключ та Закритий ключ (включає Секретний ключ). Крім того, користувач повинен обчислити деякі оновлення (позначені як a на діаграмі) на основі свого Закритого ключа та загальної публічної рядка (CRS). Ці оновлення використовуються для подальших дій у системі. Наявність загального публічного рядка (CRS) означає, що налаштування системи не є повністю недовірені. Однак процес генерації CRS заснований на побудові степеня, відомих як tau. Цей метод може бути обчислений у блокчейні кількома учасниками. Якщо принаймні один учасник є чесним, то цей CRS є безпечним.
Смарт-контракт налаштовує користувачів N для очікуваної кількості, ці користувачі розподіляються в різні групи (buckets). При реєстрації користувачів у системі, вони повинні надсилати свої ідентифікаційні номери, Відкритий ключ та оновлюване значення до Смарт-контракту. Смарт-контракт підтримує групу загальних параметрів pp, які відрізняються від раніше згаданих загальних референтних значень (CRS). Можна розуміти pp як компактний опис Відкритих ключів усіх зареєстрованих користувачів у системі. Після отримання запиту на реєстрацію від користувача, Смарт-контракт перевіряє правильність оновлюваних значень. Якщо перевірка пройшла успішно, Смарт-контракт додає Відкритий ключ цього користувача до відповідних груп (buckets) у pp. Цей крок еквівалентний тому, що Відкритий ключ нового користувача додається до загальної групи параметрів системи для подальшого використання.
У системі шифрування на основі реєстрації (RBE) користувачам потрібно зберігати деяку інформацію локально, яка допомагає їм розшифровувати повідомлення. Коли новий користувач реєструється в тій же групі, цю інформацію потрібно оновити. Користувачі можуть самостійно слідкувати за блокчейном, щоб вручну оновити цю інформацію, або смартконтракт може надати інформацію про недавно зареєстрованих користувачів, яку користувачі можуть регулярно отримувати для підтримки актуальності своєї розшифровувальної інформації.
У цій системі відправнику потрібно зробити лише дві речі:
Завантажте загальний референтний рядок (CRS): це потрібно завантажити лише один раз, після чого більше не потрібно оновлювати.
Завантажте загальні параметри: Відправник час від часу повинен завантажувати останні версії загальних параметрів. Для відправника важливо, щоб ці загальні параметри містили відкритий ключ одержувача, і не потрібно завжди завантажувати оновлення, просто знайдіть відкритий ключ одержувача.
Потім відправник шифрує повідомлення та відправляє його отримувачу за допомогою завантаженого CRS, загальних параметрів та ідентифікаційного номера отримувача. Це означає, що відправник не потребує частого оновлення даних, лише впевнений, що в загальних параметрах є Відкритий ключ отримувача.
Коли користувач отримує Шифротекст повідомлення, спочатку він перевіряє допоміжну інформацію, збережену локально, щоб переконатися, чи є значення, що відповідає певній умові (наприклад, значення, перевірене якоюсь перевіркою). Якщо користувач не знаходить локально значення, що відповідає умові, це означає, що йому потрібно отримати оновлену інформацію зі Смарт-контракту. Як тільки користувач знаходить відповідне значення допоміжної інформації, він може використовувати це значення та свій Закритий ключ для розшифрування отриманого Шифротексту та відновлення початкового повідомлення.
Очевидно, що ця схема складніша за інші дві. Але вона потребує менше у блокчейні зберігання, ніж каталог Відкритий ключ, і уникне сильних довірчих припущень IBE.
Прості параметри:
- Відношення розміру параметрів, збережених у блокчейні, до кількості користувачів є сублінійним, це набагато менше, ніж потрібний об’єм зберігання каталогу відкритих ключів (лінійне зростання), але все ще не є константою, тому в цьому випадку воно не настільки ефективне, як система IBE (ідентифікаційно-засноване шифрування).
шифрування з певною взаємодією:
- Під час відправлення повідомлення відправникові потрібна копія загальних параметрів, що містять інформацію про цільового отримувача. Це означає, що відправник повинен оновлювати ці параметри в певний момент після реєстрації отримувача, але не потрібно оновлювати їх для кожного окремого отримувача, оскільки одне оновлення може містити Секретний ключ для декількох отримувачів. Загалом, взаємодія при відправленні повідомлення більш складна, ніж в IBE, але менш складна, ніж при використанні Відкритий ключ довідника.
Дешифрування з певним рівнем взаємодії:
- Подібно до шифрування, отримувачеві потрібно мати допоміжну інформацію, яка відповідає публічній версії параметрів, використаних під час шифрування. При реєстрації нового користувача в групі, публічні параметри та допоміжна інформація оновлюються, та значення Шифротексту може бути розшифроване тільки з використанням публічної версії параметрів, які були використані під час шифрування. Користувачі можуть вибрати регулярне отримання оновлення допоміжної інформації замість того, щоб оновлювати її кожен раз, окрім випадку невдачі розшифрування. Оновлення допоміжної інформації частіше, ніж публічні параметри, не викриють конфіденційну інформацію.
Відправник анонімний:
- Подібно Відкритий ключ довідника, відправник може самостійно зашифрувати повідомлення (якщо він має останні параметри), не потребуючи запитувати конкретну інформацію, пов’язану з отримувачем. Коли відправник потребує інформацію з у блокчейні, ця інформація не має стосунку до цільового отримувача (крім випадку, коли відправник запитує лише певний параметр для групи, але це може призвести до розголошення частини інформації).
Прозорість:
- Незважаючи на те, що системі потрібно налаштуватися через довіру (можливо, розподілену або зовнішньо управляється) і вивести виправлений CRS (громадський референтний рядок), після завершення налаштування вона не залежить від будь-якої довіреної сторони або арбітражу. Хоча вона залежить від координуючої третьої сторони (смарт-контракт), ця система є повністю прозорою, і будь-хто може виступити як координатор або перевірити її чесність, виконуючи перевірку стану переходу (це також є причиною, чому вона може бути реалізована як смарт-контракт). Крім того, користувачі можуть запросити стислий (не)членський сертифікат, щоб перевірити, чи їх саміх або інших осіб зареєстровано в системі. Це відрізняється від системи IBE, де важко довести, що довірена сторона не таємно розголошує розшифрування секретного ключа (наприклад, зберігає таємну копію або розголошує іншим). У порівнянні, каталог відкритих ключів є повністю прозорим.
Обмежений набір ідентифікаторів:
- Тут описано базову версію RBE конструкції. Щоб однозначно визначити групу, до якої належить ID, ID повинен мати загальний і визначений порядок. Номери телефонів можна просто сортувати, але сортування будь-якого довільного рядка може бути складним або навіть неможливим через велику кількість або нескінченність груп. Це можна полегшити, надаючи окремий контракт для обчислення такого відображення або використовуючи метод cuckoo-хешування, запропонований у подальшій роботі, для пом’якшення цієї складності.
Анонімний одержувач:
- Цей метод дозволяє зберегти анонімність отримувача Шифротексту.
