P2P – социальная сеть / форум / файловая система
Планирую создать P2P социальную сеть, которая позволит общаться (как в виде форума, так и в виде почты), обмениваться файлами, публиковать статьи без центральных серверов, а также по желанию участников делать это псевдонимно или даже анонимно. Возможно, стоит использовать существующие сети вроде FreeNet (Frost-форум) или Tor (Torchat).
Проект разрабатывается под лицензией GPL.
Вот некоторые наброски концепции.
Помогите разобраться.
Мета-ообъекты сети
Мета-ообъекты имеют уникальный референс в пределах сети.
Есть два варианта структуры референса, пока не знаю какой выбрать:
a)
Reference: 00 0000000000000000 0000000000000000 00-control ( 36 symbols )
ClassID NodeID ObjID
Reference: 00 0000000000000000 0000000000000000 0000 00-control ( 40 symbols )
ClassID NodeID ObjID ObjVersion
ClassID (0..ff) – идентификатор класса объекта (0..255 вполне достаточно)
NodeID (0..ffffffffffffffff) – идентификатор узла, на котором был сгенерирован референс,
т.е. где впервые создан объект
ObjVersion (0..ffff) – версия (глобальное векторное время) объекта.
каждое изменение объекта на любом узле системы ведет к увеличению версии объекта.
Стоит ли включать версию объекта в референс?
Стоит ли включать версию объекта в референс?
предназначена для уменьшения числа ошибок при ручном вводе
Мета-объекты имеют хэш, вычисляемый от критических свойств объекта.
Объекты с одинаковым референсом, но раным хэшем – это разные версии объекта.
Номер версии при этом (векторное время) может быть одинаковым -
тогда это будет означать конфликт версий объекта.
Какую версию объекта принять должна решать принимающая сторона.
Распределенная файловая система
Придерживаясь принципов 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(подписаны приватным ключом группы-отправителя, зашифрованы публичным ключом группы-получателя )
от анонима к группе
(не подписаны, зашифрованы публичным ключом группы-получателя)
(не подписаны, зашифрованы публичным ключом группы-получателя)
Ссылки
[link1] https://www.pgpru.com/novosti/2011/decentocherednojjkonceptproektraspredeljonnojjprivatnojjsocialjnojjseti
[link2] https://www.pgpru.com/novosti/2011/sozdanprototipprotokoladljapostroenijaprivatnyhsocialjnyhsetejj
[link3] https://www.pgpru.com/novosti/2011/kriptograficheskoereshenieproblemyprivatnostipoljzovateljskihprofajjlov
[link4] https://www.pgpru.com/novosti/2013/pervoeispytanieprivatnojjsocsetimyzonedljamalyhzakrytyhsoobschestv
[link5] https://www.pgpru.com/comment75140
[link6] https://www.pgpru.com/forum/kriptografija/obrezanyeheshi
[link7] https://www.pgpru.com/comment72179
[link8] https://www.pgpru.com/comment72068
[link9] https://en.wikipedia.org/wiki/Shamir's_Secret_Sharing
[link10] https://www.pgpru.com/forum/prakticheskajabezopasnostj/encryptedfilesystem
[link11] https://www.pgpru.com/comment74183
[link12] https://www.pgpru.com/comment61421
[link13] https://www.pgpru.com/comment61435
[link14] https://www.pgpru.com/comment61514
[link15] http://cn13.nevsedoma.com.ua/photo/371/7/8_files/kommentc.jpg
Ага. Вот вижу проблему с принятием решений. Один и тот же воссозданный ключ нельзя допустить использовать повторно для принятие решения по другому вопросу. Перегенерировать после голосования?
Посмотрите у нас новости за последние несколько лет. Там рассматривались работы по анонимным социальным сетям. У лучших исследователей всё как-то не взлетает. Посмотрите хотя бы на сложности и ошибки, чтобы не повторять.
А идея реализации? Вы знакомы с Tahoe-LAFS? В общем, присоединяюсь к unknown'у: велосипедостроение в полный рост без даже примерного понимания амбициозности задачи.
WTF?
Перенёс топик.
Смотрел в сторону Kademlia, Freenet, GNUNet, Netsukuku, Darknet, Pandora, читал об устройстве облачных хранилищ в общем. SATtva, спасибо за подсказку насчет Tahoe-LAFS.
Я бы не хотел изобретать велосипедов на самом деле, я бы лучше написал надстройку к существующей и популярной сети с большим числом клиентов. Может быть стоит использовать в качестве транспорта пакетов Tor или I2P. Пока у меня есть общее представление и желание реализовать для начала что-то не слишком сложное – форум, например. Потом можно уже будет добавлять к нему другие социальные функции. Я хочу избежать центральных серверов, поэтому мне не подходят onion- или i2p-сайты в их типичном использовании. Нужно что-то больше похожее на старые BBS, но в p2p-исполнении и шифрованные.
Мне необходим KeyID. Хэш ключа целиком использовать нежелательно, т.к. он довольно длинный.
Мне непонятно, как можно использовать для этого последние 16 символов от хэша ключа, как это сделано на pgpru, ведь могут быть коллизии у ключей, у которох разные хэши, но одинаковые последние 16 знаков. Поэтому я хочу подсчитать CRC64 от всего отпечатка ключа и таким образом свернуть его до 16 знаков – я предполагал, что коллизий CRC64 от строк постоянной длины будет меньше, чем, если бы брать последние 16 символов от этих строк.
Это неочевидно, как минимум.
CRC-коды не имеют коллизионной стойкости, в отличие от криптографических хэшей. Отбрасывание старших битов от вывода хэш-функции — стандартный метод укорачивания хэш-значения.
Кажется, я непонятно написал. Ну вот пример. Отпечаток ключа SATtva:
6BBF A6A8 2488 F017 4211 0AA5 FAEB 26F7 8443 620A
На pgpru используется соотв. KeyID:
0xFAEB26F78443620A
Я же предлагаю использовать такой KeyID = CRC64(6BBFA6A82488F01742110AA5FAEB26F78443620A) = 0xB203ED5C579C4BC4
А с чего бы? Хороший хэш почти случаен, в последних символах – тоже, и существенно более случайным вы его никак не сделаете.
DECENT — очередной концепт-проект распределённой приватной социальной сети[link1], Создан прототип протокола для построения приватных социальных сетей[link2], Криптографическое решение проблемы приватности пользовательских профайлов[link3], Первое испытание приватной соцсети MyZone для малых закрытых сообществ[link4].
Исследователи используют протоколы приватного пересечения множеств, авторизованного пересечения множеств, приватного раскрытия контактов, анонимного поиска, атрибутов доступа на основе шифрования, доказательства скрытого членства с нулевым разглашением, широковещательного шифрования с открытым ключом, шифрованные DHT. Используются различные системы доказательств стойкости и оптимизационные техники.
А тем временем очередные шифрпанки лепят протоколы на коленке на основе интуитивных представлений о криптографии, подходящих для 80-х годов прошлого века. Без каких-либо доказательств и малейшего желания ознакомиться с теоретическими исследованиями в этой области.
Нет, всё было понятно, но, как уже было сказано, Ваше решение ненадёжно: можно подобрать такой отпечаток, который с большей вероятностью даст коллизию в CRC, чем она бы возникла в сокращённом хэше.
Вероятность коллизии Hash1 (X) = Hash1 (Y) равна 2-n/2 при размере X и Y ≥ n и размеру выхода хэша = n.
Урезание хэша и соответственно увеличение вероятности коллизии эквивалентно урезанию размера n. Посмотрите внимательно на формулу того, что вы делаете:
Hash2 (Hash1 (X)) = Hash2 (Hash1 (Y))
Это уже не говоря про CRC в качестве Hash2, который здесь вообще не к месту.
Спасибо, насчет хэшей и crc я понял, буду делать как на pgpru. По принципу укорачивания хэша работает, кажется, укороченные варианты Tiger128/160/192 и SHA224/256 & SHA384/512. Такой еще вопрос – лучше использовать короткую хэш-функцию вроде SHA-1 для этого, или же длинную вроде SHA-512. Т.е. имееи ли значение – отрезать от короткого или от длинного хэша?
Готовые урезанные хэши придумали для того, чтобы не тратить ресурсы на просчёт длинного, а затем отрезать от него. Если хэш не взломан, идеален, экономия на ресурсах не важна, то никакой разницы, всё укладывается в /comment75140[link5].
Подробнее разбиралось в отдельной теме[link6].
децентрализованная социальная сеть, как i2p "сервис" с распределенной файловой системой?
unknown, спасибо за ссылки, когда-то их читал, сейчас буду перечитывать. В целом, хочется что-то похожее на этот самый MyZone, но со свободными исходниками и рабочее. Tahoe-LAFS – штука интересная, но боюсь, что пока не получит широкого распространения, хотя может и получится как-то использовать. Есть форум Frost во FreeNet, но его очень сложно ставить, массововсти не добиться. В свете публикаций Сноудена, сегодня довольно широко распространились Tor и i2p – хотелось бы использовать их, если получится.
Гость, не очень понял что значит i2p "сервис" с распределенной файловой системой? Я хочу, чтобы пользователи могли обмениваться по DHT ссылками на свои ресурсы и управлять ими, обновлять. Ресурсами может быть что угодно – от файлов до сообщений и статусов, что в общем виде можно было бы реализовать в виде файлов.
I2P как концепция мёртв[link7], читайте отсюда[link8] и далее.
Что, если для каждого объекта DHT генерировать свою ключевую пару?
Приватный и публичный ключ находятся у создателя объекта.
Объект зашифровывать приватным ключом.
Если кому-то нужно дать право на чтение, то выдаем ему публичный ключ объекта.
Если кому-то нужно дать право на запись, то выдаем ему приватный ключ объекта.
Хватит ли пространства ключевых пар в таком слчае? Если максимальное число объектов для одного пользователя 2^64,максимальное число пользователей 2^64, а значит максимальное число объектов сети 2^4096. Будут ли коллизии?
Shamir's Secret Sharing[link9].
Onion — не центральный сайт. Любой Tor-клиент, в т.ч., находящийся за NAT'ом, может поднять свой onion-домен, сделав его доступным любому другому клиенту Tor-сети. На этом принципе работает, например, TorChat. Связь между Tor-клиентами — первое приближение к анонимной p2p-сети.
Даже если вам так хочется использовать аналогию с UNIX, то вы должны знать, что UNIX'овые права доступа были придуманы очень давно и столь же давно устарели, их присутствие в современных системах — дань исторически сложившимся обстоятельствам. Современный аналог прав доступа — ACL.
В дополнение к вышесказанному другими частниками: если вы это можете строго показать, то вы продвинулись в криптоанализе хэш-функций дальше чем, чем известно открытому сообществу. Ваш труд тянет на статью в респектабельном научном журнале. По такой статье, возможно, вы даже сможете защитить диссертацию и получить PhD в computer science. В общем, будьте поосторожений с такими заявлениями.
Если вы о традиционной криптографии с открытым ключом, то там данные шифруются публичным ключом, а не приватным. Зашифровать приватным, насколько я знаю, нельзя. Что-то подобное (права к файлам на основе ключей) здесь недавно встречалось в обсуждениях Microsoft EFS [1][link10], [2][link11].
P.S. Мой пост не отрицает вышесказанного SATtva'ой и unknown'ом: это бездумное шифрпанковское велосипедостроительство. Топовым учёным в CS, работавшим в этой области, с трудом удавалось за несколько лет придмать какие-то протоколы, которые покарывают защиту лишь от части возможных атак без замахивания на большее. Это сложные и тяжёлые протоколы, причём как для понимания, так и для имплементации. Остальные способны только набыдлокодить очередную дырявую поделку.
На шифровании приватным ключом построены, например, подписи RSA. Только владелец приватного ключа может зашифровать строку (хэш) так, что все, кто знает открытый ключ, могут это расшифровать и убедиться, что шифрование могло быть произведено только владельцем приватного (закрытого) ключа.
Хотя это формализм. В подписи неважно, какой показатель e или d считать открытым, а какой приватным в выражении e d ≡ 1 (mod φ(N)), если для закрытого ключа использовать один из них, а для открытого — второй, совместно с N. Если только как раньще, для экономии не использовался один и тот же ключ и для шифрования и для подписи, от чего впоследствии отказались.
Т.е. в RSA подпись и шифрование устроены на одинаковом принципе.
Спасибо за объяснение. Не знал этого.
Зделай по принцепу Kademlia ,Kad Network, kad
Дарья[link15], вы нас ником не обманете.