Давно уже в умах существует идея сделать систему передачи сообщений децентрализованной. В целом технология для этого существует, это DHT/Kad сеть. Основная их функция - поиск необходимого ресурса по хешу (в данном случае ресурс - имя пользователя). Но в таких сетях нет такой штуки, как авторизация, да и сложно ее придумать, когда нет центра подтверждающего подлинность. Т.е. если вы уже общаетесь с кем-то, то вместо него вряд ли кто-то влезет (потому что все шифруется ассиметричным ключом и злоумышленник не сможет декодировать ваши сообщения). Но остается проблема существования двойников. Т.е. два человека одновременно ввели одно и то же имя для регистрации из которого получается хеш. Система обошла всю сеть и не нашла такого имени (или нашла, но злоумышленник просто отсылает ваш хеш в качестве своего). В результате возникает ситуация, когда ноды имеют различные пары хеш-ip, т.е. человек, который захочет соединится именно с вами, может попасть на двойника. Причем нет разницы если вы используете нормальное имя или последовательную нумерацию новых клиентов (как это сделано у cspace.in). Система такого типа уже есть, это cspace.in, не знаю детально как она функционирует, но их клиент еще очень сырой продукт, например нет возможности подключить уже существующий аккаунт. Я пока не уверен, что такая штука реально необходима, я знаю про icq, msn и даже jabber, можно об этом не говорить. Интересует именно решение однозначной авторизации в системе без центрального сервера. Первая мысль, которая приходит в голову, использовать при "пингах" и поиске свой открытый ключ, потом тот кого пингует отсылает какое-либо шифрованное сообщение, которое пинговальщик должен вернуть расшифрованным, тем самым подтвердив, что у него имеется закрытый ключ. Но при таком раскладе объем передачи увеличивается на треть (что очень плохо, т.к. на этих пингах вообще держится вся сеть). При этом совершенно не гарантирована ситуация, что часть нодов будет иметь совсем другой открытый ключ сопоставленный с тем же самым хешем. Так как каждый клиент не может хранить все ноды сети, значит ситуация с двумя одинаковыми хешами при разных открытых ключах возможна. Плюс возникает вторая проблема: человек, который потерял свой приватный ключ, уже никак не сможет восстановить свое участие в сети под старым именем, т.к. остальные ноды не будут принимать его новый открытый ключ, т.к. уже сохранили у себя старый. Вот такая разминка для ума. Хотелось бы узнать, кто что думает.
Можно использовать распределенные сети только для поиска людей, а обмен сообщениями уже вести по TCP(ну или используя третьего участника с белым IP, если оба компа за NAT) Насчет потери ключа... можно придумать алгоритм генерации пары ключей из ника и пароля. можно проводить идентификацию участников по уникальному номеру а-ля GUID, а вот уже аутентификацию - по ключам. т.е. клиент отображает предупреждение, если участник с уникальным номером N не прошел аутентификацию. В этом случае юзер может принять новый ключ, если он верит, что человек действительно потерял старый. Можно хранить приватные ключи в распределенной сети, защищенные паролем. тогда при потере ключа юзер может затребовать его из сети и расшифровать своим паролем
понятно, что dht нужен только для поиска. аутентификация не сложный процесс, создать ключ можно рассчитать как md5 хеш от ника. но это не поможет, если злоумышленник захочет сделать двойника. да, пользователи, которые уже связались с этим ником и обменялись с ним открытыми ключами будут и дальше общаться с ним, а те кто захочет подключится первый раз могут попасть на любого из двух. GUID использовать не обязательно, есть возможность выдавать при первом подключении клиента (регистрации) новый номер последовательно. т.е. найти максимально известный в системе ID и создать новый ID+1. Но все это не убережет от злоумышленника, который станет использовать ваш ID. Т.е. с вашими знакомыми он поговорить не сможет (точнее отправлять сообщения он может, но прочитать ответ не получится), а вот с людьми, с которыми данный ID не контактировал можно совершить обман. В принципе это видно на примере "одноклассников", есть множество одинаковых имен, и вы не знаете какой из "Путиных" настоящий. Хранить приватные ключи , как мне кажется, можно только у клиента, иначе система сразу же становится уязвимой. В целом, потеря приватного ключа не такая уж большая опасность, человек просто может зарегистрировать новый ник или ID (смотря как работает система). Если устроить чуть иначе, то может вообще не нужен будет приватный ключ для работы в сети (только для обмена текстовыми сообщениями). Главная проблема в том, что новый ник не может быть однозначно идентифицирован с конкретным человеком, т.к. центрального сервера, который бы заверял, что это именно тот самый клиент не существует. Получается вариант с кучей "Путиных" легко возможен. Который будет к вам ближе по XOR-пути, того вы и найдете. "т.е. клиент отображает предупреждение, если участник с уникальным номером N не прошел аутентификацию". Вот это не понял.
@существует идея сделать систему передачи сообщений децентрализованной@ calidus, у меня только мысли вслух : ) но можно посмотреть уже готовый cspace (www.cspace.in) - только клиент сам по себе ужасный
Я спрашиваю потому что у меня есть тут достаточно новенькая вещь , её хотели заменить полностью протокол ИП , чтобы сделать весь инет децентрализованным. Но там есть много оч классных идей. Я хотел начать поект , цель , для начала червечка под вм погонять , посмотреть как он будет эту сеть создавать , вообщем есть еще пару идей. На чем писать будешь ?
calidus, писать я ничего не планировал в обозримом будущем. как минимум нужно понимание системы в целом, а у меня нет идеи решения проблемы двойников (случайных или специальных). насколько я понимаю "червячки" и im вещи очень даже разные ; )
ну это да , речь идет о протоколе который будет поддерживатся что там что там. Для того чтобы решить проблему двойников нужно разрабатывать протокол с такими особенностями. Я когда сделаю , то покажу , как работает.
Хорошая задача уровня бакалаврской. Все идеи отлаживаются на модели, основанной на графах и алогритмов маршрутизации в графах, например, есть алогритмы пограничной маршрутизации. Авторизацию без единого сервера можно проводить так: при регистрации открытый ключ клиента подписывается пограничными узлами графа, для экономии числа подписей, хранящихся у одного узла, можно предусмотреть функцию гарант-узлов, ввести алгоритм поиска одного из гарант-узлов с помощью пограничных узлов графа. Гарант узлы обмениваются подписями клиентов и хранят их с избыточностью, необходимой для надежности.
Удивительно, какие одинаковые мысли приходят в голову людям. Я совсем недавно обдумывал идею подобной сети, даже на бумаге кое-что изложил. http://dpaste.com/5376/ ещё дополнения - в качестве опоры для децентрализованной сети, можно использовать уже существующую децентрализованную архитектуру jabber'а. разработать несколько транспортов к jabber-серверам для репликации каталога, кэширования подписей и подсчета кармы не такая проблема.
NETSUKUKU — это ячеистая сеть, или p2p сеть, построенная на протоколе динамической маршрутизации Npv7_HT. В настоящее время существует достаточно много протоколов и алгоритмов для динамического управления, но они все отличаются от Npv7_HT, поскольку используются строго для создания маленьких сетей. Управление Интернетом также осуществляется различными протоколами, такими как OSPF, RIP или BGP, в основе которых лежат классические алгоритмы, способные находить наилучший путь для достижения узла в сети. Данные протоколы требуют больших ресурсов процессора и памяти. По этой причине для подобных целей предназначены специальные компьютеры. Ни один из этих протоколов не сможет создать и поддерживать такую сеть, как NETSUKUKU, в которой каждый узел управляется самостоятельно, потому что маршрутная карта всех путей, хранящаяся на каждом компьютере в сети, требовала бы около 10 Гбайт пространства. Структура Npv7 — сеть как фрактал. Для расчёта всех необходимых путей связи узла со всеми остальными узлами протокол использует особый алгоритм, называемый Quantum Shortest Path Netsukuku (QSPN). Фрактал — это математическая структура с дробной размерностью, которая обладает свойством рекурсивности: каждая её часть является уменьшенной копией целого. Поэтому возможно большое сжатие структуры, которая может безгранично расширяться. А это значит, что нужно всего лишь несколько килобайт для хранения всей карты маршрутов NETSUKUKU. Структура маршрутной карты NETSUKUKU может быть также определена как высококластеризованный граф узлов. С другой стороны, QSPN представляет собой метаалгоритм в том смысле, что не следует никаким математическим правилам, а использует случайность и Хаос, которые не требуют сложных вычислений. QSPN выполняется в реальных сетях, узлы посылают QSPN пакеты для создания сети. По этой причине не всегда верно утверждение, что определённый пакет будет отослан раньше какого-либо другого. NETSUKUKU не ограничивается созданием только сетей из компьютеров. Это протокол, который может использоваться в любой ситуации, когда надо соединить точки между собой. Мобильная телефонная сеть представляет собой тысячи узлов, связанных с одним узлом, который распределяет трафик и передаёт информацию узлу назначения. NETSUKUKU может быть использована в мобильных телефонах, сделав бессмысленным существование многочисленных операторов сотовой связи. NETSUKUKU может быть внедрена в любые коммуникационные системы, которые сейчас используются. [править] Протокол Npv7 Протокол NETSUKUKU, первая версия. NETSUKUKU использует свой собственный протокол Npv7, который родился из трёх предыдущих версий. Первый был очень похож на нынешние протоколы динамического управления: сеть была фактически разделена на несколько групп, и каждый сигнальный узел имел чёткую карту полной сети. Такая система не могла работать с NETSUKUKU, так как требовалось постоянно обновлять карту сети и каждое обновление приводило к перегрузке сети. Кроме того, после каждого обновления сети требовалось пересчитать все пути. Разграничения NETSUKUKU. Базовые определения: src_node Исходный узел. Узел, который отправляет пакет узлу назначения dst_node. dst_node Узел назначения. Узел, который получает пакет от исходного узла src_node. r_node Удалённый узел, от узла X, это любой узел связанный с узлом X. g_node Группа узлов или группа групп узлов. b_node Пограничный узел — узел, соединённый с двумя (r_node) узлами из разных (g_node) групп узлов. h_node Цепляющийся узел — узел, подсоединяющийся к NETSUKUKU. int_map Внутренняя карта. Внутренняя карта узла X содержит информацию о группе узлов (g_node), к которой он принадлежит. ext_map Внешняя карта. Карта содержит информацию о группах узлов. bmap/bnode_map Карта пограничных узлов. Карта содержит информацию о (b_node) пограничных узлах. Npv7 II Лазерная передача, направленная сразу нескольким неспецифицированным приёмникам. Npv7 II вторая версия прокола Npv7. NETSUKUKU разделена на много маленьких групп узлов, до ста узлов в каждой группе, и каждый узел имеет внешнюю карту маршрутов. Все группы организованны в мультигруппы, называемые quadro group_node. Для того, чтобы создать новый маршрут и соединится с заданным узлом, исходный узел, использую свою внешнюю карту, сначала ищет наилучший путь до пограничного узла группы, к которой принадлежит узел назначения. [править] QSPN Тому, кто знаком с физикой волны, будет просто понять, как работает qspn. Если бросить камень в бассейн с водой, то можно наблюдать следующее: волны начинают распространяться из начальной точки, причём каждая волна рождает новую волну, которая продолжает распространяться и рождать все новые и новые волны. Когда волна ударяется о края бассейна или о какую-то преграду, она отражается и начинает распространяться в обратную сторону. В применении к qspn камень — это qspn_starter, бассейн — gnode, а каждая волна — tracer_pkt. Каждая новая волна несёт с собой информацию о родившей её волне. Когда tracer_pkt(волна) достигает extreme_node (препятствия или границы бассейна), рождается qspn_open (отражённая волна). QSPN базируется на описанном принципе. Начиная трассировку узлов, каждый узел посылает qspn_pkt, называемый qspn_close, становясь тем самым qspn_starter. Qspn_pkt это обычный tracer_pkt, но его метод вещания немного отличается от остальных. Каждый пакет, который получает qspn_close, «закрывает» линк узла, от которого получил этот пакет и отсылает пакеты по всем своим остальным линкам. Все последующие полученные qspn_close пакеты будут переправляется по всем оставшимся незакрытым линкам. Через некоторый промежуток времени появляются узлы, у которых все линки будут закрыты. Такие узлы становятся extreme_node и посылают в качестве ответа другой qspn_pkt пакет (qspn_open). Другими словами, qspn_open пакет отправляется, после того как получены qspn_close пакты от всех узлов. Пакет qspn_open содержит всю информацию, собранную в последнем полученном пакете qspn_close. Extreme_node посылает пакет qspn_open по всем своим линкам, кроме того узла, от которого он получил последний qspn_close; этому узлу отсылается пустой пакет. Другими словами, пакет qspn_open отправляется после того, как узел получил пакет qspn_close от всех узлов. Узел, получивший пакет qspn_open, открывает все линки. Узлы со всеми открытыми связями абсолютно ничего не делают. Таким образом, гарантируется законченность обмена пакетами qspn_close. У qspn_open пакетов также есть идентификационный номер(sub_id) — число, которое идентифицирует во внешних картах узлы «extreme_node», сгенерировавшие эти qspn_open пакеты. Sub_id, сгенерированный в самом первом пакете и не меняющийся во всех порождённых(qspn_open) пакетах, используется для управления большим числом qspn_pkt пакетов, так как рано или поздно каждый узел сгенерирует пакет qspn_open, и все они должны быть независимы и отличны друг от друга. Действительно, все узлы, которые имеют только одну связь, — это узлы extreme_node, ведь когда они получают qspn_close, они уже закрыты. После отправки пакета qspn_open узел не может отвечать больше никому и ни на какие полученные qspn_pkt пакеты, поэтому он больше ничего не отправляет. Узел qspn_starter, который запустил qspn, становится обычным узлом, но не отправляет пакет qspn_open, так как отправил первый qspn_close. Кроме того, чтобы обновить свою собственную карту, узел будет использовать все полученные qspn_close пакеты, кроме тех, которые были отправлены такими же qspn_start узлами. Таким образом, поддерживается стабильность в случае наличия более одного узла «qspn_starter».
без сомнения, очень интересно, и надо бы разобрать их наработки, но проект мертв. и похоже, что давно и надежно.
есть исходники , год 2007 .... все основное есть, протокол ип тоже давно не менялся но он же не мертв
