Привязка криптографических ключей к личностям была проблемой с тех пор, внедрение технологии. Одной из проблем является обеспечение и поддержание публично доступного и последовательного отображения между личностями и открытыми ключами (к которым эти личности имеют приватный ключ). Без такого отображения сообщения, предназначенные для секретности, могут идти не по плану - иногда с плачевными последствиями. Эта же проблема существует в web3.

В настоящее время существует три возможных решения. Два классических подхода - это каталог открытых ключей и шифрование на основе идентификаторов. Третий подход - это шифрование на основе регистрации, который до недавнего времени был исключительно теоретическим. Три подхода предлагают различные компромиссы между анонимностью, интерактивностью и эффективностью, которые могут показаться очевидными на первый взгляд, но в блокчейн-среде появляются новые возможности и ограничения. Цель этого поста - исследовать эту область дизайна и сравнить эти подходы при их развертывании на блокчейне. Когда пользователям нужна прозрачность и анонимность onchain, практическая схема RBE становится явным победителем - преодолевая сильное доверие, предполагаемое шифрованием на основе идентификаторов, но за определенную цену.

Три подхода в кратком изложении

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

Криптографы предложили альтернативы для обхода проблем с PKI. В 1984 году,Ади Шамир предложилшифрование на основе идентификации (IBE), при котором идентификатор стороны — номер телефона, электронная почта, доменное имя ENS — служит открытым ключом. Это позволяет избежать необходимости поддерживать каталог открытых ключей, но требует доверия к генератору ключей (третьей доверенной стороне). Дэн Бонех и Мэттью Франклин предоставили первая практическая конструкция IBEв 2001 году, но IBE не получила широкого распространения, за исключением закрытых экосистем, таких как корпоративные илиразвертывания правительства, возможно, из-за сильного доверия. (Как мы увидим далее, это предположение можно частично смягчить, полагаясь на доверенный кворум сторон, что легко обеспечивается блокчейном).

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

Оценка компромиссов

Это пространство дизайна сложно, и сравнение этих схем требует учета многих измерений. Чтобы упростить вещи, я сделаю два предположения:

1. Пользователи не обновляют или отзывают свои ключи.
2. Смарт-контракт не использует никакой службы доступности данных вне цепи (DAS) или блоб-данных.

В конце я обсуду, как каждое из этих дополнительных соображений может повлиять на наши три потенциальных решения.

Каталог открытых ключей

Краткое изложение: Любой может добавить запись (id, pk) в цепную таблицу (каталог), вызвав смарт-контракт, при условии, что ID еще не был заявлен.

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

Для регистрации пользователь генерирует ключевую пару (или использует ранее сгенерированную ключевую пару) и отправляет свой идентификатор и открытый ключ контракту (возможно, вместе с некоторой оплатой). Контракт проверяет, не был ли уже заявлен данный идентификатор, и, если нет, добавляет идентификатор и открытый ключ в каталог. На этом этапе любой может зашифровать сообщение для зарегистрированного пользователя, обратившись к контракту за открытым ключом, соответствующим идентификатору. (Если отправитель ранее что-то зашифровал этому пользователю, ему не нужно снова обращаться к контракту.) С помощью открытого ключа отправитель может зашифровать свое сообщение как обычно и отправить шифртекст получателю, который может использовать соответствующий секретный ключ для расшифровки сообщения.

Давайте посмотрим на свойства этого метода.

На отрицательной стороне баланса:

• Не кратко. Полный каталог ключей должен быть сохранен на цепочке, чтобы он всегда был доступен всем (помните, что пока мы предполагаем отсутствие DAS). Для ~900Kуникальные доменные имена, зарегистрированные в ENS на момент написания этого текста, это означает почти 90 МБ постоянного хранилища. Регистрирующиеся стороны должны заплатить за хранилище, которое занимает их заявка, около 65 тыс. газа (в настоящее время примерно 1 доллар США — см. оценку производительности ниже).
• Отчасти интерактивное шифрование. Отправитель должен прочитать цепочку, чтобы получить открытый ключ пользователя, но только если это первый раз, когда отправитель шифрует сообщение этому конкретному пользователю. (Помните, мы предполагаем, что пользователи не обновляют или отзывают свои ключи.)
• Не анонимный отправитель. Когда вы получаете чей-то открытый ключ, вы связываете себя с получателем, указывая на то, что у вас есть какие-то отношения с ним. Представьте, например, что вы получаете открытый ключ WikiLeaks: это может вызвать подозрение в том, что вы сливаете секретные документы. Эта проблема может быть решена с помощью «трафика прикрытия» (получение большого пакета ключей, большинство из которых вы не собираетесь использовать) или аналогичным образом путем запуска полного узла, или с помощью извлечения конфиденциальной информации (PIR).

С позитивной стороны:

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

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

(Пороговое) шифрование на основе идентификатора (IBE)

Описание: Идентификатором пользователя является его открытый ключ. Для работы системы требуется доверенное лицо или лица, которые выдают ключи и хранят мастер-секрет (ловушку) на протяжении всего срока службы.

В IBE пользователь не создает собственную пару ключей, а регистрируется с помощью доверенного генератора ключей. Генератор ключей имеет "ведущую" пару ключей (на рисунке msk, mpk). Получив идентификатор пользователя, генератор ключей использует главный секретный ключ msk и идентификатор для вычисления секретного ключа для пользователя. Этот секретный ключ должен быть передан пользователю по защищенному каналу (который может быть установлен с помощью протокол обмена ключами).

IBE оптимизирует опыт отправителя: он загружает генератор ключей mpk один раз, после чего может шифровать сообщение на любой идентификатор, используя сам идентификатор. Расшифровка также проста: зарегистрированный пользователь может использовать выданный ему секретный ключ генератора ключей для расшифровки шифротекста.

Мастер-секретный ключ генератора ключей более постоянный, чем"ядовитые отходы", создаваемые церемониями доверенной установкииспользуется для некоторых SNARKs. Ключевой генератор нуждается в нем, чтобы выдавать новые секретные ключи, поэтому ключевой генератор не может стереть его после настройки, так же, как участники церемоний SNARK. Это также опасная информация. Любой, у кого есть msk, может расшифровать все сообщения, отправленные любому пользователю в системе. Это означает постоянную угрозу утечки с катастрофическими последствиями.

Даже если MSK находится в безопасности, каждый пользователь, регистрирующийся в системе, должен быть уверен, что генератор ключей не будет читать его сообщения, так как генератор ключей может сохранить копию секретного ключа пользователя или повторно вычислить его из MSK в любое время. Генератор ключей может даже выдать пользователю ошибочный или «ограниченный» секретный ключ, который расшифровывает все сообщения, кроме некоторых запрещенных, определенных генератором ключей.

Это доверие может быть распределено среди кворума генераторов ключей, так что пользователю нужно доверять только определенному пороговому числу из них. В этом случае небольшое число злонамеренных генераторов ключей не может восстановить секретные ключи или вычислить неправильные ключи, и злоумышленник должен был бы взломать несколько систем, чтобы украсть полный мастер-секрет.

Если пользователи согласны с этим доверием, (порог) IBE имеет множество преимуществ:

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

Но!

• Предположение о сильном доверии. В отличие от реестра открытых ключей, где пользователи генерируют свои собственные ключи, IBE требует, чтобы доверенная сторона или кворум сторон с главным секретом (люком) выдавал ключи. Главный секрет должен храниться в течение всего срока службы системы и может скомпрометировать все сообщения зарегистрированных пользователей, если он когда-либо будет украден или использован не по назначению.

Когда вам может понадобиться использовать (пороговую) IBE? Если доступно доверенное третье лицо или лица, и пользователи готовы доверять им, IBE предлагает намного более эффективный по использованию пространства (и, следовательно, более дешевый) вариант по сравнению с реестром ключей на цепи.

Шифрование на основе регистрации (RBE)

Краткое содержание: Подобно IBE, идентификатор пользователя служит его открытым ключом, но доверенная третья сторона/кворум заменяется прозрачным аккумулятором (называемым «куратором ключей»).

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

В RBE пользователь генерирует свою собственную пару ключей и вычисляет некоторые «значения обновления» (a на рисунке), полученные из секретного ключа и общей ссылочной строки (CRS). Несмотря на то, что наличие CRS означает, что установка не является полностью ненадежной, CRS является powers-of-tauстроительство, которое может бытьСовместные вычисления в цепочкеи остается безопасным, пока есть хотя бы один честный вклад.

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

Зарегистрированным пользователям также необходимо локально поддерживать некоторую "вспомогательную информацию", которую они используют для помощи в расшифровке и которая добавляется каждый раз, когда новый пользователь регистрируется в их же группе. Они могут обновлять эту информацию сами, отслеживая блокчейн для регистраций в своей группе, или смарт-контракт может помочь, поддерживая список значений обновлений, которые он получил от последних регистраций (скажем, за последнюю неделю), которые пользователи могут периодически извлекать (по крайней мере, раз в неделю).

Отправители в этой системе загружают CRS один раз и время от времени загружают самую последнюю версию общих параметров. Для общих параметров все, что важно с точки зрения отправителя, это то, что они включают открытый ключ предполагаемого получателя; это не обязательно должна быть самая последняя версия. Затем отправитель может использовать CRS и общие параметры вместе с идентификатором получателя, чтобы зашифровать сообщение для получателя.

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

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

• Лаконичные параметры. Размер параметров, которые будут храниться в блокчейне, является сублинейным по количеству пользователей. Это намного меньше, чем общий объем хранилища, необходимый для каталога с открытым ключом (линейный по количеству пользователей), но все же не является постоянным и, следовательно, хуже по сравнению с IBE.
• Отчасти интерактивное шифрование. Чтобы отправить сообщение, отправителю нужна копия общественных параметров, которая содержит предполагаемого получателя. Это означает, что он должен обновить параметры в какой-то момент после регистрации предполагаемого получателя, но не обязательно для каждого зарегистрировавшегося предполагаемого получателя, поскольку одно обновление может включать ключи нескольких получателей. В целом, отправка сообщений более интерактивная, чем IBE, но менее интерактивная, чем каталог.
• В некотором роде интерактивная расшифровка. Как и в случае с шифрованием, получателю необходима копия вспомогательной информации, которая «совпадает» с версией публичных параметров, используемых для шифрования. В частности, как публичный параметр, так и вспомогательные корзины обновляются всякий раз, когда новый пользователь регистрируется в этой корзине, и значение, способное расшифровать зашифрованный текст, соответствует версии pp, используемой для шифрования. Как и в случае с открытыми обновлениями параметров, пользователь может решить получать обновления aux только периодически, за исключением случаев, когда расшифровка завершается сбоем. В отличие от открытых обновлений параметров, получение вспомогательных обновлений чаще по своей сути не приводит к утечке информации.
• Отправитель-аноним. Как и в случае с каталогом, отправитель может полностью зашифровать сообщение самостоятельно (при условии, что оно имеет актуальные параметры), не запрашивая информацию, относящуюся к получателю. Информация, считываемая из цепочки, когда это необходимо, не зависит от предполагаемого получателя. (Чтобы сократить обмен данными, отправитель может запросить только определенную корзину PP, что приведет к утечке частичной информации.)
• Прозрачный. Несмотря на то, что система должна быть настроена с использованием (потенциально распределенной и/или администрируемой извне) доверенной церемонии установки, выводящей пробитую CRS, она не полагается на какую-либо доверенную сторону или кворум после завершения настройки: хотя она полагается на координирующую третью сторону (контракт), она полностью прозрачна, и любой может быть координатором или проверить, что они ведут себя честно, подтвердив свои переходы между состояниями (вот почему это может быть реализованный в виде смарт-контракта). Кроме того, пользователи могут запросить краткое (не)подтверждение членства, чтобы проверить, зарегистрированы ли они (или кто-либо еще) в системе. Это отличается от дела IBE, где доверенной стороне/сторонам трудно доказать, что они тайно не раскрыли ключ дешифрования (себе путем создания секретной копии или кому-то другому). Каталог с открытым ключом, с другой стороны, полностью прозрачен.
• Ограниченный набор идентификаторов. Я описал «базовую» версию конструкции RBE. Чтобы прозрачно определить, в какой корзине находится идентификатор, идентификаторы должны иметь публичный и детерминированный порядок. Номера телефонов могут быть просто упорядочены, но упорядочивание произвольных строк неудобно, если не невозможно, так как количество корзин может быть крайне большим или неограниченным. Это можно смягчить, предлагая отдельный контракт, который вычисляет такое отображение, или принятием предложенного варианта cuckoo-хэширования.эта последующая работа.

С расширениями:

• Получатель-анонимный. схема может быть расширена так, чтобы шифротексты не раскрывали личность получателя.

В каких случаях может потребоваться использование RBE? RBE использует меньше ончейн-хранилищ, чем ончейн-реестр, и в то же время избегает предположений о сильном доверии, требуемых IBE. По сравнению с реестром, RBE также предлагает отправителю более строгие гарантии конфиденциальности. Однако, поскольку RBE только что стал жизнеспособным вариантом для управления ключами, мы пока не уверены, какие сценарии будут наиболее выгодны от этой комбинации свойств. Пожалуйста дай мне знатьесли у вас есть какие-либо идеи.

Сравнение производительности

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

У PKI нет стоимости установки и низкая стоимость регистрации на пользователя, в то время как у IBE небольшие затраты на установку и практически бесплатная регистрация на пользователя. У RBE более высокая стоимость установки и также неожиданно высокая стоимость регистрации, несмотря на низкое требуемое хранение на цепи.

Большая часть стоимости регистрации (при условии выполнения вычислений на L2) обусловлена тем, что стороны должны обновлять часть общедоступных параметров в постоянном хранилище, что приводит к высокой стоимости регистрации.

Несмотря на то, что RBE дороже, чем альтернативы, этот анализ показывает, что он может быть реально развернут в основной сети Ethereum уже сегодня — без потенциально рискованных предположений о доверии как PKI, так и IBE. И это без учета оптимизаций, таких как развертывание нескольких меньших по размеру (и, следовательно, более дешевых) экземпляров или использование данных BLOB-объектов. Учитывая, что RBE имеет преимущества перед каталогом открытых ключей и IBE в виде более высокой анонимности и снижения предположений о доверии, он может быть привлекательным для тех, кто ценит конфиденциальность и не требующие доверия настройки.

Noemi Glaeserявляется аспирантом кафедры компьютерных наук Университета Мэриленда и Института Макса Планка по вопросам безопасности и конфиденциальности и летом '23 года работала стажером в исследовательском отделе a16z crypto. Она является стипендиатом Национального научного фонда и ранее работала стажером в NTT Research.

Приложение: Дополнительные сведения

Работа с обновлениями/аннулированиями ключей

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

Для отзыва в IBE Боне и Франклин предложили, чтобы пользователи периодически обновляли свои ключи (например, каждую неделю), а отправители включали текущий период времени в строку идентификации при шифровании (например, «Боб <текущая неделя>»). Из-за неинтерактивного характера шифрования отправители не могут узнать, когда пользователь отзывает свой ключ, поэтому некоторые периодические обновления являются неотъемлемыми. Болдырева, Гоял и Кумар более эффективный механизм отзыва на основе «Fuzzy» IBE для расшифровки которого требуется два ключа: ключ «идентификации» и дополнительный ключ «время». Таким образом, только ключ времени должен регулярно обновляться. Временные ключи пользователей накапливаются в бинарном дереве, и пользователь может использовать любой узел на пути (в базовом случае необходим только корень, и это единственная часть, которая публикуется генератором ключей). Отзыв ключа достигается путем прекращения публикации обновлений для конкретного пользователя (удаления узлов на пути этого пользователя из дерева), и в этом случае размер обновления увеличивается, но никогда не превышает логарифмического числа пользователей.

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

Перенос данных вне цепи с DAS

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

Отказ от ответственности:

1. Эта статья взята из [ a16zcrypto], Все авторские права принадлежат автору оригинала [Noemi Glaeser]. Если есть возражения против этой публикации, пожалуйста, свяжитесь с Gate Learn команды, и они оперативно с этим справятся.
2. Отказ от ответственности: Взгляды и мнения, выраженные в этой статье, являются исключительно точкой зрения автора и не являются инвестиционным советом.
3. Переводы статьи на другие языки выполняются командой Gate Learn. Если не указано иное, копирование, распространение или плагиатирование переведенных статей запрещено.