Как вы можете заставить партию быть честной (подчиняться правилам протокола)?
Я видел некоторые механизмы, такие как обязательства, доказательства и т. Д., Но они просто не решают всей проблемы. Мне кажется, что структура дизайна протокола и такие механизмы должны выполнять свою работу. У кого-нибудь есть хорошая классификация этого.
Редактировать
При разработке защищенных протоколов, если вы заставляете сторону быть честной, дизайн будет намного проще, хотя у этого принуждения есть свои преимущества. Я видел, что при разработке безопасных протоколов дизайнеры предполагают что-то, что мне не кажется реалистичным, например, что все стороны честны в худшем случае или предполагают честность сервера, который хранит пользовательские данные. Но, глядя на дизайн протоколов в более строгих моделях, вы редко видите такие предположения (по крайней мере, я этого не видел - я в основном изучаю протоколы надUC Framework Canetti, который, я думаю, еще не полностью формализован). Мне было интересно, есть ли хорошая классификация способов, которыми вы можете заставить сторону быть честной, или есть какой-нибудь компилятор, который может преобразовать входной протокол в протокол с честными сторонами?
Теперь я собираюсь объяснить, почему я думаю, что это просто не делает работу, хотя это может показаться неуместным. При разработке протоколов в структуре UC, которая использует идеальную / реальную парадигму, каждая линия связи в идеальной модели аутентифицируется, что не соответствует действительности в реальной модели. Поэтому разработчики протоколов ищут альтернативные методы для реализации этого канала с помощью предположения PKI или CRS (Common Reference String). Но при разработке протоколов аутентификации допущение аутентифицированных каналов неверно. Предположим, что мы разрабатываем протокол аутентификации в структуре UC, есть атака, в которой злоумышленник подделывает личность стороны, но из-за допущения аутентифицированных ссылок в идеальной модели эта атака не предполагается в этой структуре! Вы можете обратиться кМоделирование инсайдерских атак на групповые протоколы обмена ключами . Вы можете заметить, что Канетти в своей оригинальной работе Универсально составляемые понятия обмена ключами и безопасных каналов упоминает предыдущее понятие безопасности, называемое SK-Security, которого достаточно просто для обеспечения безопасности протоколов аутентификации. Он каким-то образом признается (заявляя, что это вопрос технического характера), что определение UC в этом контексте является слишком ограничительным и предоставляет смягченный вариант, называемый неинформационным оракулом (который смутил меня, потому что я не видел эту модель безопасности где-либо в другом месте). Я не могу сопоставить этот шаблон безопасности с каким-либо другим шаблоном безопасности, вероятно, с моим отсутствием знаний: D).
[В качестве примечания, вы можете почти любой протокол Sk-secure преобразовать в протокол UC, независимо от времени симулятора. Например, вы можете просто удалить подписи сообщений и сделать так, чтобы симулятор имитировал все взаимодействия фиктивным способом. См. Универсальный составляемый обмен ключами в группе взносов для доказательства! Теперь предположим, что это протокол обмена групповыми ключами с полиномиальным числом сторон, какова будет эффективность симулятора? Это источник моего другого вопроса на этом форуме .]
В любом случае, из-за отсутствия приверженности в простой модели (через UC), я искал другие способы сделать протокол безопасным, просто обойдя необходимость в этом ослаблении. Эта идея настолько проста в моем сознании и пришла мне в голову, просто изучив последнюю схему обязательств canetti в простой модели: Адаптивная твердость и Composable Security в простой модели из стандартных допущений .
Кстати, я не ищу доказательства с нулевым разглашением, потому что по причине, которую я не знаю, всякий раз, когда кто-то использовал одно из них в параллельном протоколе (в рамках UC), другие упоминали протокол как неэффективный (может быть из-за перемотки симулятора).
источник
Ответы:
Увы, вы не можете заставить людей делать то, что говорится в протоколе.
Даже доброжелательные люди, которые намеревались следовать протоколу, иногда делают ошибки.
Кажется, есть как минимум 3 подхода:
Механизм проектирования В теории игр проектирование ситуации (такой как установка правил аукциона) таким образом, чтобы люди, которые эгоистично следили только за своими собственными интересами, в конечном итоге делали то, что от них хочет дизайнер, называется «дизайном механизма». , В частности, используя теорию реализации , ситуации могут быть спроектированы таким образом, чтобы конечный результат максимизировал общую выгоду для всех, избегая плохо продуманных ситуаций, таких как «трагедия общего достояния» или «дилемма заключенного», когда происходят вещи, которых нет ни у кого. долгосрочный интерес.
Некоторые из наиболее надежных таких процессов предназначены для стимулирования совместимости .
Теория игр обычно делает упрощающее предположение, что все соответствующие агенты являются «рациональными». В теории игр «рациональный» означает, что агент предпочитает некоторые результаты другим результатам, желает и может изменить свои действия так, как он ожидает (учитывая доступную ему информацию), что приведет к более предпочтительному результату (его собственному узкий личный интерес), и он достаточно умен, чтобы понять, что другие рациональные агенты будут действовать аналогичным образом, пытаясь получить наиболее предпочтительный результат из всех возможных результатов, которые могут возникнуть в результате этого выбора действий.
Дизайнер может временно сделать упрощающее предположение, что все люди действуют только в соответствии со своими собственными узкими интересами. Это предположение облегчает разработку ситуации с использованием теории реализации. Однако после того, как проект завершен, не имеет значения, действуют ли люди в соответствии со своими собственными узкими личными интересами (« Homo economus »), или они альтруистичны и хотят максимизировать общую чистую выгоду для всех - в Правильно спроектированная ситуация, оба типа людей делают одинаковый выбор, и конечный результат максимизирует общую выгоду для всех.
конвергентные протоколы
При разработке протокола маршрутизации каждый узел в сети отправляет сообщения своим соседям, передавая информацию о том, какие другие узлы доступны с этого узла.
Увы, иногда в этих сообщениях появляются ошибки. Хуже того, иногда узел неправильно настроен и выдает много вводящих в заблуждение и, возможно, даже вредоносных сообщений.
Несмотря на то, что мы, люди, знаем, что сообщение может быть неправильным, мы обычно проектируем протокол так, чтобы правильно функционирующий узел доверял каждому сообщению и сохранял информацию в своей таблице маршрутизации, а также принимал решения, как будто он полагал, что информация полностью истинна.
Как только какой-то человек отключает неисправный узел (или отключает его от сети), мы обычно разрабатываем протокол, который быстро передает полезную информацию, чтобы удалить поврежденную информацию, и таким образом быстро перейти в полезное состояние.
комбинированные подходы
Алгоритмическая конструкция механизма, кажется, пытается объединить отказоустойчивый сетевой подход и подход теории игр.
@Yoichi Хирай и Аарон, спасибо за то, что указали на некоторые интересные попытки объединить теорию игр и криптографию.
источник
У Джо Халперна есть слайд на эту тему. http://games2009.dimi.uniud.it/Halpern.pdf
Речь идет о предоставлении сторонам стимулов, чтобы они следовали протоколу. Эти механизмы требуют рациональности сторон, а аргументы основаны на теории игр.
источник