22/06/2019
Эндрю Поэлстра работал криптографом в Bitcoin и вообще криптовалютном пространстве в течение последних шести лет. Он известен своим «нестандартным» использованием цифровых подписей в форме «скриптов без скриптов». В настоящее время занимает должность директора по исследованиям в Blockstream.
Аннотация
Подписи Шнорра, как и подписи ed25519, используемые Monero, имеют простую структуру, позволяющую множеству сторон совместно вычислять одну подпись. Эти подписи можно подтвердить обычным способом, используя общий публичный ключ, который вычисляется как комбинация ключей отдельных подписантов, и полный секретный ключ, который не известен ни одному отдельно взятому подписанту. Тем не менее, несмотря на то, что такие мультиподписи просто описать математически, они требуют применения более сложной модели безопасности, которая защитит отдельных подписантов от атак, например, направленных на похищение ключа. Кроме того, практическая реализация протоколов, подразумевающих участие множества сторон, подобных этому, требует тщательного рассмотрения с точки зрения единообразной генерации случайных чисел, возможности проведения DoS атак, атак повторного воспроизведения и многого другого. Это выступление будет посвящено работе, направленной на решение данных проблем при помощи эллиптической кривой secp256k1 (которая аналогична ed25519), а также других вопросов, связанных с генерализацией «n из n» мультиподписей и подписей с порогом «k из n».
Стенограмма:
Как уже упомянул Брендон, я собираюсь говорить о проблемах реализации пороговых подписей, проблемах, связанных с реализацией подписей Шнорра. Для начала я расскажу, что это значит, а затем по списку пройдусь по ряду проблем, с которыми мне довелось столкнуться в течение последних пары лет. Не всё так ужасно, но каждые пару месяцев здесь всплывает какая-нибудь неожиданная странность.
Для начала позвольте объяснить, о чём я буду говорить, начнём. Позвольте объяснить, что такое подпись Шнорра. Итак, подпись Шнорра — это алгоритм цифровой подписи. Алгоритмы цифровых подписей в некотором роде лежат в основе криптовалют всех форм и размеров. Bitcoin использует алгоритм под названием ECDSA. Есть предложение заменить ECDSA или добавить в Bitcoin подписи Шнорра как часть протокола под названием Taproot. Но многие другие криптовалюты, такие как Monero, уже давно пользуются подписями Шнорра. В силу использования библиотеки и кривой ed25519 Monero применяла подписи Шнорра, когда ещё была ByteСoin. Вместе с тем мне, пожалуй, следует оговориться, что подписи в стиле Monero, по сути, являются частью гораздо большей схемы (RingCT), о которой говорил Аравинд несколько подробнее.
Мой следующий слайд демонстрирует, насколько просты подписи Шнорра. И я должен подтвердить это словами: «Если вы взглянете на реализацию RingCT, то увидите, как она проста, вы увидите уравнения, в которых при удалении целой группы членов вы, по сути, останетесь всего-то вот с этим». На практике иногда всё несколько сложнее, поскольку всё входит в более широкий контекст, но, по сути, подпись Шнорра — это вот эти три формулы, которые показаны здесь, или же это просто инструкции для подписания, для создания подписи. Вы берёте вот это, называемое «нонсом», это совершенно случайная вещь. Я обозначу его k. Вы берёте хеш e. Этот хеш является хешем вашей транзакции, это хеш вашего публичного ключа, это хеш вашего публичного нонса, который выводится из k. Это всё, что вам известно на момент подписания, вы всё вкладываете в этот хеш e, затем вы решаете это простое уравнение. Вы берёте ваш секретный нонс, вы берёте ваш секретный ключ x, умноженный на этот хеш, и вы складываете их. Или вы читаете, в общем, делаете с ними всё, что захотите. И всё что у вас остаётся — вот это небольшое линейное уравнение.
Оно само по себе просто, и что действительно здорово, так это то, что это линейное уравнение — и вот причина того, что я довольно небрежен в отношении плюсов и минусов, то есть, если у вас есть множество подписантов, пытающихся создать подпись, или же вместе создать, скажем, доказательство RingCT, то всё делается предельно просто. Вот пример транзакции от одного до множества подписантов. Всё, что мне нужно, добавить несколько коэффициентов. В случае с множеством подписантов каждый независимо выбирает свой нонс, ki. Они комбинируют то, что у них имеется, они вычисляют этот хеш из того, что известно каждому, и каждый из них независимо создаёт подпись, как показано здесь внизу, а затем они объединяют эти подписи. Таким образом, добавляется этап комбинирования.
Процесс создания подписей Шнорра предполагает наличие двух этапов. После каждого из них добавляется комбинированный этап, и в этом и состоит переход от одиночных подписей к мультиподписям. Так что всё великолепно, и это распространяется на более сложные вещи, такие как Bulletproofs и, следовательно, доказательства Bulletproof или RingCT, или Omniring, или какие-либо другие доказательства, которые вы захотите использовать в Monero, — эта простота переносится. И это очень соблазнительно для разработчиков протокола. Также, если вас волнует доказуемость безопасности, что, вероятно, должно вас волновать, доказуемость безопасности подписей Шнорра немного лучше, чем у ECDSA, и я не собираюсь сильно углубляться в этот вопрос.
Позвольте мне начать с пары вопросов, с одиночных подписей Шнорра, а затем перейти к мультиподписям. После этого, если у меня останется время, я расскажу о пороговых подписях, и мы сможем увидеть, как проблемы наслаиваются на практике.
И первая наша проблема вытекает из этой первой строки. Я воспользуюсь указателем, а может, и нет, ведь при потоковой трансляции указатель видно не будет? Не знаю. Знак доллара вот здесь — это такая хитрость, элемент случайности. Это используется в академической криптографии. Идея состоит в том, что вы подбрасываете монету, чтобы получить случайный бит — ноль или единицу. Знак доллара — это сотня монет. Вам необходимы 100 бит, 256 бит, любое другое число. Сотня битов или долларов, так что вы подбрасываете доллар достоинством в пенни. В данном случае мы получаем равномерно распределяемое случайное число. На практике сложно добиться равномерно распределяемой случайности. В частности, если у вас есть что-то вроде аппаратного токена или чего-то подобного с ограниченным доступом к энтропии, или того, у чего нет доступа к накопителю или оно имеет ограничения по скорости и производительности CPU, вообщем, что угодно. И в данном случае вопрос состоит в том, что необходимая вам случайность совершенно необязательно должна быть равномерно распределяемой. Если вы используете смещение на один бит или даже менее, чем на один бит. Возможно, высший бит каждой четверти вашей подписи имеет нулевое значение, это случается чуть чаще, чем требуется, в принципе, а фактически на практике, этого оказывается достаточно, чтобы заполучить ваши секретные ключи, при условии наличия достаточного количества подписей.
В пространстве Bitcoin была опубликована статья, написанная Надей Хенингер и Иохамимом Брейтнером пару месяцев назад, в которой рассматривалась теоретическая возможность проведения такой атаки с выделением группы секретных ключей из старых транзакций Bitcoin, при создании которых производились смещённые нонсы. Рекомендую вам ознакомиться с этой статьёй. Также имеются некоторые интересные суждения относительно того, как это могло произойти. Но в целом имелось несколько старых механизмов подписания или кодовых баз, которые смещали свои нонсы на несколько битов или же на множество битов. По сути, они не использовали повторно свои нонсы и не делали чего-то ужасного, что было бы за гранью, они просто смещали нонсы при наличии достаточного количества подписей. Этого было достаточно, чтобы удалить ключи.
Если бы вы даже могли как-то решить эту проблему получения несмещённых случайных значений, если бы это получилось в случае с аппаратными токенами или чем-то подобным, в идеале вам бы захотелось проверить, обеспечивает ли аппаратный токен несмещённые случайные значения. Поэтому я немного порассуждаю на эту тему. Есть схема под названием RFC6979. Она очень проста. Ну, в принципе она проста, а на практике она требует значительного объёма хеширования и дополнительного времени CPU. В данном случае берётся секретный ключ, берётся сообщение, всё это забрасывается в псевдослучайную функцию, и вы получаете результат. Благодаря псевдослучайной функции вы можете допустить, что результат будет иметь случайное равномерно распределённое значение. Это криптографический допуск, но он лучше, чем допуск того, что считывание битов с не подсоединённого диода или чего-то другого будет не смещённым.
Это важно, всмысле, возможность верификации. Вместо прохождения детерминированного алгоритма, начиная с некоторых секретов и некоторых методов, и прочих вещей, на практике почти всё невозможно верифицировать. Если бы у вас имелся аппаратный кошелёк, который создавал случайные значения таким вот образом, и вам как пользователю хотелось гарантировать, что ваш аппаратный кошелёк всегда всё делал бы именно так, а не случайным образом или специально смещал бы что-то, что могло происходить совершенно незаметно для вас, то ваш кошелёк должен был бы как-то создавать доказательство с нулевым разглашением конфиденциальной информации, то есть проходить этот алгоритм. Так что это отстой, это слишком сложно, и для этого не было написано никакого кода. Пока не ясно, могут ли существующие аппаратные токены справиться с этим. Итак, хорошо, RFC6979 — это окончательное решение, тем не менее не допускающее верификации.
Но есть способ обеспечить возможность верификации. Для этого необходимо использовать эту технологию под названием «подписание по контракту». Что делает эта технология: по сути, она берёт уравнение в последней точке. Далее, я повторю некоторые предшествующие уравнения, но попытаюсь всё объяснить доступным языком. По сути, вы являетесь хостом, пользователем своего аппаратного кошелька, вы привносите некоторую произвольность, вы даёте кошельку возможность случайного выбора, а уже аппаратный кошелёк обеспечивает случайный характер нонса. Это здорово, это означает, что если вы способны обеспечить случайность с равномерным распределением или же аппаратный токен может осуществлять случайный выбор с равномерным распределением, то и результат будет распределён равномерно. В частности, если аппаратный кошелёк как-то пытается подкопаться под вас, то вы подкапываетесь под его подкоп. И это невероятно, если не считать, что здесь мы сталкиваемся с первой из множества трудностей, пытаясь реализовать отличные простые идеи. Таким образом, если вы без каких-либо изысков просто попытаетесь использовать RFC6979, аппаратные кошельки будут проходить через этот детерминированный процесс, а затем вы добавите фактор случайности и сможете заполучить секретные ключи из аппаратного кошелька. По крайней мере если вы сможете реализовать это.
В народе в отношении подписей ходит следующий мем: «никогда не используйте нонсы дважды». Но, по сути, вы никогда не сможете повторно использовать связанные нонсы. Таким образом, если ваш аппаратный кошелёк выдаёт один и тот же нонс, а затем смещает его значение с указанной хостом произвольностью, и смещение происходит с указанной другим хостом произвольностью, в различное время, то это будут связанные нонсы. Разница между ними будет разницей между модификациями. Так что выходит, что мем следует усилить: «никогда не используйте нонсы дважды — никогда не используйте дважды связанные нонсы». И что важно, вы можете повторно использовать свои нонсы, когда будете подписывать одно и то же сообщение, поскольку вы будете создавать одну и ту же подпись снова и снова. Выходит, что если вы используете связанные нонсы, даже если у вас одно и то же сообщение, то вы всё равно выдаёте свой ключ. Именно это и происходит в данном случае.
Что необходимо, чтобы реализовать это на практике, так это чтобы аппаратный кошелёк выдавал предварительное обязательство. И как всё будет происходить теперь?
Самым наивным способом сделать или исправить это было бы сделать так, чтобы аппаратный кошелёк вначале задавал произвольную случайность, с которой аппаратный кошелёк смешивал нонс, а аппаратный кошелёк при использовании RFC6979 смешивал бы его с секретным ключом и сообщением. И подобным образом он всегда будет использовать различный базовый нонс для различных поправок. Проблема состоит в том, что аппаратный кошелёк по-прежнему сохраняет способность к смещению путём постоянной прокрутки в попытке найти возможность до тех пор, пока не удастся добиться смещения.
В данном случае необходимо отправить аппаратному кошельку предварительное обязательство в отношении поправки, которую вы хотите, чтобы он добавил. Аппаратный кошелёк включит предварительное обязательство в поправку, в нонс, который он собирается использовать, он выдаст вам нонс, который собирается использовать, а затем вы зададите фактическую произвольность, и он использует её. Если вы всё сделает именно в этом порядке в три, в четыре этапа, то это будет замечательно. Таким образом, тут мы должны извлечь следующий урок — не будьте наивными. А промежуточный урок можно бы было выразить как «Уххххх!»
Как выяснилось, и легло в основу образца — я написал API, чтобы провернуть это «подписание по контракту». Я подумал: «Это здорово, я убираю нонс по стороннему каналу, это изумительно». Мой коллега, Джонас Ник, посмотрел и сказал: «Используя это, я смогу извлечь ключи». Я ответил: «Уххх, всякий раз, когда я пишу API, используя его, ты можешь извлечь ключи». И это пугает, поскольку интуитивно я беру публичный нонс, и я делаю публичную поправку. Вся связь между аппаратным кошельком и хостом в данном случае совершенно публична. Это застало меня врасплох, и затем я получил опыт, которым делюсь с сейчас вами в процессе этого выступления, и всё хорошо. Не будьте наивными.
Продолжаем. Давайте поговорим о мультиподписях. Мы можем рассматривать тот нонс в качестве предшественника мультиподписей. Мы движемся от одного объекта, создающего подпись, к аппаратному кошельку и хосту, совместно создающим подпись. И вот тут всё немного начинает выбиваться из колеи. Интуитивно мы любим мультиподписи Шнорра именно за то, что было показано мною в первом слайде. Вот это уравнение, которое я скопировал из первого слайда, только в нём изменён минус на плюс, все выбирают случайный нонс. На первом этапе все складывают свои нонсы вместе и хешируют результат. На втором этапе все создают подписи и складывают их вместе. Отлично, у нас получилась мультиподпись. И не нужно ничего лишнего: никаких новых безумных протоколов, никакой дополнительной криптографии, множества этапов, никаких повторений, никаких дополнительных сеансов связи.
Всё несколько тоньше, чем я пытаюсь представить. Интуитивно можно буквально сложить все различные нонсы вместе и сложить все подписи, и получить одну подпись для суммы всех ключей. Это опасно, поскольку если начинать просто с группы публичных ключей различных подписантов и складывать их вместе, чтобы получить общий публичный ключ, а так, по сути, и работает схема, то один пользователь, тот который последним добавит свой ключ, просто сможет вычесть, подумайте о ключе, вычесть чужие ключи и сказать: «О, вот мой ключ, поверьте». А затем вы сложите их все вместе, и все остальные ключи будут взаимно исключены. Итак, теперь у них есть общий ключ, который полностью контролируется одним пользователем. Это называется атакой с кражей ключа.
Чтобы избежать этого, необходимо повторно обеспечить случайность ключей таким образом, чтобы если кто-то попытается создать свой ключ, суммируя ключи других пользователей, то эта повторная рандомизация не позволила бы сделать этого. Изначально у нас был необходимый способ: вы брали свой ключ, вы хешировали свой ключ и смешивали его со своим секретным ключом. Оказалось, что всё это разбивается алгоритмом Вагнера. Ухххх! Что позволяет сделать алгоритм Вагнера злоумышленнику, проводящему атаку, при наличии целой группы случайных чисел. Если вы можете только снова и снова генерировать случайные числа, то вы обнаружите, что целая группа этих чисел добавляется к нулю. Таким образом, вы получите целую группу 256-битных хешей и целый ряд из них, не очень большой, около 500, возможно. И если у вас не так много работы, в районе от 2 до 60 или где-то так, вы найдёте ту группу, где они прибавляются к нулю или же к 1, или же прибавляются к чему вам угодно. Это можно отследить. От двух до 60 отслеживаются. От двух до 128 не отслеживаются из-за конфликтов, от 2 до 256 не отслеживаются по другим причинам, но эти отслеживаются.
Это означает, что если вы позволите злоумышленнику просто выбирать ключи, и каждый ключ будет иметь собственное случайное распределение, то появится возможность выбрать ключи таким образом, что когда вы будете добавлять все свои случайные ключи, то они всё равно будут складываться к его оригинальному ключу. Очень печально. Таким образом, появляется необходимость в смешивании случайных значений каждого ключа с каждым последующим ключом. На практике вы хешируете весь список ключей, а затем для каждого ключа хешируете этот список наряду с отдельным ключом, и так происходит рандомизация.
Также выходит так, что здесь добавляется дополнительный этап. Я говорю о том, что добавляются нонсы и добавляются подписи. Получается так, что каждый должен добавить предварительные обязательства к своим нонсам до того, как раскрыть свои нонсы, до того как их можно будет добавить. И причина тут снова в том, что вы можете использовать алгоритм Вагнера с хешами сообщения, в противном случае злоумышленники могли бы выбрать свои нонсы таким образом, что они бы получили из этого свободную подпись. Можно было бы запустить целую группу параллельных сессий подписания с теми, кого хотели бы атаковать. Как и в случае с 511 сессиями подписания, они могут получить 512 подпись. Создавай 511 с использованием тщательно выбранных нонсов и алгоритма Вагнера, чтобы получить свои существующие подписи, чтобы добавить ещё одну.
Необходимо сделать предварительное обязательство, а это всё портит. Вам необходимо использовать фактор случайности от каждого ключа к ключу. Вот к чему мы приходим, и полученная нами схема называется MuSig, и у неё интересная история. Изначально мы опубликовали MuSig с доказательством безопасности, и эта версия прошла независимый анализ без этапа предварительного обязательства. Она очень серьёзно анализировалась, не только в прессе, но и всеми членами нашей команды, принимавшими участие в написании, а также другими командами, конкурирующими с нами. Только одной команде удалось обнаружить, что наше доказательство не может быть действительным. Странное «мета-доказательство» и на тот момент оно было похоже на что-то вроде — «хм, может быть, нам стоит к этому присмотреться внимательней», и да, они решили взглянуть на схему повнимательнее, и тут уже они смогли найти фактическую ошибку в нашем доказательстве. И позднее они таки нашли возможность проведения реальной атаки, используя алгоритм Вагнера.
Результатом стала вот эта работа, опубликованная ими в итоге, и, к счастью, во время развития этой драмы наша статья проходила через обычные циклы анализа перед публикацией. Так что у нас было время, чтобы всё исправить, и в окончательной опубликованной версии, версии, которая была фактически опубликована, этой ошибки уже не было. Но это был звоночек, который нас насторожил, так как мы пропустили такое слабое место. А ошибка в доказательстве действительно была неуловима. Это было длинное и сложное доказательство, и оно было уязвимо. Но сейчас мы имеем то, что называем MuSig.
Продолжим. Давайте поговорим о реализации Musig, как нам удалось получить безопасную схему. Дело в том, что когда вы смешиваете RFC6979 и мультиподписи, вы по-прежнему можете выделить ключи. И проблема в данном случае состоит в том, что в отличие от схемы с аппаратным кошельком в роли хоста. Если вы всё делаете в правильном порядке, чтобы кошелёк выбирал всё случайным образом, то он гарантированно будет использовать иной случайный нонс, неважно какие вводные вы зададите. Только все должны дать предварительные обязательства, которые будут вами включены. В случае с мультиподписями это невозможно. Кто-то должен быть первым при публикации нонсов или при выборе нонсов. И этому человеку будут неизвестны другие нонсы, и это будет включено в хеш сообщения. Не играет никакой роли, сколько раундов с предварительными обязательствами вы добавите. Не имеет значения, в каком порядке всё будет сделано. По сути, хорошо, если вы детерминировано генерируете свои нонсы, тогда кто-то сможет первым запустить схему или создать мультиподпись вместе с вами, выбрать некоторый нонс, а затем создать другую мультиподпись с вами с тем же сообщением, тем же ключом и всем остальным. Но в этот раз выбирается другой нонс, и двух схем вместе, или же полученных подписей будет достаточно, чтобы выделить ваш ключ. Таким образом, вы не можете использовать детерминированные нонсы. Если только, возможно, и я не буду углубляться в это, если все не станут использовать детерминированные нонсы, и если каждый не представит доказательство с нулевым разглашением конфиденциальной информации, что так и было сделано, в этом случае никто не сможет поправить собственный вклад, и тут всё серьёзно усложняется.
Лучше не создавать детерминированные нонсы. Ну, действительно ли это лучше? На самом деле нет, поскольку если вы хотите, чтобы ваш аппаратный кошелёк генерировал случайные нонсы, не используя какой-либо детерминированной схемы, то вы вернётесь ко всем старым проблемам, связанным с невозможностью верификации. Даже если вы сможете выделить секретные ключи и вскрыть подписи, то вам будет не на что взглянуть, вы не сможете определить, какими должны быть нонсы. Стоит беспокоиться о смещении нонсов. Равно как и о сбое аппаратного обеспечения, его перегреве и о других естественных вещах, которые могут стать причиной сбоя. Также стоит беспокоиться о возможности проведения атак с повторным воспроизведением. Это можно сделать, если у аппаратного кошелька есть счётчик и он включает его значение в хеш и выполняет фукцию «6979», затем, посто прибавляет значение счётчика. Следует беспокоиться о том, что кто-то каким-то образом сможет «отмотать» счётчик или вызвать сбой вашего аппаратного обеспечения, сделать повторное воспроизведение или что-то в этом роде. По сути, вам необходим либо RNG, либо какое-то состояние, которое нельзя будет воспроизвести, и оба эти варианта сложно реализовать в случае с аппаратными кошельками.
Нам нужен свежий фактор случайности, не RFC6979. Это всё, что я хотел сказать об этом. И нам также необходимо всё делать правильно с MuSig. Каждому необходимо выдавать предварительное обязательство по своему нонсу, и тут мы имеем три раунда: предварительное обязательство по нонсу, раскрытие нонса, раскрытие подписи. И если вы сделаете это, то я скажу: «Ну, это отстой, ведь у меня уже есть протокол, подразумевающий наличие трёх раундов в системе, разрабатываемой мною, и я ничего не знаю о сообщении до последнего момента, но я по крайней мере позволяю всем совместно использовать нонсы наряду с тем, что они вкладывают в сообщение. Таким образом, я могу делать что-то параллельно, и если всё пойдёт не так, то я смогу начать с начала и сделать ещё одну попытку параллельно с прошлой или что-то подобное».
Мне хотелось, чтобы мои подписанты добавляли предварительные обязательства к своим нонсам до того, как им станет известно сообщение. И это казалось очень простым — мы немного изменяли их API, чтобы всё получилось. А два дня назад выяснилось, что после двух лет итераций, два дня назад Джонас прислал мне сообщение: «Я нашёл способ атаки при помощи алгоритма Вагнера. Необходимо знать сообщение до того, как будет выбран нонс». Просто отлично.
Меня расстроило, что беда пришла из ниоткуда. Но тут есть и урок. Аравинд говорил о пользе доказуемой безопасности. Когда я попытался изменить порядок совместного использования нонсов выбором сообщений, я, по сути, нарушил протокол, описанный в работе. А, следовательно, доказательство безопасности, о котором говорилось в ней, было более не применимо. И в этом случае действительно открывалась возможность для проведения атаки. И урок тут состоит в том, что не следует нарушать порядок, указанный в документах. Если вы реализуете другой протокол, который не описан в документации, то вы реализуете именно другой протокол, и доказательство безопасности в этом случае не работает. И я был слишком самоуверен и обжёгся. Ничего хорошего.
Давайте перейдём к пороговым подписям. Я быстро обрисую вопрос, но, на самом деле, тут особо много и не расскажешь. Первое, что мне хотелось бы отметить, всё, что я уже рассказал про мультиподписи — для начала я хотел бы отделить пороговые подписи от мультиподписей, поскольку мы несколько неаккуратны в данном случае с разграничением, когда речь идёт о мультиподписях, целая группа людей создаёт подпись, они создают одну подпись. И в академическом пространстве, по сути, вашим верификаторам известен весь список ваших ключей, и им известны изначальные участники, и им необходимо верифицировать только одну подпись. В случае с пороговой подписью вам не нужны все, возможно, у вас есть десять участников, и вам необходимо, чтобы только восемь из них создали подпись. Это и называется пороговой подписью.
Пороговые подписи Шнорра очень просты из-за линейной структуры наших уравнений. У всех есть свои настройки ключей, и все секретно совместно используют ключи, все делятся своими частями, и им для этого необходимы приватные каналы передачи данных, но это немного сложно. Затем все заменяют свои индивидуальные ключи суммами своих частей и частей остальных. А затем, во время подписания, восемь человек объединяются и они могут реализовать только алгоритм мультиподписи. Все они выбирают нонсы, вы складываете их, они берут свои ключи и взвешивают их, используя множители Лагранжа, которые меняются в зависимости от того, какой ряд из восьми участников у вас имеется. Они создают подписи, вы складываете подписи, и всё великолепно. Предельно просто.
С придумыванием нонсов гораздо больше вопросов. Первый заключается в выборе нового нонса при каждой попытки создания подписи. Дело в том, что даже если вы подписываетесь тем же самым ключом, тем же самым рядом подписантов и, используя то же самое сообщение, и всё то же самое, вы получаете доказательство с нулевым разглашением конфиденциальной информации и все эти положительные вещи. Если вы подпишетесь, воспользовавшись другим рядом подписантов, полученный комбинированный нонс может быть иным. В этом случае ключ также может быть извлечён. Опять же, необходимо очень тщательно выбирать нонсы. А это означает невозможность верификации и большие затруднения.
А другой проблемой пороговых подписей является то, что в принципе суть пороговых подписей заключается в том, что вы защищены от того, что некоторые стороны будут недоступны на момент подписания. Но на практике, как правило, все стороны будут доступны. И в идеале вы могли бы сказать: «Хорошо, если нужно всего восемь участников, чтобы сделать подпись при том, что десять человек составляют ключ, в идеале все десять могут поучаствовать, и если двое из них почему-то будут бездействовать, то мы просто сможем не брать их в расчёт». И это здорово. Смысл пороговых подписей не только в том, чтобы подстраховаться на случай отсутствия людей, но и в предупреждении действий злоумышленников. Необходимо сильно постараться, чтобы сделать их.
Прежде всего, очень сложно будет всё восстановить. По сути, будет необходимо выяснить, кто не принимает участие, отбросить этих людей, а затем перезапустить протокол. Выяснить, кто бездействует, довольно сложно. Необходимо прибегнуть к так называемому совместному использованию публично верифицируемого секрета. Я думал, что создам более продуманную схему, чтобы упростить использование подписей и всего прочего. Но оказалось, что это не работает, если злоумышленник принимает участие в создании первой половины подписи, а затем исчезает. Причина состоит в том, что если вы добавляете требования, чтобы каждый всё делал, как положено, а люди не делают этого, то это трудно обнаружить и предоставить свидетельство. Таким образом, есть целый ряд технических сложностей, но я собираюсь разобраться с ними.
А теперь ещё одна заключительная минорная нота. Я говорил о том, насколько важна доказуемая безопасность, и как я обжигался всякий раз, когда пытался уйти от этого. Дело, в случае с пороговыми подписями, заключается в том, что есть эта работа, в которой говорится, что вы не можете использовать их. То есть вы не получаете доказуемой безопасности, если не используете всей этой дополнительной механики. И вы не можете получить доказуемой безопасности, поскольку ключи не являются случайными. И я подумал: «А вообще, имеет ли значение, если ваши секретные ключи не будут случайными? То есть если нонсы не будут случайными, а секретные ключи будут постоянными. Так что, может, всё будет нормально, если они будут смещёнными?». А затем я прочитал статью и понял, что она вовсе не о секретных ключах, а о публичных. И очевидно, это не имеет значения, но мы часто обжигались, заявляя, что что-то «не имеет значения». Так что, возможно, мне придётся поработать над всем этим.
Я хочу сказать, что в статье говорится, что нужно делать, но всё это очень сложно, и есть много над чем поразмыслить. Это всё, что я хотел сказать. Спасибо за внимание.
Перевод: Mr. Pickles
Редактирование: Agent LvM
Коррекция: Kukima