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

fogone Feb 18 2015 at 16:07

Да, я видел, что упоминание об этом есть, но нет информации о реализации этого.

Guria Feb 18 2015 at 19:38

$.post(«demo.zeronet.io/ZeroBoard/add.php», {«body»: body, «auth_key»: auth_key, «hash»: hash}).always(@submittedMessage)

Guria Feb 18 2015 at 19:39

без комментариев

fr33z3 Feb 18 2015 at 22:08

То есть мои данные будут гулять по тысячам компьютеров? перед тем как попасть на сервер? Или я чего-то не понимаю?

Guria Feb 18 2015 at 23:55

т.е. для публикации коммента на ZeroBoard, будет отправлен стандартный http (не шифрованный) запрос через стандартный tcp/ip.
таким образом ну пути прохождения запроса будет известен не только факт вашей публикации, но и содержимое. неговоря о лёгкой блокировке возможности отправки как таковой.
Я понимаю, что это «концепт», но он из разряда вредных. И не годится для утверждения: «сайты могут иметь динамический контент»

fogone Feb 19 2015 at 12:00

Так и какая же это распределенность, если всё равно есть сервер с форумом? Просто блокируешь адрес сервера или демонтируешь сервер ломом и всё — нету форума.

ZoomLS Feb 18 2015 at 14:45

Если нужно сделать сайт с CMS, получается, нужно и саму CMS распространять всем вместе с сайтом? А если это будет что-то например на Django? Как тут быть? Никак?

shifttstas Feb 18 2015 at 15:05

Тут CMS может быть в двух вариантах:
1) Вы генерируете статику и заливаете в сеть (аналогично Github Pages)
2) Сайт использует динамику только через javascript (webrtc например)

kolpeex Feb 18 2015 at 20:04

В дополнение к этой штуке идеально бы вписаля какйо-нибудь dnsmasq

fshp Feb 19 2015 at 09:58

Может Namecoin тогда?

Flash_X Feb 18 2015 at 20:41

поисковик работает через вполне себе централизованный web ресурс:

127.0.0.1:43110/media/1ZeroeuDnL2jNS6t1epQa1SPvC91KG8ER/index.html

39: xmlhttp.open(«POST»,«zeronetproxy.tk/zeronet/zerosearch/add.php»,true);

По всей видимости можно хостить только статичные сайты.

Guria Feb 18 2015 at 23:56

ZeroBoard тоже самое:
habrahabr.ru/post/250945/#comment_8289093

-1

fogone Feb 19 2015 at 12:08

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

Chamie Feb 19 2015 at 16:58

Да, для динамики нужно ещё распределённую БД с авторизацией (защитой данных) и распределённый (скриптовый?) «серверный» язык. Ну, или, по крайней мере, если взять двухзвенную архитектуру с отнсительно «толстыми» JS-клиентами, то хотя бы просто распределённую БД с авторизацией и http-интерфейсом.

Chamie Feb 19 2015 at 17:12

Размышления с дивана о возможной архитектуре такой БД

Предположим, изначально база создаётся в виде базовой (файловой?) структуры, подписанной администратором БД и включающей описания в себя структуры хранимых данных и таблицу прав доступа с правами пользователей и их публичными подписями. Каждый зарегистрированный пользователь может «делать записи» в неё путём добавления записей о действиях, подписанных своей подписью — если подпись верна, то запись при чтении базы учитывается «поверх» основной (подписанной администратором) базы, если не верна — то не учитывается. Записи о заявке на регистрацию видны администратору, и он может их внести в базу путём добавления в таблицу прав доступа (кроме него никто не может, т.к. таблица входит в структуру, невалидную без его подписи). Также администратор может «аппрувить» записи в основную структуру — удалять отдельные записи, подписанные пользователями, перенося данные из них в основную подписанную структуру.

Nokta_strigo Feb 19 2015 at 23:31

Мои пять копеек с дивана:

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

Chamie Feb 21 2015 at 02:05

Скрытый текст

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

Да, хорошая идея. Я, собственно, с чего-то похожего и начинал рассуждения, но к тому времени, как додумался до подписей и «накладных» записей — уже забыл, что изначально-то как раз собирался защитить приватные данные.

закрытый ключ пользователя шифровать на пароле и хранить тут же в БД

Не стоит. Это ж всё равно что хранить хэш пароля в открытом доступе.

~~В общем, стоит попробовать запилить некий proof of concept на досуге.~~
Похоже, ZeroTalk как-то похоже на это и работает — http-сервер, по утверждению автора, используется только для регистрации новых пользователей.

Nokta_strigo Feb 21 2015 at 22:15

закрытый ключ пользователя шифровать на пароле и хранить тут же в БД

Не стоит. Это ж всё равно что хранить хэш пароля в открытом доступе.

Я согласен с тем, что решение спорное, но зато хорошие возможности :-) Если хороший пароль (например случайный 20 символов с буквами, цифрами, спецсимволами ~= 128 бит энтропии), то публикация хэша к нему не создаёт угрозы взлома или расшифрования чего-либо. Ну и это больше похоже на хранение не просто хэша, а хорошо солёного хэша в открытом виде.

Chamie Feb 23 2015 at 01:44

хороший пароль (например случайный 20 символов с буквами, цифрами, спецсимволами ~= 128 бит энтропии)

Ну, такой запоминать, мне кажется, нереально для 99.9% пользователей :)
Немного будет любителей пользоваться паролями по 20 случайных символов, вводимых по памяти. А если всё равно копипастить, то можно и весь ключ.

Nokta_strigo Feb 23 2015 at 02:32

Ну можно пользоваться чем-то типа www.pwdhash.com (правда надо допиливать так, что бы он за имя домена считал ID сайта в ZeroNet) Кто-то может придумывать мнемонические схемы; то, что символы будут не совсем случайными, на практике, думаю, сильно переборщикам не поможет. Для замедления перебора можно делать много итераций шифрования (так, что бы шифрование занимало ~ 1 сек на слабом компьютере).
И самое главное — на сколько я вижу, это единственный способ попадать в свой аккаунт с разных компов без использования аппаратных криптосредств.

Chamie Feb 23 2015 at 02:54

Ну, учитывая, что даже у обычных сайтов пароли хэшируют с солью даже с учётом того, что сам хэш доступен только после получения доступа к скрытой базе, то это мне очень, очень, очень не нравится :(
Способ попадать в аккаунт с разных компов — хранить где-то в доступном только для себя месте свой ключ. На физ. носителе или где-нибудь в облаке. Или в голове.
В конце концов, приватный ключ же может быть любым, и даже при фиксированной длине всегда можно использовать ключ вида «00000…0000МОЙКЛЮЧ».

Nokta_strigo Feb 23 2015 at 19:55

В конце концов, приватный ключ же может быть любым, и даже при фиксированной длине всегда можно использовать ключ вида «00000…0000МОЙКЛЮЧ».

Это очень плохая идея. Т.к. при работе с паролями считают что у пароля заведомо низкая энтропия (используют алгоритмы, замедляющие перебор, и т.п.). При работе с ключами считают что у них энтропия заведомо достаточно высокая и операции с ключами проектируют так, что бы получить максимальное быстродействие_{(c учётом защиты от атак по побочным каналам)}. Поэтому использование легко запоминаемого ключа — это огромная дыра. Если что-то предполагается быть запомненным, то это должен быть только пароль.
К тому же в асимметричной криптографии нельзя просто так взять произвольный приватный ключ, обычно их рассчитывают одновременно с публичным ключом (есть исключения).

Способ попадать в аккаунт с разных компов — хранить где-то в доступном только для себя месте свой ключ. На физ. носителе или где-нибудь в облаке. Или в голове.

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

Chamie Feb 23 2015 at 22:05

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

Nokta_strigo Feb 24 2015 at 00:16

Погодите, а зачем нужен пароль при наличии не выложенного в публичный доступ ни в каком виде ключа?

Ну если ключ доступен пользователю, то пароль не нужен. «На физическом носителе можно хранить и пароль и ключ.» — я имел ввиду что или то, или то.
В оффлайн приложениях пароль обычно используется для генерации симметричного ключа шифрования и процедуру генерации ключа обычно делают вычислительно сложной. Стандартное решение — считать хэш от пароля, и потом хэш от этого хэша и так N итераций, а результат использовать в качестве ключа шифрования. N можно выбрать достаточно большим: миллион, миллиард,…
Такой метод увеличивает затраты времени и у честного пользователя, и у нарушителя в одинаковое количество раз, но пароль вводится не часто и его ввод занимает много времени, поэтому замедление в доли секунды будет честному пользователю незаметно. Для ключей шифрования для повышения стойкости увеличивают их длину. При этом замедление перебора экспоненциально, а замедление работы честного пользователя обычно около линейного.
Пример: при N = 10^9 подбирающему пароль нужно будет считать хэш 10^9 ~ 2^30 раза для каждого возможного пароля. Получится что для пароля из 15 символов (~98 бит энтропии) ему нужно будет сделать ~2^128 расчётов хэша. Т.е. если мы используем дальше AES128, то перебрать пароль будет не проще, чем перебрать сам ключ шифрования, что считается нереальным. При этом для честного кодирования 128 бит нужно запоминать строку из 20 символов. В асимметричной криптографии ключи обычно на порядок длиннее. Т.е. имеем пароль из 15 символов, либо симметричный ключ (на котором зашифрован приватный ключ) из 20 символов, либо прям сам приватный ключ из 158 (1024 битв) или больше символов.
Но пароль из 15 символов более-менее случайного вида — это хороший пароль. Плохой пароль, конечно, ни от чего не защитит.

Chamie Feb 24 2015 at 02:06

Но если ключ зависит только от пароля, то один раз сгенерированные «радужные таблицы» дадут сразу все ключи. Надо тогда, всё-таки, ещё и «солить».

Nokta_strigo Feb 24 2015 at 02:27

1) Радужные таблицы используются для поиска пароля по известному хэшу. Обычно ключ шифрования не известен, так что радужные таблицы не применимы. Если ключ известен, то всё уже можно расшифровать без радужных таблиц и пароля.

Радужные таблицы и файлы

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

2) Для генерации радужных таблиц потребуется времени строго больше чем для перебора 2^128 ключей (если брать цифры из моего примера выше), что делает их генерацию нереальной.
3) Если надо солить — то кто против? ;-)

Если имеется ввиду, что можно сгенерировать всё множество ключей, которые могут быть получены из 15-ти символьных паролей, то тут не радужные таблицы, а просто огромный список ключей будет. Тут пункт 1) не действует, а пункты 2) и 3) актуальны. Может правда есть смысл солить.

Chamie Feb 24 2015 at 02:49

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

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

Nokta_strigo Feb 24 2015 at 03:32

Да, тут это будет работать, вы правы :-)

Изначально я имел ввиду другую схему с многократным шифрованием

типа того:

for i from 1 to N
s[i] = enc(hash(password || i), s[i-1])

s[0] = private_key (который надо зашифровать),
s[N] — шифрованный приватный ключ, который публикуется,
enc(key, M) — блочный шифр в режиме counter mode (или другом без инициализационного вектора)
|| — конкатенация строк.
Для расшифрования всё делается в обратном порядке.
Такая схема лучше чем с хэшами тем что:
1) на каждой итерации требуется пароль (не получится такая штука с двумя таблицами)
2) в схеме с хэшами вообще даже если использовать огромные пароли, при очень большом кол-ве итераций хэширования (порядка корня из множества значений хэша) множество ключей будет вырождаться в некоторое подмножество значений хэша (опять же порядка корня из множества значений хэша). Правда это лечится использованием 512 битной хэш-функции.
Естественно, это всё на уровне «размышлений на диване» ;-)

bagger Feb 18 2015 at 21:28

предвижу создание в скором времени ZeroDNS

farcaller Feb 18 2015 at 22:07

Namecoin?

dna Feb 18 2015 at 21:47

freenet?

Nokta_strigo Feb 18 2015 at 22:34

Работает шустренько :-) Даже сайт на 166 Мб есть.
Хорошо бы это в виде плагина к браузеру сделать (понятно, что это может быть на далёкую перспективу)

DjOnline Feb 19 2015 at 00:51

Это как гипертекстовый фидонет? Чтобы посмотрели другие, надо сначала всё скачать самому, даже то что не нужно?

Nokta_strigo Feb 19 2015 at 01:51

Есть прокси из обычного инета: zero.network
Кроме поисковика есть индекс сайтов: 1JF4oezBUFMCbbct1uUnXHf4y3W3grUsXP

Nokta_strigo Feb 19 2015 at 02:08

Правда если смотреть через эту прокси, то в ZeroTalk последние сообщения не показываются… Не успевает она обновляться похоже.

MiXaiL27 Feb 19 2015 at 10:09

Однако! А на какой стадии разработчики определяют свой проект по степени завершенности?

Zardos Feb 19 2015 at 11:51

Я правильно понимаю, что это революция и появление чего-то сопоставимого с самим интернетом? По крайней мере, пока не было динамических сайтов, это была всего лишь милая поделка. А сейчас, похоже, начинается самое интересное.

Guria Feb 19 2015 at 12:03

см. выше. вся динамика через tcp/ip

xni Feb 19 2015 at 23:35

Блин, еще один пункт из своей тетради «идеи настолько гениальные, что с их реализацией можно повременить» придется вычеркнуть.
Авторам — респект и моя поддержка на гитхабе, автору статьи — большое спасибо!

shaytan Feb 20 2015 at 10:12

Вот тут уже, вроде, научились делать приложения в блокчейне:
bitcointalk.org/index.php?topic=345882.msg9573397#msg9573397 и пару сообщений ниже есть подробнее.

grey_rat Feb 20 2015 at 18:23

А мне нравится идея которую сделали разработчики в utorrent 3.4
Пользователю всего лишь нужно поставить торрент-клиент и больше ничего, весь загружаемый через p2p контент можно просматривать в любом обычном браузере. Можно даже самому некое подобие http сайта слепить и раздавать его utorrent если есть статический IP или же если белый динамический (тогда возможно поможет услуга no-ip или ей подобные). Контент можно загружать как с p2p так и с обычных http сайтов.

utkorose Apr 24 2015 at 07:52

можно ссылку?

grey_rat Apr 26 2015 at 11:09

habrahabr.ru/post/251625

Show the best of all time