P2P – социальная сеть / форум / файловая система

Планирую создать P2P социальную сеть, которая позволит общаться (как в виде форума, так и в виде почты), обмениваться файлами, публиковать статьи без центральных серверов, а также по желанию участников делать это псевдонимно или даже анонимно. Возможно, стоит использовать существующие сети вроде FreeNet (Frost-форум) или Tor (Torchat).

Проект разрабатывается под лицензией GPL.

Вот некоторые наброски концепции.
Помогите разобраться.

Мета-ообъекты сети

Мета-ообъекты имеют уникальный референс в пределах сети.

Есть два варианта структуры референса, пока не знаю какой выбрать:
a)
Reference: 00 0000000000000000 0000000000000000 00-control ( 36 symbols )

ClassID NodeID ObjID

b)
Reference: 00 0000000000000000 0000000000000000 0000 00-control ( 40 symbols )

ClassID NodeID ObjID ObjVersion

ClassID (0..ff) – идентификатор класса объекта (0..255 вполне достаточно)
NodeID (0..ffffffffffffffff) – идентификатор узла, на котором был сгенерирован референс,

т.е. где впервые создан объект

ObjID (0..ffffffffffffffff) – локальный идентификатор объекта в базе данных узла NodeID
ObjVersion (0..ffff) – версия (глобальное векторное время) объекта.

каждое изменение объекта на любом узле системы ведет к увеличению версии объекта.
Стоит ли включать версию объекта в референс?

control (0..ff) – контрольная сумма CRC8 от предыдущей части референса,

предназначена для уменьшения числа ошибок при ручном вводе

Мета-объекты имеют хэш, вычисляемый от критических свойств объекта.
Объекты с одинаковым референсом, но раным хэшем – это разные версии объекта.
Номер версии при этом (векторное время) может быть одинаковым -
тогда это будет означать конфликт версий объекта.
Какую версию объекта принять должна решать принимающая сторона.

Распределенная файловая система

Придерживаясь принципов unix, любые объекты сети можно представить в виде файлов.
Файлы находятся в директориях. Директории могут быть вложенными и вложенность
может ветвиться по типу деревьев.
(Файлами могут быть сообщения на форумах, а директориями – разделы и темы форумов).

Директории и файлы имеют права доступа, согласно unix-концепции.
Owner[0..7]:Group[0..7]:Other[0..7]

Каждая директория или файл может принадлежать только одному пользователю и только одной группе.
Если файл или директория должны принадлежать всей группе, но никому в отдельности,
то используется Owner=nobody с правами 07x
Если директории или файл должны быть доступны всем без разбора,
то используется Owner=nobody и Group=nogroup с правами 007

Пользователи

Каждый пользователь имеет свой приватный и публичный ключи.
Остальные могут иметь только публичный ключ пользователя.
TheUserID = CRC64( Hash(TheUser.PublicKey) )

Если приватный ключ пользователя скомпроментирован, то нельзя просто перегенерировать ключевую пару.
Генерация новой ключевой пары означает новый публичный ключ и новый идентификатор пользователя,
поэтому нельзя просто изменить ключевую пару – нужно создать нового пользователя.
Прежнего пользователя необходимо деактивировать – для этого можно использовать отзывающий сертификат.

- Вопрос? Как правильно генерировать и использовать отзывающий сертификат?
Что он из себя представляет?

Группы

Любой пользователь может состоять в нескольких группах.

В группе могут состоять только пользователи, но не группы.
Вложенность групп не допускается.

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

Каждый член группы имеет ее приватный и публичный ключи.
Остальные могут иметь только публичный ключ группы.
TheGroupID = CRC64( Hash(TheGroup.PublicKey) )

Если возникает необходимость удалить пользователя из группы, то нужно закрыть эту группу
и создать новую, состоящую из всех членов предыдущей, кроме удаленного члена.
Генерация новой ключевой пары означает новый публичный ключ и новый идентификатор группы,
поэтому нельзя просто изменить ключевую пару – нужно создать новую группу.
Прежнюю группу необходимо деактивировать – для этого можно использовать отзывающий сертификат.

Можно ли как-то не закрываь группу, если нужно удалить одного или нескольких членов?

Принятие решений в группах

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

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

(Что-то вроде пиратской карты, куски которой отданы нескольким пиратам,
и чтобы откопать клад нужно собрать все куски карты снова.)
Например, при создании группы решается разделить приватный ключ решений так,
что любые 2/3 участников группы могут собрать свои части ключа решений вместе,
подписав таким образом некое решение группы.

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

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

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

Типы пакетов/сообщений

a)
1.user1=>user2

от пользователя к пользователю
(подписаны приватным ключом пользователя-отправителя, зашифрованы публичным ключом пользователя-получателя)

2.group=>user

от неизвестн-ого(ых) член-а(ов) группы к пользователю
(подписаны приватным ключом группы-отправителя, зашифрованы публичным ключом пользователя-получателя)

3.anonymous=>user

от анонима к полюзователю
(не подписаны, зашифрованы публичным ключом пользователя-получателя)

b)
1.user=>group

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

2.group1=>group2

от неизвестн-ого(ых) член-а(ов) одной группы ко всем членам другой группы
(подписаны приватным ключом группы-отправителя, зашифрованы публичным ключом группы-получателя )

3.anonymous=>group

от анонима к группе
(не подписаны, зашифрованы публичным ключом группы-получателя)

На страницу: 1, 2 След.

Комментарии

—	*Гость* (27/12/2013 17:00) <#>

unknown, спасибо за ссылки, когда-то их читал, сейчас буду перечитывать. В целом, хочется что-то похожее на этот самый MyZone, но со свободными исходниками и рабочее. Tahoe-LAFS – штука интересная, но боюсь, что пока не получит широкого распространения, хотя может и получится как-то использовать. Есть форум Frost во FreeNet, но его очень сложно ставить, массововсти не добиться. В свете публикаций Сноудена, сегодня довольно широко распространились Tor и i2p – хотелось бы использовать их, если получится.
Гость, не очень понял что значит i2p "сервис" с распределенной файловой системой? Я хочу, чтобы пользователи могли обмениваться по DHT ссылками на свои ресурсы и управлять ими, обновлять. Ресурсами может быть что угодно – от файлов до сообщений и статусов, что в общем виде можно было бы реализовать в виде файлов.

—	*Гость* (27/12/2013 17:32) <#>

> Tor и i2p – хотелось бы использовать их

I2P как концепция мёртв, читайте отсюда и далее.

—	*Гость* (30/12/2013 12:18) <#>

Что, если для каждого объекта DHT генерировать свою ключевую пару?
Приватный и публичный ключ находятся у создателя объекта.
Объект зашифровывать приватным ключом.
Если кому-то нужно дать право на чтение, то выдаем ему публичный ключ объекта.
Если кому-то нужно дать право на запись, то выдаем ему приватный ключ объекта.

—	*Гость* (30/12/2013 12:25) <#>

Хватит ли пространства ключевых пар в таком слчае? Если максимальное число объектов для одного пользователя 2^64,максимальное число пользователей 2^64, а значит максимальное число объектов сети 2^4096. Будут ли коллизии?

—	*Гость* (12/01/2014 02:16) <#>

> Публичный ключ решений рассылается всем членам группа, а приватный ключ решений разделяется между членами группы по некоему правилу, так что восстановить его может только минимально-необходимое число участников. (Что-то вроде пиратской карты, куски которой отданы нескольким пиратам, и чтобы откопать клад нужно собрать все куски карты снова.) Например, при создании группы решается разделить приватный ключ решений так, что любые 2/3 участников группы могут собрать свои части ключа решений вместе, подписав таким образом некое решение группы.

Shamir's Secret Sharing.

> Я хочу избежать центральных серверов, поэтому мне не подходят onion- или i2p-сайты в их типичном использовании

Onion — не центральный сайт. Любой Tor-клиент, в т.ч., находящийся за NAT'ом, может поднять свой onion-домен, сделав его доступным любому другому клиенту Tor-сети. На этом принципе работает, например, TorChat. Связь между Tor-клиентами — первое приближение к анонимной p2p-сети.

> Директории и файлы имеют права доступа, согласно unix-концепции. Owner[0..7]:Group[0..7]:Other[0..7]

Даже если вам так хочется использовать аналогию с UNIX, то вы должны знать, что UNIX'овые права доступа были придуманы очень давно и столь же давно устарели, их присутствие в современных системах — дань исторически сложившимся обстоятельствам. Современный аналог прав доступа — ACL.

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

В дополнение к вышесказанному другими частниками: если вы это можете строго показать, то вы продвинулись в криптоанализе хэш-функций дальше чем, чем известно открытому сообществу. Ваш труд тянет на статью в респектабельном научном журнале. По такой статье, возможно, вы даже сможете защитить диссертацию и получить PhD в computer science. В общем, будьте поосторожений с такими заявлениями.

> Приватный и публичный ключ находятся у создателя объекта. Объект зашифровывать приватным ключом. Если кому-то нужно дать право на чтение, то выдаем ему публичный ключ объекта. Если кому-то нужно дать право на запись, то выдаем ему приватный ключ объекта.

Если вы о традиционной криптографии с открытым ключом, то там данные шифруются публичным ключом, а не приватным. Зашифровать приватным, насколько я знаю, нельзя. Что-то подобное (права к файлам на основе ключей) здесь недавно встречалось в обсуждениях Microsoft EFS [1], [2].

P.S. Мой пост не отрицает вышесказанного SATtva'ой и unknown'ом: это бездумное шифрпанковское велоси^{педостроительство}. Топовым учёным в CS, работавшим в этой области, с трудом удавалось за несколько лет придмать какие-то протоколы, которые покарывают защиту лишь от части возможных атак без замахивания на большее. Это сложные и тяжёлые протоколы, причём как для понимания, так и для имплементации. Остальные способны только набыдлокодить очередную дырявую поделку.

—	*Гость* (12/01/2014 02:27) <#>

> Если максимальное число объектов для одного пользователя 2⁶⁴,максимальное число пользователей 2⁶⁴, а значит максимальное число объектов сети 2⁴⁰⁹⁶. Будут ли коллизии?

Во всех (даже идеальных) функциях могут (и по определённой статистической зависимости должны быть) быть коллизии при любом размере сообщения. Вопрос в вероятности их возникновения и отсутствии возможности находить их быстрее простого перебора.

за счёт того, что вы хотите сконструировать функцию вообще без коллизий в пределах блока на основе блочного шифра, вы и получите тривиальное нахождение по-крайней мере одной коллизии за счёт обратного расшифрования всех блоков по цепочке для сообщения любой длины. Т.е. абсолютно дефектный алгоритм хэширования.

Не надо пытаться сделать конструкцию случайнее, чем случайный оракул и идеальнее, чем идеал :) Не должно быть различителей между идеальной PRF, в которой могут выпадать совпадения, как положено по статистике.

Это просто фундаментальные вещи, нарушение которых рушит всё доказательство стойкости. Возможно, отсутствие коллизий в изначальной конструкции (предусмотренных естественной статистикой) приведёт к тому, что искать сообщение-ключ станет станет быстрее, чем простой перебор n/2 вариантов (как было бы по парадоксу дней рождения). И тогда, на самом деле, число коллизий будет не строго равно нулю, а недопустимо близко к нулю. И они отыщутся быстрее. Это как невозможные (никогда не выпадающие) дифференциалы в криптоанализе — метод, обратный (или комплементарный) дифференциальному криптоанализу. Ну или совсем художественный пример — помните Шерлока Холмса с методом дедукции? Если мы знаем то, чего не может быть, что можно исключить, значит мы тоже сокращаем искомое множество, оно становится статистически неравномерным.

—	unknown (12/01/2014 14:49) профиль/связь <#> комментариев: 9796 документов: 488 редакций: 5664

Если вы о традиционной криптографии с открытым ключом, то там данные шифруются публичным ключом, а не приватным. Зашифровать приватным, насколько я знаю, нельзя.

На шифровании приватным ключом построены, например, подписи RSA. Только владелец приватного ключа может зашифровать строку (хэш) так, что все, кто знает открытый ключ, могут это расшифровать и убедиться, что шифрование могло быть произведено только владельцем приватного (закрытого) ключа.

Хотя это формализм. В подписи неважно, какой показатель e или d считать открытым, а какой приватным в выражении e d ≡ 1 (mod φ(N)), если для закрытого ключа использовать один из них, а для открытого — второй, совместно с N. Если только как раньще, для экономии не использовался один и тот же ключ и для шифрования и для подписи, от чего впоследствии отказались.

Т.е. в RSA подпись и шифрование устроены на одинаковом принципе.

—	*Гость* (12/01/2014 19:59) <#>

Спасибо за объяснение. Не знал этого.

—	руслан (17/08/2014 15:42) <#>

Зделай по принцепу Kademlia ,Kad Network, kad

—	*Гость* (17/08/2014 21:33) <#>

Зделай по принцепу

Дарья, вы нас ником не обманете.

На страницу: 1, 2 След.

Ваша оценка документа [показать результаты]