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 След.

Комментарии

—	*Гость* (26/12/2013 19:15) <#>

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

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

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

—	SATtva (27/12/2013 08:27, исправлен 27/12/2013 08:28) профиль/связь <#> комментариев: 11558 документов: 1036 редакций: 4118

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

А идея реализации? Вы знакомы с Tahoe-LAFS? В общем, присоединяюсь к unknown'у: велосипедостроение в полный рост без даже примерного понимания амбициозности задачи.

> CRC64( Hash(

WTF?

Перенёс топик.

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

Смотрел в сторону Kademlia, Freenet, GNUNet, Netsukuku, Darknet, Pandora, читал об устройстве облачных хранилищ в общем. SATtva, спасибо за подсказку насчет Tahoe-LAFS.

Я бы не хотел изобретать велосипедов на самом деле, я бы лучше написал надстройку к существующей и популярной сети с большим числом клиентов. Может быть стоит использовать в качестве транспорта пакетов Tor или I2P. Пока у меня есть общее представление и желание реализовать для начала что-то не слишком сложное – форум, например. Потом можно уже будет добавлять к нему другие социальные функции. Я хочу избежать центральных серверов, поэтому мне не подходят onion- или i2p-сайты в их типичном использовании. Нужно что-то больше похожее на старые BBS, но в p2p-исполнении и шифрованные.

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

> CRC64( Hash(

Мне необходим KeyID. Хэш ключа целиком использовать нежелательно, т.к. он довольно длинный.
Мне непонятно, как можно использовать для этого последние 16 символов от хэша ключа, как это сделано на pgpru, ведь могут быть коллизии у ключей, у которох разные хэши, но одинаковые последние 16 знаков. Поэтому я хочу подсчитать CRC64 от всего отпечатка ключа и таким образом свернуть его до 16 знаков – я предполагал, что коллизий CRC64 от строк постоянной длины будет меньше, чем, если бы брать последние 16 символов от этих строк.

—	sentaus (27/12/2013 12:15) профиль/связь <#> комментариев: 1060 документов: 16 редакций: 32

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

Это неочевидно, как минимум.

—	SATtva (27/12/2013 12:22) профиль/связь <#> комментариев: 11558 документов: 1036 редакций: 4118

CRC-коды не имеют коллизионной стойкости, в отличие от криптографических хэшей. Отбрасывание старших битов от вывода хэш-функции — стандартный метод укорачивания хэш-значения.

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

Кажется, я непонятно написал. Ну вот пример. Отпечаток ключа SATtva:
6BBF A6A8 2488 F017 4211 0AA5 FAEB 26F7 8443 620A
На pgpru используется соотв. KeyID:
0xFAEB26F78443620A
Я же предлагаю использовать такой KeyID = CRC64(6BBFA6A82488F01742110AA5FAEB26F78443620A) = 0xB203ED5C579C4BC4

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

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

А с чего бы? Хороший хэш почти случаен, в последних символах – тоже, и существенно более случайным вы его никак не сделаете.

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

DECENT — очередной концепт-проект распределённой приватной социальной сети, Создан прототип протокола для построения приватных социальных сетей, Криптографическое решение проблемы приватности пользовательских профайлов, Первое испытание приватной соцсети MyZone для малых закрытых сообществ.

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

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

—	SATtva (27/12/2013 12:48) профиль/связь <#> комментариев: 11558 документов: 1036 редакций: 4118

Кажется, я непонятно написал.

Нет, всё было понятно, но, как уже было сказано, Ваше решение ненадёжно: можно подобрать такой отпечаток, который с большей вероятностью даст коллизию в CRC, чем она бы возникла в сокращённом хэше.

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

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

Вероятность коллизии Hash₁ (X) = Hash₁ (Y) равна 2^-n/2 при размере X и Y ≥ n и размеру выхода хэша = n.

Урезание хэша и соответственно увеличение вероятности коллизии эквивалентно урезанию размера n. Посмотрите внимательно на формулу того, что вы делаете:

Hash₂ (Hash₁ (X)) = Hash₂ (Hash₁ (Y))

Это уже не говоря про CRC в качестве Hash₂, который здесь вообще не к месту.

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

Спасибо, насчет хэшей и crc я понял, буду делать как на pgpru. По принципу укорачивания хэша работает, кажется, укороченные варианты Tiger128/160/192 и SHA224/256 & SHA384/512. Такой еще вопрос – лучше использовать короткую хэш-функцию вроде SHA-1 для этого, или же длинную вроде SHA-512. Т.е. имееи ли значение – отрезать от короткого или от длинного хэша?

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

Готовые урезанные хэши придумали для того, чтобы не тратить ресурсы на просчёт длинного, а затем отрезать от него. Если хэш не взломан, идеален, экономия на ресурсах не важна, то никакой разницы, всё укладывается в /comment75140.

Подробнее разбиралось в отдельной теме.

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

децентрализованная социальная сеть, как i2p "сервис" с распределенной файловой системой?

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

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