Раньше я думал, что проблема мультиподписи в основном сводится к тому, чтобы собрать достаточно подписей.
Потом я посмотрел, что именно поменяла Dusk в своей реализации JubJub-Schnorr.
Один момент бросился в глаза: одноразовые значения (nonce) используются только один раз, при этом состояние мультиподписи также проверяет транскрипт и связывает вместе ключевой материал и шарды.
Похоже на обычные криптографические «хозяйственные» процедуры, пока не задумаешься о том, что на самом деле представляет nonce.
Это не просто ещё одно значение, лежащее внутри подписи.
Это часть состояния, которая делает конкретный раунд подписи валидным.
Так что мультиподпись — это не только вопрос:
«Все ли подписали?»
Это ещё и вопрос о том, принадлежат ли эти подписи одной и той же сессии подписи, с правильными ключами и правильными шардами.
Для меня это меняет формулировку задачи безопасности.
Недостаточно просто собрать корректные подписи.
Протокол должен уметь понимать, что они валидны именно вместе.
@Dusk
$DUSK #dusk
Потом я посмотрел, что именно поменяла Dusk в своей реализации JubJub-Schnorr.
Один момент бросился в глаза: одноразовые значения (nonce) используются только один раз, при этом состояние мультиподписи также проверяет транскрипт и связывает вместе ключевой материал и шарды.
Похоже на обычные криптографические «хозяйственные» процедуры, пока не задумаешься о том, что на самом деле представляет nonce.
Это не просто ещё одно значение, лежащее внутри подписи.
Это часть состояния, которая делает конкретный раунд подписи валидным.
Так что мультиподпись — это не только вопрос:
«Все ли подписали?»
Это ещё и вопрос о том, принадлежат ли эти подписи одной и той же сессии подписи, с правильными ключами и правильными шардами.
Для меня это меняет формулировку задачи безопасности.
Недостаточно просто собрать корректные подписи.
Протокол должен уметь понимать, что они валидны именно вместе.
@Dusk
$DUSK #dusk