Три предпочтительных варианта решения основной проблемы криптографии открытого ключа, разработанные a16z

Источник: Noemi Glaeser, a16z crypto

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

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

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

Три способа

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

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

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

В 2001 году Dan Boneh и Matthew Franklin предложили первую практическую IBE конструкцию, однако эта технология не получила широкого применения и используется в основном в закрытых экосистемах, таких как предприятия или государственные среды развертывания. Одной из причин, по которой IBE не получила широкого распространения, может быть то, что она требует сильной доверительной гипотезы, а именно доверия к секретному ключу, сгенерированному третьей стороной.

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

преимущества и недостатки

При сравнении нескольких вариантов шифрования необходимо учитывать множество различных факторов. Я делаю два предположения об этом.

Пользователи не будут обновлять или отменять свой Секретный ключ: это означает, что в обсуждении предполагается, что у каждого пользователя Секретный ключ фиксирован и не изменяется.

Смарт-контракт не использует никаких вне блокчейна данных доступности сервисов (DAS) или blob данных: другими словами, предполагается, что смарт-контракт полностью зависит от данных в блокчейне, не затрагивая данных вне цепи или дополнительного хранения данных.

Общедоступный каталог открытых ключей

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

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

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

Давайте рассмотрим преимущества и недостатки этого метода:

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

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

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

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

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

Главный Закрытый ключ генератора ключей (msk) должен быть сохранен надолго, так как во время работы системы требуется постоянно генерировать новые Закрытые ключи пользователей. Это отличается от некоторых систем SNARK, которые генерируются во время доверенной настройки и могут быть уничтожены после завершения настройки. В IBE-системе главный Закрытый ключ не может быть удален после инициализации, как в SNARK.

Даже если владелец Закрытый ключ（msk） надлежащим образом хранит, каждому зарегистрированному пользователю все еще нужно доверять генератору ключей, что он не будет читать их сообщения. Это потому, что генератор ключей в любое время может сохранить копию Закрытый ключ пользователя или использовать главный Закрытый ключ для повторного вычисления Закрытый ключ пользователя.

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

Преимущества и недостатки хранения в блокчейне: система требует небольшого или постоянного объема хранения в блоке, который не увеличивается со временем. Сильная доверительная гипотеза: система зависит от одного или нескольких доверенных сторон, что означает необходимость сильного доверия к этим сторонам. Если эти стороны нарушены или ненадежны, безопасность системы подвергается угрозе. Неинтерактивное шифрование: процесс шифрования не требует взаимодействия с другой стороной, отправитель может самостоятельно выполнить шифрование. Анонимность отправителя: система может сохранить анонимность отправителя, защищая конфиденциальность. Произвольный идентификатор: пользователь может свободно выбирать или использовать произвольный идентификатор, не ограниченный определенным форматом или правилами.

На основе зарегистрированного шифрования (RBE)

Как в IBE, в этой системе идентификация пользователя (например, электронная почта Адрес или номер телефона) непосредственно выступает в качестве его Открытый ключ. Однако, в отличие от IBE, эта система больше не зависит от доверенного третьего лица или группы quorum для управления Секретный ключ. Вместо этого доверенное третье лицо заменяется key curator.

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

В RBE-системе каждый пользователь генерирует свою пару ключей (включая открытый ключ и закрытый ключ). Пользователь также должен вычислить некоторые обновляющие значения (обозначенные как ‘a’ на рисунке) на основе своего закрытого ключа и общей строки-ссылки (CRS). Эти обновляющие значения используются для дальнейших операций в системе. Присутствие общей строки-ссылки (CRS) означает, что настройка системы не является полностью безопасной. Однако процесс генерации CRS основан на построении степеней, называемых тау, которые могут быть вычислены совместным усилием нескольких участников в блокчейне. При условии, что хотя бы один участник является добросовестным, эта CRS является безопасной.

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

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

В этой системе отправитель должен выполнить только две вещи:

Скачать общую ссылочную строку (CRS): это нужно скачать всего один раз, затем обновлять не требуется.

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

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

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

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

Простые параметры:

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

шифрование с некоторым взаимодействием:

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

Интерактивное дешифрование:

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

Отправитель анонимен:

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

Прозрачность:

• Несмотря на то, что система требует установки через настройку доверия (которая может быть распределенной или управляемой внешними силами) и выводит скорректированный CRS (общую строку ссылки), после завершения настройки она больше не зависит от любых доверенных сторон или арбитражных групп. Хотя он зависит от координирующей стороны (смарт-контракт), этот система полностью прозрачна, и любой может выступать в роли координатора или проверять, работает ли он честно, используя проверку состояния перехода (поэтому он может быть реализован как смарт-контракт). Кроме того, пользователи могут запросить краткое (не) удостоверение членства, чтобы проверить, зарегистрированы ли они или другие в системе. Это отличается от системы IBE, где сложно доказать доверенной стороне, что они не утайкивают секретный ключ для расшифровки (например, сохраняют секретную копию или раскрывают другим). В сравнении с этим, Открытый ключ каталог полностью прозрачен.

Ограниченный набор идентификаторов:

• Описывается базовая версия, построенная на RBE. Чтобы прозрачно определить, к какой группе относится идентификатор, ему необходимо иметь общий и определенный порядок. Номера телефонов можно просто сортировать, но сортировка произвольной строки может быть чрезвычайно сложной или даже невозможной, так как количество групп может быть очень большим или даже бесконечным. Это можно сделать, предоставив отдельный контракт для вычисления этого отображения или с помощью метода cuckoo-hashing, предложенного в последующих работах, чтобы смягчить эту сложность.

Анонимный получатель:

• Этот метод позволяет Шифротексту не раскрывать личности получателей.