P2P – социальная сеть / форум / файловая система
Планирую создать P2P социальную сеть, которая позволит общаться (как в виде форума, так и в виде почты), обмениваться файлами, публиковать статьи без центральных серверов, а также по желанию участников делать это псевдонимно или даже анонимно. Возможно, стоит использовать существующие сети вроде FreeNet (Frost-форум) или Tor (Torchat).
Проект разрабатывается под лицензией GPL.
Вот некоторые наброски концепции.
Помогите разобраться.
Мета-ообъекты сети
Мета-ообъекты имеют уникальный референс в пределах сети.
Есть два варианта структуры референса, пока не знаю какой выбрать:
a)
Reference: 00 0000000000000000 0000000000000000 00-control ( 36 symbols )
b)
Reference: 00 0000000000000000 0000000000000000 0000 00-control ( 40 symbols )
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
(не подписаны, зашифрованы публичным ключом группы-получателя)
комментариев: 9796 документов: 488 редакций: 5664
комментариев: 11558 документов: 1036 редакций: 4118
А идея реализации? Вы знакомы с Tahoe-LAFS? В общем, присоединяюсь к unknown'у: велосипедостроение в полный рост без даже примерного понимания амбициозности задачи.
WTF?
Перенёс топик.
Я бы не хотел изобретать велосипедов на самом деле, я бы лучше написал надстройку к существующей и популярной сети с большим числом клиентов. Может быть стоит использовать в качестве транспорта пакетов Tor или I2P. Пока у меня есть общее представление и желание реализовать для начала что-то не слишком сложное – форум, например. Потом можно уже будет добавлять к нему другие социальные функции. Я хочу избежать центральных серверов, поэтому мне не подходят onion- или i2p-сайты в их типичном использовании. Нужно что-то больше похожее на старые BBS, но в p2p-исполнении и шифрованные.
Мне необходим KeyID. Хэш ключа целиком использовать нежелательно, т.к. он довольно длинный.
Мне непонятно, как можно использовать для этого последние 16 символов от хэша ключа, как это сделано на pgpru, ведь могут быть коллизии у ключей, у которох разные хэши, но одинаковые последние 16 знаков. Поэтому я хочу подсчитать CRC64 от всего отпечатка ключа и таким образом свернуть его до 16 знаков – я предполагал, что коллизий CRC64 от строк постоянной длины будет меньше, чем, если бы брать последние 16 символов от этих строк.
комментариев: 1060 документов: 16 редакций: 32
Это неочевидно, как минимум.
комментариев: 11558 документов: 1036 редакций: 4118
6BBF A6A8 2488 F017 4211 0AA5 FAEB 26F7 8443 620A
На pgpru используется соотв. KeyID:
0xFAEB26F78443620A
Я же предлагаю использовать такой KeyID = CRC64(6BBFA6A82488F01742110AA5FAEB26F78443620A) = 0xB203ED5C579C4BC4
А с чего бы? Хороший хэш почти случаен, в последних символах – тоже, и существенно более случайным вы его никак не сделаете.
комментариев: 9796 документов: 488 редакций: 5664
Исследователи используют протоколы приватного пересечения множеств, авторизованного пересечения множеств, приватного раскрытия контактов, анонимного поиска, атрибутов доступа на основе шифрования, доказательства скрытого членства с нулевым разглашением, широковещательного шифрования с открытым ключом, шифрованные DHT. Используются различные системы доказательств стойкости и оптимизационные техники.
А тем временем очередные шифрпанки лепят протоколы на коленке на основе интуитивных представлений о криптографии, подходящих для 80-х годов прошлого века. Без каких-либо доказательств и малейшего желания ознакомиться с теоретическими исследованиями в этой области.
комментариев: 11558 документов: 1036 редакций: 4118
Нет, всё было понятно, но, как уже было сказано, Ваше решение ненадёжно: можно подобрать такой отпечаток, который с большей вероятностью даст коллизию в CRC, чем она бы возникла в сокращённом хэше.
комментариев: 9796 документов: 488 редакций: 5664
Вероятность коллизии Hash1 (X) = Hash1 (Y) равна 2-n/2 при размере X и Y ≥ n и размеру выхода хэша = n.
Урезание хэша и соответственно увеличение вероятности коллизии эквивалентно урезанию размера n. Посмотрите внимательно на формулу того, что вы делаете:
Hash2 (Hash1 (X)) = Hash2 (Hash1 (Y))
Это уже не говоря про CRC в качестве Hash2, который здесь вообще не к месту.
комментариев: 9796 документов: 488 редакций: 5664
Готовые урезанные хэши придумали для того, чтобы не тратить ресурсы на просчёт длинного, а затем отрезать от него. Если хэш не взломан, идеален, экономия на ресурсах не важна, то никакой разницы, всё укладывается в /comment75140.
Подробнее разбиралось в отдельной теме.