Zcash намерена защитить историю платежей от квантовых атак
Ключевые выводы
- •Zakura опубликовала 15 октября release-кандидат экспериментального инструмента, который выводит уникальный ключ просмотра входящих платежей для каждого возврата по свопу Zcash или входящего свопа.
- •Адреса, используемые для свопов ZEC через NEAR Intents, записываются в публичном блокчейне NEAR, создавая долгосрочный риск «harvest now, decrypt later», если будущий квантовый компьютер восстановит общий ключ просмотра.
- •Дизайн сохраняет полномочия на расход средств, позволяя пользователям тратить средства, полученные через отдельные ключи свопов, с того же аккаунта без разделения балансов.
- •Восстановление кошелька использует зашифрованные заметки в транзакциях финансирования для исходящих свопов и детерминистическое сканирование адресов в сочетании с частным извлечением информации (PIR) для входящих свопов.
- •Реализация остаётся экспериментальной: перед реальным использованием требуются криптографическая проверка, интеграция в кошельки, включая ожидаемую поддержку Vizor, и сертификация прошивок аппаратных подписантов.

Zakura опубликовала экспериментальную реализацию, которая предоставляет адресам свопов Zcash отдельные ключи просмотра входящих платежей, сохраняя при этом полномочия аккаунта на расходование средств. Согласно release-кандидату от 15 октября, процедура деривации ключей требует проверки до выпуска рабочих адресов.
Адрес для возврата средств может раскрыть более одного свопа
Обмен ZEC через NEAR Intents требует адреса для возврата неиспользованных средств. В техническом объяснении инженер Zakura Адам Такер сообщает, что этот защищённый адрес для возврата записывается в публичном блокчейне NEAR при регистрации депозита, даже если возврат не происходит. Свопы в ZEC также публикуют адрес получателя.
Эти адреса могут выглядеть несвязанными, при этом разделяя один ключ просмотра входящих платежей. Восстановление такого ключа может, таким образом, раскрыть поступления за пределами самого свопа.
Описанная атака потребовала бы достаточно мощного будущего квантового компьютера, чтобы восстановить ключ из раскрытого адреса. Затем он мог бы определить входящие платежи, связанные с этим ключом, включая суммы и заметки. Предложение решает будущий риск конфиденциальности, а не сообщает об уже происходящей атаке. И поскольку эти адреса записаны в публичном блокчейне, раскрытые сегодня данные останутся доступными для такого анализа, как только появится подходящая машина — этот долгосрочный паттерн уязвимости в отрасли часто описывают как «harvest now, decrypt later» (собирай сейчас, расшифруй позже).
Отдельные ключи просмотра сохранят расходный аккаунт нетронутым
Zcash различает полномочия просмотра и полномочия расходования. Ключи просмотра предназначены для того, чтобы владельцы могли предоставлять доступ только для чтения к своим входящим платежам — например, длята или аудита — не отказываясь от контроля над средствами. Стандарт деривации ключей кошелька, описанный в ZIP 32, поддерживает получение ключей и адресов из единой seed-фразы, позволяя кошелькам управлять множеством адресов без отдельного резервного копирования для каждого.
Простое создание нового адреса не обязательно создаёт независимый ключ просмотра входящих платежей. Предлагаемое Zakura изменение работает за адресом: оно выводит отдельный ключ просмотра для каждого возврата по свопу или входящего свопа, как описано в документации реализации.
Реализация сохраняет полномочия аккаунта на расходование средств. Пользователь может тратить средства, полученные через эти отдельные ключи свопов, с того же аккаунта, избегая операционной нагрузки от разделения балансов между множеством аккаунтов.
При текущей модели общего ключа восстановление одного ключа может раскрыть входящие платежи по нескольким адресам. С отдельными ключами свопов восстановление ключа просмотра одного свопа раскрыло бы поступления, связанные только с этим ключом, не открывая автоматически несвязанные входящие платежи. Ключ просмотра сам по себе не даёт права тратить средства. Предусмотренная защита уже: ограничить историю платежей, которую может раскрыть один скомпрометированный ключ.
Восстановление должно находить платежи, не раскрывая владение
Отдельные ключи создают проблему обнаружения при восстановлении кошелька. Регенерация ключей из seed-фразы не сообщает кошельку, какие из них получали платежи. Проверка каждого ключа свопа по всей истории транзакций увеличивала бы объём работы по восстановлению с каждым новым свопом.
Исходящие свопы предоставляют место для записи восстановления. Предлагаемая реализация помещает зашифрованную заметку в note, принадлежащую транзакции финансирования пользователя. Эта заметка记录ует индекс, использованный для вывода ключа возврата. При восстановлении кошелек может извлечь индекс и реконструировать соответствующий ключ и адрес.
Для входящих свопов нужен другой подход, поскольку кошелек Zcash не создавал транзакцию финансирования, в которую можно было бы поместить такую заметку. Вместо этого дизайн последовательно проверяет детерминистически выведенные адреса, используя записи об оплаченных или уже раскрытых своп-провайдеру адресах, чтобы определить, насколько далеко нужно продолжать поиск.
Для поиска платежей система обнаружения получателя использует публичные фильтры, которые кошелек проверяет локально. Возможное совпадение приводит к запросу частного извлечения информации (PIR), который определяет соответствующую транзакцию без отправки серверу читаемого запроса с указанием адреса.
Затем кошелек может расшифровать платеж с помощью соответствующего ключа просмотра. Это избавляет от необходимости выполнять отдельный поиск по всей цепочке для каждого восстановленного ключа.
Частные запросы также предотвращают раскрытие через читаемую серию запросов того факта, что несколько адресов принадлежат одному владельцу. Иначе сервер мог бы получить запросы по адресу A, затем B, затем C и связать их с одним кошельком, подрывая часть разделения, созданного новыми ключами.
Проверка и поддержка кошельков остаются незавершёнными
Экспериментальный код не подтверждает, что кошельки включили эту функцию для обычных пользователей. Криптографическая проверка ещё не завершена, а в реализации указано, что аппаратные подписанты нуждаются в сертификации прошивок до включения одноразовых ключей для аппаратных аккаунтов.
В технической публикации Zakura ожидается интеграция в совместимые программные кошельки, включая Vizor, в ближайшие недели. Это оценка разработки, а не подтверждённая дата выпуска.
Эта работа отделена от планируемых на январь мер защиты платежей Zcash, которые касаются авторизации платежей. Предложение о свопах касается конфиденциальности защищённой истории входящих платежей.
Новая деривация также не может удалить адреса, уже записанные публично. Изоляция будущих ключей свопов не сотрёт более ранние раскрытия, связанные с существующим общим ключом просмотра.
Оставшаяся работа по внедрению конкретна: проверить деривацию, интегрировать обнаружение платежей и восстановление, а также сертифицировать поддерживаемые подписанты. Эти шаги должны быть выполнены, прежде чем пользователи смогут полагаться на предложенное разделение в выпущенном кошельке.
Эта статья предоставлена исключительно в информационных целях. Предлагаемая функция является экспериментальной и требует дальнейшей проверки перед использованием в реальных условиях.
Эта статья изначально опубликована на Coindoo.