Сначала обратимся к бонусной части: когда вы решаете такого рода проблемы, вы обычно получаете какой-то протокол, подтверждающий, что заявленный пользователь форума является частью текущего набора пользователей форума. Когда набор текущих пользователей форума изменится, вы сможете просто повторно запустить этот протокол, чтобы убедиться, что данный пользователь все еще авторизован.Это работает еще лучше, если у вас есть какой-то детерминированный псевдослучайный идентификатор для каждого пользователя форума.
Что касается фактической части доказательства, я вижу два варианта: использование доказательства с нулевым разглашением с хешем и доказательством членства в группе или использование протокола двухсторонних вычислений с PRF и предикатом членства в группе. Без части псевдонимизации это был бы стандартный случай кольцевой подписи или групповой подписи, которые доказывают, что вы можете создать подпись, действительную для одного открытого ключа из группы. В качестве альтернативы, если вы можете убедить работу форума сотрудничать, было бы использование анонимных учетных данных/слепых токенов, таких как Конфиденциальность Pass.
Сложность в этом заключается в том, что вам нужно, чтобы поставщик услуг узнал идентификатор пользователя, который не может быть произвольно (повторно) выбран пользователем, и в то же время не позволяет находчивому злоумышленнику идентифицировать точного пользователя по идентификатору. . Лучшее решение, которое я мог бы придумать для этого, - это хешировать / PRF закрытый ключ, который в любом случае не должен быть грубым, и поэтому не пропускает личность, не позволяя другим пользователям изображать из себя друг друга через И часть доказательства / протокол.
Конкретно, предполагая, что у вас есть общий протокол доказательства с нулевым разглашением, вы хотите доказать, что пользователь знает свой закрытый ключ. $х$ такой, что $H=\operatorname{Hash}(x)\land \exists i: \operatorname{is-public-key-of}(\text{pk}_i,x)$ держится где $\{\text{pk}_i\}$ - это набор открытых ключей текущего пользователя форума и моделирование хэш-функции как случайного оракула, чтобы не быть одной из тех «тупых» хэш-функций, которые пропускают ввод. Альтернативная формулировка приведенного выше утверждения, которая должна быть доказана, была бы $H=\operatorname{Hash}(x)\land (\bigvee_i \operatorname{is-public-key-of}(\text{pk}_i,x))$ чтобы подчеркнуть «ИЛИ»-природу второй части. Эта бумага похоже, это может помочь с этим подходом.
В качестве альтернативы, то же самое должно быть достижимо при других предположениях с использованием безопасных многосторонних вычислений. В частности, здесь вы должны определить функциональность, которая берет у пользователя форума закрытый ключ. $х$, от поставщика услуг статический симметричный случайный ключ $к$ а затем в качестве общедоступного ввода текущий список открытых ключей форума. Затем функциональность будет выводить немного $b$ указание на то, $\bigvee_i \operatorname{открытый-ключ}(\text{pk}_i,x)$ содержит и случайную строку $I=\operatorname{PRF}(k,x)$ как идентификатор пользователя форума. Хотя я думаю, что обе эти подоперации, как правило, имеют эффективные специализированные протоколы по отдельности, к сожалению, я этого не знаю. считать в общем, есть хороший способ «связать» входы этих протоколов вместе, чтобы пользователь не использовал разные входы для одного подпротокола. Для этого лучшим вариантом, вероятно, будет смешанный протокол 2PC, например. ПБЯ, ДВИЖЕНИЕ, или же ПЯБ 2.0 поскольку они позволяют вам выполнять проверку отношения частного и открытого ключей с помощью арифметических операций и проверку хэша / оценку PRF с помощью двоичных.
