Комментарии 9
Чем это отличается от того что некоторые участники подписывают документ своей личной подписью, а проверка заключается в проверке личных подписей И кворума участников? Попытка сделать один универсальный ключ для группы участников кажется глупостью, поскольку он будет, пусть временно, но храниться в открытом виде на устройстве контролируемом третьими лицами.
Ключ никогда не хранится открыто. В смысле приватного ключа.
Зачем нужен TSS: часто хочется сберечь место и тратиться на 1 подпись, против сотен или тысяч - торговать трафик на место; рандом можно распределенный unbiased, verifiable source of randomness делать, например.
Кворум 2 из 3. Полный ключ = ABC. Первый знает AB. Второй ВС. Третий AC.Любые 2 могут собрать ключ ABC, но всё равно он где-то собирается и как правило оказывается на абсолютно левом устройстве откуда его могут украсть.
Это не так работает. Приватный ключ никто не собирает - это не нужно по протоколу: мы не собираем приватный ключ, только подпись из подписей каждого.
Если вы про атаку на протокол, когда есть malicious участники, то тогда вам надо больше участников и выше threshold. А далее - нет общих задач, для каждой задачи ищется, что будет для неё безопасным и оптимальным.
Мне, например, приходится обычно работать с количеством участников TSS 50-100. И по условиям протокола и закладывается, что честных 2/3+1. Для пойманных нечестных участников - денежное наказание. Время от времени ключи пересоздаются.
То есть как я в начале спрашивал - участники подписывают документ своей личной подписью, а проверка заключается в проверке личных подписей И кворума участников?
Что-то вы путаетесь в показаниях
можно подписывать подпись - но это не меняет схемы что участники подписывают своими личными подписями и проверка равносильна проверки личных подписей и кворума.
такая схема имеет ограничение в порядке подписания - последующий участник должен иметь модуль секретного ключа (например для RSA) больший чем у предыдущего участника.
точнее не подписывать подпись, а каждый участник применяет секретное преобразование к последней контрольной сумме, по очереди. первая контрольная сумма = хеш от сообщения.
но это имеет ограничения по порядку участников.
Я думаю, что понял, о чем вы. Вы о trusted setup, генерации подписей и ограничениях на них. Написанное выше не обязательно. Trusted setup, доверенная сторона, ограничения на порядок - это всё не нужно. https://github.com/dedis/kyber/blob/master/share/dkg/rabin/dkg_test.go - можно делать генерацию ключей и без доверенного центра, посмотрите тесты - подписывать там можно в любом порядке. По ссылке выше DKG BLS.
Добрый день
Чем это отличается от того что некоторые участники подписывают документ своей личной подписью, а проверка заключается в проверке личных подписей И кворума участников?
Концептуально - ничем.
Однако есть 2 больших эксплуатационных плюса для мира криптовалют:
1. Согласования подписи происходит оффчейн, т.е. логику кворума и проверки не нужно реализовывать на смарт-контрактах, что ускоряет процесс верификации результата.
2. Это дёшево по комиссиям, так как в цепочку пишется только одна транзакция, подписанная таким способом, а не смарт-контракт с логикой проверки кворума + транзакции от каждого из участников.
Попытка сделать один универсальный ключ для группы участников кажется глупостью, поскольку он будет, пусть временно, но храниться в открытом виде на устройстве контролируемом третьими лицами.
Это работает иначе. При операциях генерации разделённого ключа и операции создания подписи, ключ никогда не собирается целиком у какого-либо из участников. Более того, протокол создан таким образом, что участник не имеет возможности собрать его, даже если захочет. Как такого добиться? ответ на этот вопрос будет в следующих статьях)
Введение в пороговую подпись (TSS) и другие криптографические примитивы