Криптография: защита от одноранговых игр

Question

Это больше крипто / алгоритм, чем вопрос программирования, поэтому не стесняйтесь говорить мне, чтобы я пошел в другое место, если это здесь неуместно.

Мне интересно, есть ли решение для "проблемы разъединения": два пира A и B общаются друг с другом, и это должно быть оскорбительно для любого пира разорвать соединение. Можно ли доказать, что отключение было вызвано определенной стороной?

Конечно, если бы они были связаны прямой линией, тогда не было бы никакой возможности определить ответственную сторону за потерю связи. Таким образом, мы должны включить некоторую сеть окружения и определить как отключенную сторону, которая теряет соединение с каким-то третьим узлом «арбитра» в сети. Однако, если A хочет отключиться, он может выборочно заблокировать только соединение с B, поддерживая связь с арбитром.

Существует ли криптографическое решение, с помощью которого A и B постоянно обмениваются сообщениями активности, которые они также направляют арбитру, что гарантирует, что всегда можно определить, кто вызвал преднамеренное разъединение?

Answer 1

Я думаю, что по такому протоколу это невозможно.

Допустим, что у вас есть соединение

     arbiter
       /\
      /  \
     /    \
    /      \
   /        \
 peerA --- peerB

А теперь один из пиров обрезает одноранговую ссылку peerB.

Перед отключением могут возникнуть все возможные ситуации.(A отправляет данные на B, или B получает или B-> A или что-то третье.)

Поскольку больше нет ссылки A <-> B, вы не можете сказать, кто разорвал соединение.Обе стороны могут утверждать, что

a) они отправили последний пакет
b) они не получили пакет

Дело в том, что когда связь A <-> B пропала, вы неЯ могу сказать, кто его сломает, потому что это может быть даже какая-то третья сторона в середине.

Мне приходит в голову одно практическое решение: когда это происходит, вы перенаправляете весь трафик с арбитра, который теперь действует как прокси,Обе стороны тем временем отправляют трассировочный маршрут друг другу и отправляют результаты арбитру.Даже если это не удастся, и мошенник реализует поддельные ICMP-пакеты, этот метод мошенничества не будет работать, и они рано или поздно откажутся от этого мошеннического метода.В худшем случае вам придется перенаправить некоторый трафик и действовать как маршрутизатор, но вы сможете статистически отследить мошенники и предпринять соответствующие действия против них.

Answer 2

Я не эксперт, но так как здесь все немного тихо, я подумал, что укажу, с чего начать.Возможно, что то, что я пишу, бесполезно, но, по крайней мере, это заставляет меня двигаться.

Мне кажется, что обнаружение разъединения - это тот же класс проблем, что и обнаружение ошибки в целом.(предположительно, отсутствует «сигнал отключения», поэтому мы пытаемся определить, когда кто-то вытащил вилку).Я чувствую, что это попадает в тему теории кодирования шумных каналов.Я не эксперт в этом, но у меня есть хорошая книга на эту тему.

Дэвида Маккея * Теория информации, алгоритмы логического вывода и обучения.

Он доступен для бесплатного онлайн-просмотра на авторском веб-сайте (с разрешения издателя), поэтому вы можете судить, полезно ли вам это или нет, не платя никаких денег.

Для этого конкретногопроблема, вы можете захотеть посмотреть коды повторного накопления (глава 49 - вам не нужно читать 48 глав до этого).Вы посылаете повторение каждого бита сигнала, который хотите отправить, но переставляете их случайным (но фиксированным) ключом.Вы тогда к контрольным суммам на переставленном сигнале.

Итак, если центральный сервер использовал разные ключи для каждого пользователя - я бы подумал, что они могли бы определить, кто внес ошибку при отключении среднего сигнала (например, вытащив свой штекер).

Вот так я бы начал, но я не эксперт.

Том