TL;DR
- пороговая криптография распределяет способность выполнять криптографическую операцию между несколькими участниками. Операция завершается успешно только при сотрудничестве авторизованного порога. При пороговой подписи участники совместно формируют обычную цифровую подпись под одним групповым открытым ключом без предварительного восстановления полного закрытого ключа.
- обозначение t-of-n означает, что для выполнения предполагаемой операции требуется участие как минимум t из n участников. Безопасная схема обычно направлена на защиту секретности ключа от меньшего числа, чем t, попыток взлома и на сохранение доступности, пока в сети остаются как минимум t подходящих участников. Эти гарантии зависят от указанного противника, сети и модели реализации.
- метод разделения секрета Шамира делит хранящийся секрет таким образом, чтобы пороговое значение могло его восстановить. Простой метод разделения секрета Шамира не определяет, как вычислять подпись ECDSA, Schnorr или EdDSA, пока секрет остается разделённым. Протокол пороговой подписи может использовать доли Шамира внутренне, но он добавляет интерактивные вычисления, доказательства, обработку нонсов и верификацию, благодаря чему восстановление секрета становится ненужным.
- Иногда. В системе на основе DKG участники совместно создают доли и групповой открытый ключ, поэтому, согласно допущениям протокола, ни один отдельный участник не узнает полный закрытый ключ. Доверенный дилер, преобразование импортированного ключа или резервное копирование с целью восстановления могут привести к созданию полного ключа при настройке или восстановлении. Ответ определяет жизненный цикл, а не маркетинговая этикетка.
В одном блоке
Пороговая криптография распределяет криптографическую операцию между несколькими участниками, так что ни один из них не может действовать в одиночку.
Что такое пороговая криптография?
Быстрый ответ
пороговая криптография распределяет способность выполнять криптографическую операцию между несколькими участниками. Операция завершается успешно только при сотрудничестве авторизованного порога. При пороговой подписи участники совместно формируют обычную цифровую подпись под одним групповым открытым ключом без предварительного восстановления полного закрытого ключа.
Обычный ключ подписи представляет собой сосредоточенную власть. Тот, кто может использовать закрытый ключ, может подписать документ, а тот, кто навсегда его утратил, может лишиться доступа. Резервные копии повышают доступность, но создают дополнительные копии той же власти. Пороговая криптография меняет структуру: участники владеют долями, а криптографическая операция вычисляется совместно. Цель состоит в том, чтобы ни одно устройство, ни один оператор, ни одно нарушение безопасности не было достаточным ни для кражи, ни для необратимой потери.
Термин «порог» описывает такую политику, как «2 из 3» или «3 из 5». В схеме подписи «2 из 3» любые два авторизованных участника могут завершить операцию. Один участник в одиночку не должен иметь возможности подписать документ или узнать лежащий в основе секрет. Доли могут храниться на устройствах, аппаратных модулях безопасности, серверах, в автономных системах или у разных людей. Архитектура имеет такое же значение, как и арифметика: три доли, контролируемые одним облачным администратором, могут вести себя как одна область отказа, а не как три независимые стороны.
MPC (безопасные многосторонние вычисления) — это более широкое понятие, чем пороговые подписи. Безопасные многосторонние вычисления изучают, как стороны могут вычислять функции над частными входными данными, контролируя при этом, какая информация раскрывается. Генерация пороговых ключей, подпись, дешифрование и генерация случайных чисел являются специализированными приложениями. Поэтому кошелек, позиционируемый как «MPC», может использовать совершенно разные протоколы, пороговые значения, схемы восстановления и модели безопасности. Само по себе это обозначение мало что говорит о фактических гарантиях.
Что на самом деле гарантирует t-of-n?
Быстрый ответ
обозначение t-of-n означает, что для выполнения предполагаемой операции требуется участие как минимум t из n участников. Безопасная схема обычно направлена на защиту секретности ключа от меньшего числа, чем t, попыток взлома и на сохранение доступности, пока в сети остаются как минимум t подходящих участников. Эти гарантии зависят от указанного противника, сети и модели реализации.
Пороговое значение не является универсальной гарантией. Эксперты выделяют такие понятия, как секретность, неподдельность, доступность, отказоустойчивость и подотчётность. Конструкция может защищать ключ, но при этом позволять одному злонамеренному участнику срывать каждую попытку подписания. Она может выявить саботажника, но всё равно оказаться неспособной завершить подписание без замены этого участника. Она может допускать одного скомпрометированного подписанта в рамках модели статического противника, но выйти из строя, если злоумышленник со временем скомпрометирует разных подписантов.
| Свойство | Вопрос, на который он отвечает | Почему это важно |
|---|---|---|
| Секретность / конфиденциальность ключа | Могут ли менее t долей раскрыть секретный ключ или предоставить достаточно информации для его восстановления? | Защищает базовый центр авторизации от компрометации при количестве долей, меньшем порогового значения. |
| Неподдельность | Может ли злоумышленник создать действительную подпись без авторизованного порогового значения? | Основная цель безопасности пороговой подписи. |
| Активность | Могут ли добросовестные участники завершить операцию, если доступно достаточное количество из них? | Безопасный, но постоянно прерывающий работу кошелек непригоден для использования. |
| Устойчивость | Может ли протокол завершить операцию, несмотря на некорректные сообщения или злонамеренных участников, а не просто прервать её? | Определяет устойчивость к атакам типа «отказ в обслуживании». |
| Идентифицируемое прерывание | Если протокол завершается с ошибкой, могут ли добросовестные участники определить, какой из участников нарушил правила? | Обеспечивает возможность исключения участников, установления ответственности и восстановления работоспособности. |
| Проактивная безопасность | Можно ли обновлять доли, чтобы компрометации, произошедшие в разное время, не накапливались бесконечно? | В рамках данной модели возможности злоумышленника ограничиваются одним окном обновления. |
| Адаптивная безопасность | Что произойдет, если злоумышленник выберет, кого скомпрометировать, во время или после наблюдения за сессиями протокола? | Более точно моделирует долговечные производственные системы. |
| Композируемость | Сохраняются ли гарантии при наличии множества параллельных сеансов и сопутствующих протоколов? | Важно для масштабной подписи сервисов. |
Даже фраза «менее t долей ничего не раскрывают» требует уточнения. Идеальное распределение секрета Шамира дает утверждение из теории информации о математических долях. Развернутый пороговый кошелек также генерирует транскрипты, публичные обязательства, журналы, информацию о времени и сообщения об ошибках. Эти сопутствующие системы могут привести к утечке метаданных, сделать возможными атаки с выбранным входом или выявить недостатки реализации, не противореча при этом идеальной теореме о распределении секрета.
Вывод: t-of-n указывает кворум. Оно не указывает модель противника, не указывает, может ли злонамеренный подписант остановить систему, можно ли обновлять доли или был ли код независимо проверен.
Почему метод разделения секрета Шамира не то же самое, что пороговая подпись?
Быстрый ответ
метод разделения секрета Шамира делит хранящийся секрет таким образом, чтобы пороговое значение могло его восстановить. Простой метод разделения секрета Шамира не определяет, как вычислять подпись ECDSA, Schnorr или EdDSA, пока секрет остается разделённым. Протокол пороговой подписи может использовать доли Шамира внутренне, но он добавляет интерактивные вычисления, доказательства, обработку нонсов и верификацию, благодаря чему восстановление секрета становится ненужным.
Конструкция Шамира 1979 года представляет секрет в виде постоянного слагаемого случайного многочлена. Каждый участник получает точку на этом многочлене. При достижении любого требуемого порогового значения можно интерполировать многочлен и восстановить секрет; при меньшем количестве точек секрет остаётся неопределённым. Это элегантный и мощный способ защиты резервных копий, материалов, находящихся на хранении у третьей стороны, и секретов восстановления.
Операционное ограничение возникает, когда секрет необходимо использовать. Если единственным доступным инструментом является реконструкция Шамира, уполномоченные участники объединяют свои фрагменты на одном компьютере, получают полный закрытый ключ и запускают обычный алгоритм подписи. В этот момент устройство реконструкции, память, журналы процессов, область подкачки и оператор становятся единой точкой уязвимости. Секрет можно удалить впоследствии, но уязвимость уже существовала.
Пороговая подпись выполняет арифметические операции над долями. Участники создают частичные значения, доказывают или проверяют, что эти значения сформированы правильно, и объединяют частичные результаты в подпись. Полный ключ подписи не обязательно должен появляться во время сеанса подписи. Многие пороговые схемы используют в качестве одного из компонентов разделение полиномов по Шамиру. Реальное различие заключается между хранением секрета с возможностью восстановления, с одной стороны, и полностью распределенным протоколом подписи, с другой.
| Возможности | Простая резервная копия Шамира | Пороговая подпись |
|---|---|---|
| Хранение секрета в разных местах | Да. | Да, в виде активных долей ключа или состояния протокола. |
| Использование меньшего количества, чем пороговое | Реконструкция невозможна. | В рамках данной модели безопасности подпись не является действительной. |
| Подписывайте без реконструкции ключа | Нет, сам по себе — нет. | Да. |
| Создать одну обычную подпись | Только после восстановления и обычного подписания. | Да, путем объединения долей подписи. |
| Требуется контроль нонса и транскрипта | Не только для хранения. | Да; это имеет ключевое значение для безопасности подписания. |
| Изменение участников без изменения открытого ключа | Требуется явный процесс повторного распределения. | Возможно только в том случае, если схема поддерживает обновление или повторное предоставление доступа. |
| Наилучшее соответствие | «Холодное» резервное копирование и восстановление после сбоев. | Повторная операционная подпись с распределенными полномочиями. |
Существует ли когда-либо полный закрытый ключ?
Быстрый ответ
Иногда. В системе на основе DKG участники совместно создают доли и групповой открытый ключ, поэтому, согласно допущениям протокола, ни один отдельный участник не узнает полный закрытый ключ. Доверенный дилер, преобразование импортированного ключа или резервное копирование с целью восстановления могут привести к созданию полного ключа при настройке или восстановлении. Ответ определяет жизненный цикл, а не маркетинговая этикетка.
Доверенный дилер
Дилер генерирует обычный закрытый ключ, создает доли и распределяет их. Это может быть безопасно, если дилер использует сильную случайность, аутентифицирует каждого участника, проверяет обязательства по распределению и надежно удаляет исходный секрет и неиспользованные доли. Тем не менее это создает момент и субъекта, обладающего знанием полного ключа. RFC 9591 выносит генерацию ключей за пределы основного протокола FROST и включает процедуру с участием доверенного дилера лишь в качестве приложения.
Распределенное генерация ключей
Протокол DKG позволяет участникам вносить случайные данные и совместно выводить доли, а также общий открытый ключ. Ни одна из сторон не должна узнать соответствующий закрытый ключ, при условии, что протокол реализован правильно и порог коррупции не превышен. DKG — это не единый алгоритм: различные схемы исходят из разных допущений относительно широковещательных передач, аутентифицированных каналов, жалоб, злонамеренных участников и доступности участников.
Импорт существующего ключа
Учреждения могут захотеть сохранить существующий адрес, историю счёта или открытый ключ. Некоторые протоколы поддерживают преобразование или совместное использование существующего ключа. Этот процесс может потребовать от владельца ключа работы с полным ключом или может использовать специализированные протоколы импорта. История безопасности до импорта по-прежнему имеет значение: распределение ключа не отменяет ранее сделанную копию, фотографию, резервную копию или компрометацию.
Восстановление и аварийная реконструкция
Некоторые системы сохраняют «аварийный» путь, позволяющий восстановить ключ из резервных материалов. Это может улучшить восстановление после сбоев и одновременно вновь привести к раскрытию единого ключа, чего по замыслу пороговой архитектуры и следовало избежать. Другие системы сознательно не предоставляют пути восстановления и требуют наличия определенного порога активных участников для каждого действия по восстановлению. Ни один из этих подходов не является автоматически правильным; выбор должен быть явным, протестированным и включенным в модель угроз.
Как MPC формирует одну подпись из нескольких долей?
Быстрый ответ
стороны согласовывают точное сообщение и сеанс, генерируют одноразовую случайную величину или обязательства, вычисляют доли подписи из своих частных долей, проверяют эти доли и объединяют их. Результатом является стандартная подпись под групповым открытым ключом. Протокол раскрывает итоговую подпись и любые метаданные, предоставляемые приложением, но не полный закрытый ключ.
Цифровая подпись представляет собой математическое соотношение между сообщением, открытым ключом и секретным материалом для подписи. Пороговые протоколы используют алгебру схемы подписи или общие инструменты безопасных вычислений, благодаря чему каждый участник вносит свой вклад в это соотношение, не раскрывая свою входную долю. Детали значительно различаются между подписями типа Шнорра и ECDSA, но жизненный цикл операции имеет общие этапы.
- Создание сеанса. Система определяет групповой ключ, набор участников, пороговое значение, точное сообщение, дайджест подписи, специфичный для цепочки, версию протокола и уникальный идентификатор сеанса.
- Проверка входных данных. Каждый участник проверяет, является ли сообщение синтаксически корректным и разрешено ли оно политикой. Протокол с пороговым значением не должен превращаться в оракул подписи для произвольных входных данных.
- Подготовка нонса или предварительной подписи. Участники генерируют одноразовые секретные значения, обязательства и, в некоторых схемах ECDSA, материалы для умножения. Эти значения должны быть уникальными, правильно привязанными к сеансу и защищенными так же, как ключевой материал.
- Генерация долей подписи. По крайней мере t участников объединяют свои частные доли с общей стенограммой для получения частичных подписей или соответствующих результатов MPC.
- Верификация и агрегация долей. Недопустимые доли отбрасываются. Координатор или все участники объединяют допустимые доли в одну окончательную подпись.
- Обычная проверка. Блокчейн или приложение проверяет итоговую подпись с помощью общего открытого ключа группы, используя свой обычный верификатор. Ему не требуется понимать внутренний протокол пороговых значений.
Координатор — это роль в протоколе, а не обязательно доверенный владелец ключа. Например, в FROST координатор может собирать обязательства, выбирать набор подписантов, распределять сообщение и агрегировать доли, не получая при этом частных долей. Координатор по-прежнему может вызвать отказ в обслуживании, отправить несогласованные представления или представить вредоносное сообщение, поэтому по-прежнему необходимы аутентифицированная связь и проверка со стороны участников.
Почему важны нонсы, предварительная обработка и координаторы?
Быстрый ответ
пороговая подпись вводит состояние протокола, связанное с одноразовыми нонсами, обязательствами участников и общей стенограммой. Повторное использование или манипулирование нонсом, смешивание сеансов, принятие некорректно сформированных доказательств или разрешение участникам подписывать разные сообщения может привести к раскрытию группового ключа или появлению недействительных подписей. Предварительная обработка сокращает задержку, но создает ценный запас данных до подписания, который необходимо защищать.
Нонсы являются частью секрета
Подписи Schnorr, EdDSA и ECDSA зависят от секретных значений, уникальных для каждой подписи, которые обычно называют нонсами. При обычной односторонней подписи надёжная библиотека может генерировать или выводить нонс в пределах одной доверенной границы. В протоколе с пороговым значением несколько сторон совместно формируют или вычисляют состояние, связанное с нонсом. Повторное использование нонса, повторное воспроизведение обязательства или намеренно некорректно сформированное сообщение умножения могут превратить одну или несколько сессий подписи в атаку с извлечением ключа. В RFC 9591 прямо указывается, что детерминированное выведение нонса, подходящее для обычного EdDSA, небезопасно в многосторонней среде и требует генерации новых, равномерно случайных нонсов.
Предварительная обработка выполняется до формирования сообщения
Многие системы порогового ECDSA вычисляют ресурсоемкие данные до того, как становится известна транзакция. Таким образом, онлайн-фаза может быть сведена к небольшому количеству сообщений, что полезно для «холодных» подписантов и сетей с высокой задержкой. Компромисс носит операционный характер: предварительные подписи становятся криптографическим ресурсом одноразового использования. Повторное использование, откат, дублирование между репликами или потеря синхронизации состояния могут привести к катастрофическим последствиям. Резервные копии не должны восстанавливать использованные предварительные подписи так, как если бы они были неиспользованными.
Привязка к сеансу предотвращает атаки типа «mix-and-match»
Каждое сообщение должно быть привязано к версии протокола, открытому ключу группы, набору участников, дайджесту сообщения, цепочке, сети, роли подписанта и уникальному сеансу. Участник должен отклонять устаревшие или несогласованные обязательства и подтверждать, что окончательные байты транзакции совпадают с байтами, авторизованными политикой. Именно здесь проектирование приложения пересекается с криптографией: формально безопасное ядро подписи всё равно может подписать неверную цепочку, неверный нонс, неверный вызов контракта или неверный адрес назначения, если адаптер предоставляет некорректные данные.
Надежность не достигается автоматически
Некоторые протоколы гарантируют секретность и невозможность подделки, но прерывают работу, если один из участников ведет себя некорректно. Идентифицируемое прерывание позволяет указать участника, ответственного за сбой; цель отказоустойчивости — завершить операцию, несмотря на наличие некоторых недобросовестных участников. RFC 9591 не претендует на отказоустойчивость и отмечает, что оболочка более высокого уровня, такая как ROAST, может решать проблему злонамеренных сбоев в некоторых условиях.
Что такое FROST и что стандартизирует RFC 9591?
Быстрый ответ
FROST — это пороговый протокол Шнорра, который формирует подпись после двух раундов обмена данными. RFC 9591 определяет протокол подписи, наборы шифров и тестовые векторы. Он не стандартизирует распределенное генерацию ключей, отказоустойчивость, защиту метаданных или вариант однораундовой предварительной обработки, и представляет собой информационный исследовательский RFC IRTF, а не интернет-стандарт.
FROST использует преимущества линейной структуры подписей Шнорра. Каждый выбранный участник владеет долей группового ключа подписи. В первом раунде участники генерируют одноразовые нонсы и публикуют обязательства. Во втором раунде они вычисляют доли подписи, привязанные к сообщению, набору подписантов и обязательствам. Координатор проверяет и объединяет доли для получения окончательной подписи Шнорра.
| RFC 9591 включает | RFC 9591 сам по себе не предоставляет |
|---|---|
| Двухраундовый протокол подписи FROST. | Полный стандарт распределённой генерации ключей. |
| Наборы шифров для Ed25519, ristretto255, Ed448, P-256 и secp256k1. | Автоматическую совместимость со всеми протоколами, использующими ту же кривую. |
| процедуры проверки и агрегации долей подписи; | Надежное завершение процесса даже при наличии злонамеренных участников. |
| Генерация ключей с помощью доверенного посредника в качестве информативного приложения. | Гарантия отсутствия полного ключа на этапе настройки. |
| Соображения безопасности, касающиеся повторного использования нонсов, побочных каналов и проверки сообщений. | Конфиденциальность метаданных, предотвращение понижения уровня безопасности или постквантовая безопасность. |
| Тестовые векторы для указанных наборов. | Разбор транзакций, специфичный для цепочки, политика или восстановление кошелька. |
Важно различать исследовательский RFC и интернет-стандарт. RFC 9591 отражает консенсус Исследовательской группы Crypto Forum и предоставляет разработчикам точную общую спецификацию, однако в разделе о статусе указано, что он носит информационный характер и не входит в процесс стандартизации IETF. NIST отдельно начал многолетний процесс оценки пороговых схем; FROST входит в число схем, рассматриваемых в рамках этого конкурса.
Совместим ли набор RFC secp256k1 с Taproot в Биткойне?
Не автоматически. BIP340 для Биткойна определяет открытые ключи, содержащие только x, тегированные хеши, конкретное уравнение проверки и 64-байтовое кодирование. Набор шифров FROST secp256k1 в RFC 9591 использует собственную конструкцию хешей с разделением по доменам и общую обработку сжатых точек. Протокол может использовать ту же кривую и при этом генерировать подписи, которые верификатор BIP340 отклоняет. Поэтому пороговая система Schnorr, совместимая с Bitcoin, требует конструкции и реализации, явно разработанных с учётом семантики BIP340.
Вывод: «Использует secp256k1» не является сертификатом совместимости. Кривая — это лишь один из уровней системы подписи.
Почему пороговый ECDSA сложнее, чем пороговый Schnorr?
Быстрый ответ
подписи Шнорра являются линейными, поэтому можно складывать правильно взвешенные доли подписи. ECDSA включает умножение на обратное значение секретного нонса, что вынуждает стороны вычислять произведения и обратные значения общих секретов, не раскрывая их. Это требует дополнительных механизмов MPC, доказательств и раундов протокола.
В упрощённом виде подпись ECDSA содержит значение s = k^-1(H(m) + r x) mod q, где x — закрытый ключ, а k — одноразовый нонс. В пороговой конфигурации ни x, ни k не должны быть известны одной из сторон. Поэтому участники должны получить аддитивные или полиномиальные доли произведений, включающих x и k, и, в конечном итоге, выражения, связанного с обратным элементом, при этом не позволяя злонамеренной стороне выбирать некорректные значения, которые приводят к утечке другой доли.
Протоколы на основе алгоритма Пайлье используют аддитивно-гомоморфное шифрование и подпротоколы «умножение-к-сложению» (MtA). Другие семейства протоколов используют классовые группы или «обливиозный перенос». Доказательства с нулевым разглашением или проверки согласованности демонстрируют, что зашифрованные значения и доли находятся в требуемых диапазонах и удовлетворяют соотношениям протокола. Эти компоненты создают более обширную плоскость реализации, чем пороговый протокол Шнорра: арифметика больших целых чисел, системы доказательств, управление транскриптами, предварительная обработка, определение причин сбоев и множество криптографических допущений.
| Размерность | Пороговый Шнорр / FROST | Пороговый ECDSA |
|---|---|---|
| Базовая алгебра | Линейное соотношение; доли подписи можно суммировать. | Нелинейное соотношение, включающее обратное значение общего нонса и произведения секретов. |
| Типичное взаимодействие при подписании | Два раунда в RFC 9591; варианты предварительной обработки существуют за пределами RFC. | Зависит от протокола; онлайн/офлайн-архитектуры могут сократить продолжительность онлайн-фазы. |
| Вспомогательные примитивы | Группа порядка простого числа, хэши, разделение секрета, коммитменты и верификация долей. | Могут быть добавлены шифрование Пайлье или шифрование с использованием групп классов, «обливиозный» перенос, доказательства диапазона и проверки с нулевым разглашением. |
| Сложность реализации | Значительная, но сравнительно простая. | Более высокая и исторически богатая ловушками реализации. |
| Результат верификации | Обычная подпись Шнорра или совместимая с ней подпись для выбранного набора. | Обычная подпись ECDSA при соблюдении правил кодирования, специфичных для цепочки. |
| Обзор протоколов | FROST имеет общую спецификацию CFRG. | Несколько семейств протоколов; единого универсального стандарта развертывания нет. |
Пороговый ECDSA по-прежнему важен, поскольку он используется для расходования ключей в старых версиях Биткойна и SegWit v0, для внешних счетов в Ethereum и во многих других развернутых системах. Совместимость с существующими адресами и аппаратным обеспечением может оправдать эту сложность, но выбор следует делать с четким осознанием более широкой поверхности атаки.
Какие семейства протоколов порогового ECDSA имеют значение?
Быстрый ответ
В сфере внедренных решений и научных исследований используются протоколы Paillier/MtA, такие как Gennaro-Goldfeder и CGGMP, двухсторонние и многосторонние протоколы Doerner-Kondi-Lee-Shelat, конструкции на основе классов и групп, а также более новые двух- и трёхраундовые схемы. Названия, такие как GG18, GG20 и CGGMP21, обозначают конкретные научные статьи, а не единый взаимозаменяемый отраслевой стандарт.
Область быстро развивается, и прозвища протоколов часто используются неточно. Разработчики должны указывать точную редакцию статьи, набор параметров, доказательство безопасности и версию кода. Библиотека, обозначенная как «GG18», может включать более поздние исправления, опускать необходимые доказательства, добавлять проприетарную предварительную обработку или реализовывать более старый уязвимый вариант. Год в прозвище не является достаточным подтверждением безопасности.
| Протокол / семейство | Форма | Важный вклад или предостережение |
|---|---|---|
| Lindell-Nof и связанные с ним двухсторонние ECDSA | Преимущественно конструкции типа «2 из 2». | Практическая распределенная генерация ключей и подпись для двух сторон; существуют различные допущения и конструкции в отношении безопасности. |
| GG18 / обновленная версия Gennaro-Goldfeder | Общая ECDSA с пороговым значением. | Быстрая настройка без посредника и практическая многосторонняя подпись с использованием алгоритмов Пайлье/MtA; детали реализации и модификации имеют значение. |
| GG20 | Общая ECDSA с пороговым ключом и предварительной обработкой. | Добавлена неинтерактивная онлайн-фаза и возможность идентифицируемого прерывания; в опубликованных исправлениях устранены проблемы. |
| CGGMP / CGGMP21 | Любое количество подписантов; проактивная и ориентированная на UC архитектура. | Объединяет предварительную обработку, проактивное обновление, адаптивную безопасность и идентифицируемое прерывание при указанных допущениях. |
| Семейства DKLS для двух и нескольких сторон | Протоколы ECDSA на основе OT. | Во избежание допущений Пайе в некоторых конструкциях; в более поздних работах предлагается подпись с нечестным большинством за три раунда. |
| Конструкции на основе классов-групп и более новые | Различные пороговые значения и компромиссы между онлайн- и офлайн-режимами. | Цель — улучшить пропускную способность, количество раундов, допущения или подотчетность; в рамках конкурса NIST собираются многочисленные кандидаты. |
В статье не проводится ранжирование этих протоколов. Производительность зависит от количества участников, географического положения, порогового значения, предварительной обработки, аппаратного обеспечения, допущений о доступности и качества реализации. Более новая статья не обязательно безопаснее зрелой реализации, а зрелая реализация не является безопасной только потому, что лежащая в ее основе статья хорошо изучена.
Чем отличаются FROST, MuSig2 и обычная мультиподпись?
Быстрый ответ
FROST — это пороговая схема Шнорра типа «t из n», использующая доли одного группового ключа. MuSig2 объединяет несколько независимых ключей Шнорра и требует участия всех n подписантов, поэтому это схема типа «n из n», а не общая пороговая схема. Обычная многоподпись в цепочке блоков требует от скрипта или контракта блокчейна проверки нескольких ключей или подписей в соответствии с собственной политикой.
| Особенности | FROST | MuSig2 | Мультиподпись в цепочке / кошелек на основе контракта |
|---|---|---|---|
| Структура подписантов | Доли одного группового секрета. | Несколько полных независимых закрытых ключей. | Несколько полных ключей или других полномочий, определенных контрактом. |
| Кворум | t из n. | n из n. | m из n, специфичное для цепочки, или программируемая политика. |
| Верификатор видит | одну подпись и один открытый ключ группы. | одну агрегированную подпись Шнорра и агрегированный ключ | Несколько подписей, выполнение скрипта или вызов контракта — если только это не скрыто с помощью такой конструкции, как путь к ключу Taproot. |
| Генерация ключей | Дилер или DKG / распределенная настройка. | Неинтерактивное объединение существующих открытых ключей. | Каждый подписант создает обычный ключ; политика развертывается в цепочке. |
| Замена участника | Может сохранять групповой открытый ключ посредством повторного обмена, если это поддерживается. | Смена подписантов приводит к изменению агрегированного ключа. | Часто требует нового скрипта, обновления состояния контракта или нового адреса; реализация может варьироваться. |
| Основной стандарт | RFC 9591 для двухэтапной подписи по алгоритму FROST. | BIP327 для MuSig2, совместимого с BIP340. | Правила скриптов Bitcoin/Taproot, код контракта Ethereum или другой механизм, специфичный для конкретной цепочки. |
MuSig2 иногда называют пороговой подписью, поскольку в ней участвуют несколько сторон. В BIP327 явно указано, что это схема мультиподписи «n из n», а не пороговая подпись «t из n». Каждый ключ, используемый в агрегации, остаётся полноценным ключом для подписи. Если один из участников недоступен, группа не сможет подписать транзакцию, если не предусмотрен отдельный резервный путь.
Taproot усложняет сравнение видимости. Транзакция с использованием MuSig2 или другого агрегированного ключевого пути может выглядеть как обычная транзакция BIP340 с одним подписантом, а дополнительные пути скрипта остаются скрытыми, пока не будут использованы. Транзакция с использованием пути скрипта раскрывает выполненную ветвь и доказательство, но не обязательно каждую неиспользованную ветвь. Поэтому утверждение «мультиподпись видна, пороговая подпись невидима» является слишком абсолютным.
Пороговая подпись против мультиподписи в цепочке: какие компромиссы меняются?
Быстрый ответ
мультиподпись в цепочке заставляет блокчейн обеспечивать кворум с помощью независимых ключей или логики контракта. Пороговое подписание обеспечивает кворум вне цепочки и предоставляет цепочке один открытый ключ и одну подпись. Мультиподпись обычно предлагает более простую, независимо проверяемую политику; пороговое подписание предлагает компактные подписи, конфиденциальность политики и потенциальную непрерывность адресов ценой более сложной внецепочечной криптографии.
Это сравнение не является универсальным рейтингом. Скрипт Биткойна, Taproot и счета смарт-контрактов Ethereum предоставляют разные возможности. Некоторые цепочки поддерживают эффективную встроенную мультиподпись; другие требуют использования кошельков на основе контрактов или вообще не имеют гибкого скрипта. Пороговое подписание позволяет цепочке видеть привычную подпись, но внецепочечный протокол становится частью доверенной вычислительной базы.
| Аспект | Внутрицепочечная мультиподпись | Пороговая подпись |
|---|---|---|
| Где обеспечивается кворум | Правилами валидации блокчейна или кодом контракта. | С помощью внецепочечного криптографического протокола. |
| Ключи | Каждый подписант обычно владеет полным независимым ключом. | Каждый участник владеет долей одного группового ключа для подписания. |
| Возможность аудита | В зависимости от структуры политика и подписи могут быть доступны для проверки в цепочке. | Верификатор обычно видит один ключ и одну подпись; внутреннее кворум не подтверждается в цепочке. |
| Комиссии и объем данных | Может потребоваться больше данных или выполнение контрактов; агрегация Taproot может уменьшить эти затраты. | Обычно на уровне цепочки используется одна обычная подпись. |
| Изоляция сбоев | Ошибка у одного подписанта не обязательно приводит к раскрытию остальных полных ключей. | Иногда из-за недостатка протокола или реализации групповой ключ может быть извлечен даже у добросовестных участников. |
| Непрерывность адресов | Изменение политики часто приводит к изменению состояния скрипта или контракта; дизайн варьируется. | Некоторые протоколы повторного обмена сохраняют тот же открытый групповой ключ и адрес. |
| Переносимость | Зависит от поддержки скриптов или контрактов цепочки. | Зависит от точной совместимости подписей, а также от корректности адаптера цепочки. |
| Восстановление | Можно кодировать резервные ключи, задержки или механизмы управления непосредственно в цепочке. | Зависит от обновления вне цепочки, повторного обмена, резервного копирования и архитектуры сервиса. |
Эффективная архитектура может сочетать оба подхода. Например, выход Taproot может использовать агрегированный или пороговый путь ключей для рутинных расходов и сохранять скрытые пути скриптов для восстановления с задержкой по времени или в экстренных ситуациях. Смарт-аккаунт Ethereum может требовать ECDSA-подписи, сгенерированной с использованием порогового алгоритма, а также ограничений на уровне контракта. Многоуровневость может снизить один риск и увеличить операционную сложность, поэтому каждая ветвь восстановления должна быть протестирована, а не просто задокументирована.
Работает ли пороговая подпись в любой блокчейне?
Быстрый ответ
нет. Протокол с пороговой подписью должен генерировать именно ту подпись, формат открытого ключа и дайджест сообщения, которые проверяет целевая цепочка. Соответствие эллиптической кривой в некоторых случаях необходимо, но недостаточно. Хеширование, кодирование, канонизация, идентификаторы восстановления, вывод адресов и семантика транзакций, специфичные для конкретной цепочки, — всё это может нарушить совместимость.
Стек подписей блокчейна состоит из нескольких уровней: математическая кривая, уравнение подписи, кодирование открытого ключа, кодирование подписи, сериализация транзакций, дайджест подписи, разделение доменов, правила канонических значений и семантика счетов или скриптов. Пороговое подписание должно соответствовать всем этим уровням. Фраза «работает в любой цепочке с той же кривой» игнорирует большую часть этого стека.
| Уровень совместимости | Пример того, почему это важно |
|---|---|
| Кривая и группа | secp256k1, P-256 и Ed25519 используют разные группы и кодировки. |
| Уравнение подписи | Общий алгоритм Шнорра над secp256k1 не является автоматически алгоритмом Шнорра BIP340 для Биткойна. |
| Хеш-задачи / разделение доменов | Один и тот же R и открытый ключ могут генерировать разные челленджи при разных правилах хеширования. |
| Кодировка подписи | В Bitcoin BIP340 используется фиксированное 64-байтовое кодирование; системы ECDSA могут использовать DER, компактное кодирование или r/s плюс метаданные восстановления. |
| Канонизация | Политики Ethereum и Bitcoin по-разному ограничивают ECDSA-подписи с высоким s; адаптер пороговых значений должен выдавать допустимые значения. |
| Подпись дайджеста | Флаги sighash в Bitcoin, типизированные транзакции Ethereum и сообщения, специфичные для контрактов, подписывают разные последовательности байтов. |
| Производство адресов | Один и тот же открытый ключ может сопоставляться с разными адресами в разных цепочках или для разных типов счетов. |
| Политика приложения | Допустимая подпись всё равно может авторизовать неверную сеть, контракт токена, нонс, сумму или адрес назначения. |
Биткойн
Расходование средств с помощью ключей Legacy и SegWit v0 использует алгоритм ECDSA, в то время как подписи по пути ключей Taproot используют алгоритм Шнорра BIP340. BIP340 имеет специфические ключи, содержащие только x, и хеширование с тегами. MuSig2 BIP327 явно разработан для BIP340. Универсальная библиотека threshold-ECDSA или FROST нуждается в адаптере для Биткойна, который обрабатывает построение sighash, тип скрипта, настройку ключей, правила нонса и допустимую кодировку подписи.
Ethereum
Учёты, принадлежащие внешним владельцам, используют ECDSA secp256k1 и восстанавливают адрес из компонентов подписи. Типы транзакций Ethereum, идентификаторы цепочек и структурированные данные EIP-712 используют отдельные домены подписи. EIP-2 отклоняет подписи транзакций с высоким s. Поэтому подписант с пороговым ключом должен генерировать канонические значения r и s, а также правильную информацию для восстановления для конкретного полезного груза.
Системы на основе Ed25519
RFC 9591 включает наборы, совместимые с Ed25519 и Ed448, конечные подписи которых могут проверяться соответствующими стандартными верификаторами. Приложение по-прежнему должно предоставлять точное сообщение цепочки, формат открытого ключа и политику транзакций. Совместимость с верификаторами не проверяет интеграцию с кошельком.
Как работают обновление, повторное распределение, восстановление и изменения в составе участников?
Быстрый ответ
проактивное обновление заменяет каждый шар на новый шар того же секрета, оставляя открытый ключ группы без изменений. Перераспределение также может изменять порог или набор участников в протоколах, предназначенных для этого. Ни одна из этих операций не выполняется автоматически: требуется достаточное количество авторизованных участников, аутентифицированная связь, правильное состояние системы и явная поддержка протокола.
Проактивное обновление
Обновление добавляет долю с нулевым значением или иным образом перераспределяет доли таким образом, чтобы базовый групповой секрет оставался прежним. Старые доли должны стать непригодными для использования после обновления. В рамках проактивной модели безопасности злоумышленник, который со временем компрометирует разных участников, должен собрать пороговое значение в течение одного периода обновления, а не накапливать доли бесконечно. Обновление не устраняет компрометацию, которая уже достигла порогового значения, и не удаляет копии учетных данных приложения или систем политик, которые мог сделать злоумышленник.
Перераспределение долей и замена участников
Протокол перераспределения долей может распределить новые доли среди нового набора участников и изменить значения t или n, сохранив при этом тот же открытый ключ группы. Это позволяет заменить утерянное устройство, произвести ротацию сотрудника или изменить структуру управления в организации без перемещения средств в цепочке. Это возможно только в том случае, если протокол поддерживает такую возможность и сотрудничает достаточный набор авторизованных участников. Продукт не может «воссоздать» утраченную долю из ничего.
Что происходит при потере одной доли?
Если остаётся хотя бы t действительных долей, группа обычно может продолжать подписывать документы. Она может создать замену посредством повторного распределения долей. Если сохранилось менее t долей и отсутствует отдельный ключ восстановления, резервная копия или путь контракта, право на подпись утрачивается. Пороговая схема повышает избыточность; она не гарантирует восстановление при любом сценарии потери.
Что происходит, когда одна доля украдена?
В идеальной модели секретного разделения «t из n» количество долей, меньшее чем t, не позволяет раскрыть секрет и не дает возможности подписать документ. С практической точки зрения похищенная доля по-прежнему представляет собой актуальный инцидент безопасности. Злоумышленник может использовать её в сеансах протокола, объединить с будущими взломами, воспользоваться ошибками реализации или получить метаданные. Правильным ответом является приостановка рискованных сеансов, проведение расследования, обновление или повторное распределение долей, ротация связанных учетных данных и проверка независимости оставшихся участников.
Каковы основные допущения по безопасности и режимы отказа?
Быстрый ответ
пороговая подпись перемещает риск, а не устраняет его. Основные классы сбоев включают компрометацию нескольких пороговых элементов, коррелированную инфраструктуру, злонамеренных участников, отказ в обслуживании, сбои в работе нонса или генерации случайных чисел, ошибки в протоколе или доказательствах, побочные каналы, некорректную интеграцию цепочки, небезопасное восстановление и уровень политики, авторизующий неверное сообщение.
| Тип сбоя | Что может произойти | Основные средства управления |
|---|---|---|
| Компрометация по принципу «пороговое количество долей» | Злоумышленник может создавать действительные подписи с использованием группового ключа. | Использование независимых устройств и операторов, обновление, принцип минимальных привилегий, мониторинг и быстрая ротация. |
| Связанный компромисс | Один облачный идентификатор, администратор, канал обновлений или библиотека охватывает несколько ресурсов. | Разделение доменов отказов, поставщиков, учетных данных, сетей и ответственности за эксплуатацию. |
| Злоумышленник | Прерывание, несогласованные представления, некорректные протокольные сообщения или атаки с использованием выбранных входных данных. | Аутентифицированные стенограммы, проверка общих ресурсов, идентифицируемое прерывание, отказоустойчивость и процедуры исключения. |
| Сбой нонса / предварительной подписи | Полное извлечение ключа или недействительные подписи после повторного использования, смещения, отката или дублирования. | CSPRNG, одноразовое состояние, хранилище с защитой от отката, привязка сеанса и контроль запасов. |
| Ошибка реализации протокола | Извлечение ключа, несмотря на безопасность протокола на бумаге. | Точная реализация в соответствии с документом, независимые аудиты, тестовые векторы, формальные методы там, где это целесообразно, и управление исправлениями. |
| Боковой канал | Утечка секрета по методу разделения или нонса через временные характеристики, кэш, энергопотребление, поведение при сбоях или ошибках. | Примитивы с постоянным временем выполнения, укрепление HSM/устройств, обнаружение неисправностей и тестирование с учетом особенностей среды. |
| Ошибка адаптера цепочки | Допустимая подпись над неверным полезным грузом, неверной цепочкой или отклоненным кодированием. | Независимый разбор транзакций, канонические кодировки, тестовые сети, опорные векторы и проверка соответствия политикам. |
| Сбой восстановления | Постоянная блокировка, восстановление секрета на небезопасном устройстве или несанкционированное использование аварийного доступа. | Документированное и отработанное восстановление, разделение кворума, запечатанные процедуры и мониторинг. |
| Нарушение политики / человеческая ошибка | Кворум подписывает мошенническую, злонамеренно одобренную или неправильно настроенную транзакцию. | Чистые доверенные дисплеи, независимая проверка, лимиты, списки разрешений, задержки и внеполосная верификация. |
Защита от прерывания отличается от защиты от кражи
Многие протоколы с нечестным большинством сохраняют секретность даже в том случае, если злонамеренный участник прерывает сессию. Это успешный криптографический результат и неудачный операционный результат. Системы казначейства должны определять, как быстро можно исключить недобросовестного участника, существуют ли альтернативные подмножества подписантов, как аннулируются просроченные сессии и как продолжается бизнес во время спора.
Координатор может не скрывать свою личность и при этом обладать значительной властью
Координатор может выбирать подписантов, собирать обязательства, выбирать сообщение, планировать сессии и публиковать окончательную подпись. Даже без доли ключа он может отслеживать метаданные, цензурировать запросы, разделять представления участников или неоднократно инициировать ресурсоемкие операции. Сообщения протокола должны проходить аутентификацию, участники должны выводить или независимо проверять транзакцию, а мониторинг должен различать обычные сбои и враждебное поведение.
Пороговое подписание по умолчанию не является постквантовым
Системы FROST, ECDSA и современные системы Шнорра основаны на допущениях о дискретном логарифме. Разделение ключа не делает лежащий в основе алгоритм подписи устойчивым к достаточно мощному квантовому компьютеру. Постквантовые пороговые подписи являются активной областью исследований и стандартизации, и при планировании миграции необходимо учитывать как верификатор цепочки, так и уровень распределенного управления ключами.
Что показали исследования Alpha-Rays, TSSHOCK и последующие работы по извлечению ключей?
Быстрый ответ
они показали, что упрощения в реализации пороговой ECDSA могут позволить злонамеренному участнику извлечь полный ключ подписи, не взламывая ни ECDSA, ни эллиптическую кривую. Отсутствие доказательств диапазона, некорректно сформированные параметры Пайлье, слабая проверка с нулевым разглашением и ошибки кодирования, специфичные для протокола, превратили доступ к пороговому значению в полный компромисс.
Alpha-Rays
В исследовании Alpha-Rays 2021 года были описаны атаки по извлечению ключей, направленные против реализаций пороговой ECDSA типов GG18 и GG20. Атаки были нацелены на подпротоколы «умножение-сложение» и такие решения реализации, как «быстрые» режимы без обязательных доказательств диапазона. Злоумышленник мог воспользоваться этим взаимодействием для восстановления полного ключа. Результат не привёл к взлому ECDSA; он продемонстрировал, что пропуск этапов проверки и подтверждения делает аргументы в пользу безопасности несостоятельными.
TSSHOCK
Исследование TSSHOCK, опубликованное в 2023 году, задокументировало дополнительные атаки на реализации пороговой ECDSA. Исследование было сосредоточено на недостатках реализации в области гомоморфного шифрования и обработки доказательств и показало несколько путей восстановления закрытого ключа. Важный урок вытекает не только из названных атак: протоколы пороговой ECDSA чувствительны к точным диапазонам, проверке параметров, формулировкам доказательств и обработке ошибок.
BitGo Zero Proof
Публично раскрытая уязвимость кошелька BitGo, обнаруженная Fireblocks, продемонстрировала ту же схему в производственной интеграции. Отсутствие проверки доказательств в двухстороннем потоке ECDSA могло позволить одной стороне извлечь долю другой стороны и восстановить ключ. Затронутый сервис был приостановлен и исправлен после раскрытия. Опять же, причиной сбоя был не примитив ECDSA, а реализация протокола и отсутствие границ проверки.
Практические исследования по извлечению ключей в 2024 году
В последующих академических и отраслевых исследованиях были проанализированы ведущие реализации кошельков на основе MPC и описаны атаки по извлечению ключей, требующие различного количества взаимодействий по подписанию — в одном случае в исследуемых условиях достаточно было всего одной подписи. Эти результаты подтверждают необходимость точной идентификации версий протоколов, включения всех этапов проверки доказательств и валидации, а также учета проверки реализации в рамках оценки криптографической безопасности.
Как следует оценивать реализацию MPC или пороговой подписи?
Быстрый ответ
начните с точного протокола, версии и модели злоумышленника, затем оцените код, генерацию случайных чисел, жизненный цикл нонсов, каналы, устойчивость к побочным каналам, цепочные адаптеры, независимость долей, обновление, восстановление и политику. Фразы «использует MPC», «прошла аудит» или «ключ никогда не существует» сами по себе не являются достаточным доказательством.
Криптографическая спецификация
- Укажите точную статью, редакцию, набор шифров и набор параметров. Убедитесь, что реализация соответствует той версии, доказательство которой цитируется.
- Задокументируйте пороговое значение, количество участников, статическую или адаптивную модель коррупции, допущение о честном или нечестном большинстве, поведение при прерывании и заявления о робастности.
- Подтвердите, как генерируются или импортируются ключи, существует ли доверенный дилер и создаётся ли когда-либо полный ключ или восстанавливаемая резервная копия.
- Укажите все вспомогательные примитивы: параметры Пайлье, «обливиозный трансфер», классовые группы, коммитменты, доказательства с нулевым разглашением, хеш-функции и генераторы случайных чисел.
Реализация и тестирование
- Обязательно проведите независимую экспертизу специалистами именно по данному семейству протоколов, а не ограничивайтесь общим аудитом смарт-контрактов или приложений.
- Протестируйте все негативные сценарии: некорректные точки, скалярные величины, доказательства, зашифрованные тексты, идентификаторы участников, наборы подписантов, дубликаты нонсов, повторно отправленные сообщения и прерванные сессии.
- Используйте примитивы с постоянным временем выполнения и устойчивые к боковым каналам, соответствующие среде устройства; защищайте журналы, дампы сбоев, файлы подкачки, телеметрию и системы наблюдаемости.
- Проводите проверку с использованием опубликованных тестовых векторов и разрабатывайте тесты на взаимодействие между различными реализациями там, где существует спецификация.
- Обеспечить функционирование процесса реагирования на уязвимости, позволяющего отстранять участников, приостанавливать подписание, обновлять доли и переводить средства без сокрытия операционных последствий.
Операционная архитектура
- Размещайте доли в действительно независимых доменах отказов: с разными учетными данными, администраторами, устройствами, сетями и, по возможности, с разными программными или аппаратными корнями.
- Защищайте состояние доподписи и нонса от отката, клонирования и восстановления из резервной копии. Рассматривайте использованное состояние как окончательно использованное.
- Проводите аутентификацию сообщений участников и предоставляйте каждому подписанту достаточно данных о транзакции для проверки экономического действия, а не только хеш без контекста.
- Проведите репетицию сценариев потери данных, компрометации, ухода сотрудников, сбоев в работе облака, отказа координатора и восстановления после аварии. План восстановления, который никогда не выполнялся, — это всего лишь предположение.
- Отслеживайте попытки подписания, выбор участников, неудачные проверки, события обновления и переопределения политик. Криптографическая конфиденциальность не должна исключать операционную подотчетность.
| Красный флаг | Почему это недостаточно или опасно |
|---|---|
| «MPC военного уровня» без названия протокола | Нет никаких технических утверждений, которые можно было бы оценить. |
| Все доли работают в рамках одного облачного тентанта | Система может выйти из строя в случае компрометации одного набора учетных данных или одного администратора. |
| При восстановлении можно воссоздать любой общий ресурс без кворума | Может существовать скрытый главный секретный ключ или центральный орган восстановления. |
| Говорят, что универсальная библиотека secp256k1 поддерживает каждую цепочку | Совместимость кривых игнорирует различия в сообщениях, кодировке и верификаторах. |
| Отчет об аудите охватывает только мобильное приложение или смарт-контракт | Протокол пороговых значений, встроенная криптография и состояние бэкэнда могут остаться непроверенными. |
| Отсутствует задокументированный механизм реагирования на кражу доли | В системе может отсутствовать обновление, повторное распределение долей или аварийная миграция. |
| Подписывающие получают только непрозрачный дайджест | Они не могут самостоятельно проверить, какое экономическое действие они санкционируют. |
Часто задаваемые вопросы
Является ли MPC тем же, что и пороговые подписи?
Нет. MPC — это обширная область вычислений над частными входными данными, хранящимися у нескольких сторон. Пороговое подписание — это одно из приложений MPC, которое генерирует цифровую подпись с использованием общего группового ключа. Другие приложения MPC включают пороговое дешифрование, пересечение частных множеств и совместное генерацию случайных чисел.
Есть ли у порогового кошелька закрытый ключ?
Он обладает полномочиями на подпись, соответствующими открытому ключу, но эти полномочия могут существовать только в виде распределенных долей. В архитектуре на основе DKG ни один участник никогда не владеет полным закрытым ключом. В архитектурах с дилером, импортом или реконструкцией полный ключ может существовать на каком-то этапе.
Может ли одна украденная доля привести к краже средств?
При правильно реализованной схеме t-из-n количество долей, меньшее чем t, не должно позволять сгенерировать подпись или раскрыть ключ. Кража одной доли всё же представляет собой инцидент: злоумышленник может объединить её с результатами последующих взломов, злоупотребить сессиями протокола или воспользоваться недостатками реализации. Обновляйте или перераспределяйте доли, когда это допускает архитектура.
Можно ли заменить утерянную долю?
Только если осталось достаточное количество авторизованных долей и протокол или архитектура восстановления поддерживают повторное распределение. Оставшиеся участники иногда могут создать новую долю, сохранив открытый ключ. Если осталось меньше, чем пороговое количество, и не существует отдельного пути восстановления, ключ восстановить невозможно.
Является ли FROST официальным интернет-стандартом?
Нет. RFC 9591 — это информационная публикация IRTF, отражающая консенсус исследовательской группы Crypto Forum. Это точная совместная спецификация, но не документ, проходящий процедуру стандартизации IETF. NIST отдельно оценивает представленные схемы с пороговым ключом в рамках процесса, официальный призыв к участию в котором был объявлен в 2026 году.
Включает ли RFC 9591 генерацию ключей?
Основная спецификация охватывает двухраундовую подпись FROST. Генерация ключей явно выходит за пределы её основной сферы применения. В приложении приведён пример с доверенным дилером, а при внедрении можно использовать отдельный протокол DKG.
Совместим ли FROST secp256k1 с Taproot в Bitcoin?
RFC включает набор шифров secp256k1, но это не означает автоматической совместимости с BIP340. Биткойн использует специфические ключи, содержащие только символы «x», тегированные хеши и правила кодирования. Для внедрения в Биткойне требуется построение пороговой схемы, специфичное для BIP340, и адаптер цепочки.
Является ли MuSig2 пороговой подписью?
MuSig2 — это схема мультиподписи, которая объединяет независимые ключи Шнорра и требует участия всех n подписантов. В BIP327 она явно описывается как «n из n», а не как общая схема пороговой подписи «t из n».
Можно ли по блокчейну определить, что использовалась MPC?
Часто — нет, если судить только по конечной подписи: она проверяется как обычная подпись под одним открытым ключом. Тип адреса, код контракта, шаблоны транзакций, метаданные сервиса или последующие раскрытия информации всё же могут выявить структуру хранения. Taproot также может скрывать некоторые политики мультиподписей и скриптов, поэтому невидимость не является уникальной особенностью MPC.
Является ли пороговая подпись более безопасной, чем мультиподпись?
Ни один из этих методов не является универсально более безопасным. Мультиподпись предлагает более простую политику, обеспечиваемую цепочкой, и независимые полные ключи; пороговая подпись может уменьшить след в цепочке, скрыть кворум и сохранить адрес за счет повторного обмена. Пороговые протоколы добавляют внецепочечную криптографическую сложность и сложность реализации. Правильный выбор зависит от цепочки, модели угроз, потребностей в восстановлении и операционных навыков.
Защищает ли пороговая подпись от мошенничества?
Она может требовать нескольких утверждений и налагать ограничения, но легитимный кворум по-прежнему может подписать вредоносную транзакцию. Участники и системы политик должны понимать точное назначение, сумму, вызов контракта, сеть и разрешения перед созданием долей.
Является ли пороговая криптография постквантовой?
Существующие пороговые схемы FROST, Schnorr и ECDSA не являются постквантовыми. Они распределяют имеющиеся полномочия по подписанию, но сохраняют допущения о безопасности базового алгоритма подписи. Постквантовые пороговые схемы требуют других примитивов и поддержки со стороны цепочки.
Вывод
Пороговая криптография решает реальную операционную проблему: один секрет подписи не должен определять судьбу крупного баланса, системы или учреждения. Решение заключается не просто в том, чтобы разделить ключ на части. Полная архитектура пороговой подписи должна определять, как генерируются доли, как защищается одноразовая случайность, как участники согласовывают одно сообщение, как отклоняются некорректные вклады, как распределяются сбои, как обновляются доли и как окончательная подпись сопоставляется с целевой цепочкой.
Самое важное уточнение к обычному маркетинговому языку заключается в том, что каждое утверждение носит условный характер. Система на основе DKG может обходиться без полного ключа на протяжении всего срока службы; система с импортированным ключом не может похвастаться такой же историей. Одиночная доля может быть криптографически недостаточной и операционно критичной. Одна подпись может выглядеть обычной в цепочке, при этом завися от обширной внецепочечной доверенной вычислительной базы. Протокол может быть доказанно безопасным, но реализован небезопасно.
При использовании с независимыми доменами отказов, прошедшим аудит кодом, строгой дисциплиной использования нонсов, правильными адаптерами цепочек, отработанными процедурами восстановления и подписантами, которые проверяют то, что они утверждают, пороговая подпись может устранить единичную точку отказа без ущерба для совместимости с обычной проверкой подписи. Используемая в качестве ярлыка без этих мер контроля, она может скрывать более сложную единичную точку отказа.
Источники и дополнительная литература
Основные источники для данной статьи, актуальные по состоянию на июль 2026 года.
- Проект NIST по многосторонней пороговой криптографии. https://csrc.nist.gov/projects/threshold-cryptography
- NIST IR 8214: Пороговые схемы для криптографических примитивов. https://csrc.nist.gov/pubs/ir/8214/final
- NIST IR 8214A: План действий по разработке критериев для пороговых схем. https://csrc.nist.gov/pubs/ir/8214/a/final
- NIST IR 8214C: Первый призыв к разработке многосторонних пороговых схем. https://nvlpubs.nist.gov/nistpubs/ir/2026/NIST.IR.8214C.pdf
- Ади Шамир, «Как поделиться секретом». https://dl.acm.org/doi/10.1145/359168.359176
- RFC 9591: Двухраундовые подписи Шнорра FROST. https://www.rfc-editor.org/info/rfc9591/
- Комло и Голдберг, FROST. https://eprint.iacr.org/2020/852
- BIP340: Подписи Шнорра для secp256k1. https://bips.dev/340/
- BIP327: MuSig2 для мультиподписей, совместимых с BIP340. https://bips.dev/327/
- BIP341: Taproot. https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki
- Дженнаро и Голдфедер, Быстрая многосторонняя ECDSA с пороговым ключом и быстрой настройкой без доверия. https://dl.acm.org/doi/10.1145/3243734.3243859
- Дженнаро и Голдфедер, «Однораундовый пороговый ECDSA с идентифицируемым прерыванием». https://eprint.iacr.org/2020/540
- Канетти и др., UC-неинтерактивный, проактивный пороговый ECDSA с идентифицируемым прерыванием. https://eprint.iacr.org/2021/060
- Донер и др., Пороговая ECDSA на основе допущений ECDSA: многосторонний случай. https://eprint.iacr.org/2019/523
Примечания к подготовке: карта внутренних ссылок
Удалите этот раздел перед публикацией.
| Местоположение анкора в данной статье | Цель ссылки |
|---|---|
| Разделы базовой информации об одном ключе | Объяснение разницы между закрытыми и открытыми ключами |
| Общие сведения о проверке подписи | Как на самом деле работает криптовалюта? Ключи, консенсус и транзакции |
| Сравнение мультиподписей в цепочке | Что такое блокчейн и как он работает? |
| Упоминания о принуждении и хранении | Криптовалютные мошенничества и угрозы: как их распознать и избежать |
| Первое использование nonce, share, DKG | Глоссарий криптовалют: 50 основных терминов |
Быстрый тест: прилипло ли оно?
Метод разделения Шамира работает только в случае паролей
Вы прошли тест по теме «Пороговая криптография и вычисления с многосторонним секретом (MPC) с учетом первоначальных принципов»! Поделитесь своим достижением в социальных сетях.
Было ли это полезно?
