Пользователь
0,0
рейтинг
18 февраля 2015 в 14:17

Разработка → ZeroNet — Распределенные сайты через Bittorrent и Bitcoin


— Стартовое окно ZeroNet

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


ZeroNet — Что это?


ZeroNet это платформа которая позволяет:
1) Получать доступ к распределенным сайтам
2) Создавать распределенные сайты

Для доступа к сайту в этой сети требуется указать его hash адрес и перейти на него, он выглядит вот так: 13DNDkMUExRf9Xa9ogwPKqp7zyHFEqbhC2
При первом заходе на такой сайт он будет помещен на домашний экран системы и будет отображатся с нормальным именем а не с хэшем.

Как это работает?


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

После создания сайта происходит анонсирование его через DHT сеть, и создается аналог blockchain для данного сайта (для поддержки версионности).

А что происходит при просмотре сайтов?


При первом открытии сайта происходит поиск пиров в DHT сети, как только пиры найдены — начинается загрузка контента сайта с них. В дальнейшем вы будете с этими пирами в общем рое (swarm) что позволит оперативно получать обновления.

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

ZeroNet — opensource проект github.com/HelloZeroNet/ZeroNet кроме того, тут github.com/HelloZeroNet можно найти примеры всех распределенных приложений.

Как установить?


Windows
Установите Python 2.7
Установите Python ZeroMQ
Установите Python Greenlet
Установите Python Gevent
Установите Python MsgPack
Запустите start.py

Открыть в браузере 127.0.0.1:43110

Linux
apt-get install python-pip
pip install pyzmq
pip install gevent
pip install msgpack-python
Запустите python zeronet.py
Открыть в браузере 127.0.0.1:43110

Mac
brew install python-pip
sudo pip install pyzmq
sudo pip install gevent
sudo pip install msgpack-python
Запустите python zeronet.py

Открыть в браузере 127.0.0.1:43110
Shift @shifttstas
карма
52,0
рейтинг 0,0
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама

Самое читаемое Разработка

Комментарии (48)

  • +3
    И как найти нужный сайт?
  • +1
    Для примера, в сети есть простой сайт
    http://127.0.0.1:43110/1FhhawHHvgLg5LS1w3w7DxT8KJSPihG9Cv

    Это ZeroHabr
    • –1
      А если контент не статический?
      • +2
        Чуть выше привел пример — есть форум в сети, контент там не статический, кроме того есть WebRTC которые позволяют реализовать любой динамический контент.
        • 0
          Да, я видел, что упоминание об этом есть, но нет информации о реализации этого.
          • +5
            $.post(«demo.zeronet.io/ZeroBoard/add.php», {«body»: body, «auth_key»: auth_key, «hash»: hash}).always(@submittedMessage)
            • 0
              без комментариев
            • 0
              То есть мои данные будут гулять по тысячам компьютеров? перед тем как попасть на сервер? Или я чего-то не понимаю?
              • +3
                т.е. для публикации коммента на ZeroBoard, будет отправлен стандартный http (не шифрованный) запрос через стандартный tcp/ip.
                таким образом ну пути прохождения запроса будет известен не только факт вашей публикации, но и содержимое. неговоря о лёгкой блокировке возможности отправки как таковой.
                Я понимаю, что это «концепт», но он из разряда вредных. И не годится для утверждения: «сайты могут иметь динамический контент»
            • 0
              Так и какая же это распределенность, если всё равно есть сервер с форумом? Просто блокируешь адрес сервера или демонтируешь сервер ломом и всё — нету форума.
  • 0
    Если нужно сделать сайт с CMS, получается, нужно и саму CMS распространять всем вместе с сайтом? А если это будет что-то например на Django? Как тут быть? Никак?
    • 0
      Тут CMS может быть в двух вариантах:
      1) Вы генерируете статику и заливаете в сеть (аналогично Github Pages)
      2) Сайт использует динамику только через javascript (webrtc например)
  • 0
    В дополнение к этой штуке идеально бы вписаля какйо-нибудь dnsmasq
    • 0
      Может Namecoin тогда?
  • +3
    поисковик работает через вполне себе централизованный web ресурс:

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

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

    По всей видимости можно хостить только статичные сайты.
    • –1
      ZeroBoard тоже самое:
      habrahabr.ru/post/250945/#comment_8289093
      • 0
        Распределенностью здесь даже не пахнет, по сути распределен только статический контент, а данамика работает по старинке на одном сервере, который можно спокойно прикрыть. Думаю, полноценное решение было бы возможность выполнять динамику в какой-то песочнице у пользователя или возможно даже распределенно между пользователями, что конечно не очень просто.
        • 0
          Да, для динамики нужно ещё распределённую БД с авторизацией (защитой данных) и распределённый (скриптовый?) «серверный» язык. Ну, или, по крайней мере, если взять двухзвенную архитектуру с отнсительно «толстыми» JS-клиентами, то хотя бы просто распределённую БД с авторизацией и http-интерфейсом.
          • +2
            Размышления с дивана о возможной архитектуре такой БД
            Предположим, изначально база создаётся в виде базовой (файловой?) структуры, подписанной администратором БД и включающей описания в себя структуры хранимых данных и таблицу прав доступа с правами пользователей и их публичными подписями. Каждый зарегистрированный пользователь может «делать записи» в неё путём добавления записей о действиях, подписанных своей подписью — если подпись верна, то запись при чтении базы учитывается «поверх» основной (подписанной администратором) базы, если не верна — то не учитывается. Записи о заявке на регистрацию видны администратору, и он может их внести в базу путём добавления в таблицу прав доступа (кроме него никто не может, т.к. таблица входит в структуру, невалидную без его подписи). Также администратор может «аппрувить» записи в основную структуру — удалять отдельные записи, подписанные пользователями, перенося данные из них в основную подписанную структуру.
            • +2
              Мои пять копеек с дивана:
              Так же можно делать приватный контент, который хранится в БД в зашифрованном на ключе пользователя виде. Например личные сообщения можно подписывать ключём отправителя плюс шифровать ключами отправителя и получателя.
              Если при этом закрытый ключ пользователя шифровать на пароле и хранить тут же в БД, то получается возможность логиниться по паролю с любого компа, как на обычный сайт.

              • 0
                Скрытый текст
                Так же можно делать приватный контент, который хранится в БД в зашифрованном на ключе пользователя виде. Например личные сообщения можно подписывать ключём отправителя плюс шифровать ключами отправителя и получателя.
                Да, хорошая идея. Я, собственно, с чего-то похожего и начинал рассуждения, но к тому времени, как додумался до подписей и «накладных» записей — уже забыл, что изначально-то как раз собирался защитить приватные данные.
                закрытый ключ пользователя шифровать на пароле и хранить тут же в БД
                Не стоит. Это ж всё равно что хранить хэш пароля в открытом доступе.
                В общем, стоит попробовать запилить некий proof of concept на досуге.
                Похоже, ZeroTalk как-то похоже на это и работает — http-сервер, по утверждению автора, используется только для регистрации новых пользователей.
                • 0
                  закрытый ключ пользователя шифровать на пароле и хранить тут же в БД

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

                  Я согласен с тем, что решение спорное, но зато хорошие возможности :-) Если хороший пароль (например случайный 20 символов с буквами, цифрами, спецсимволами ~= 128 бит энтропии), то публикация хэша к нему не создаёт угрозы взлома или расшифрования чего-либо. Ну и это больше похоже на хранение не просто хэша, а хорошо солёного хэша в открытом виде.
                  • 0
                    хороший пароль (например случайный 20 символов с буквами, цифрами, спецсимволами ~= 128 бит энтропии)
                    Ну, такой запоминать, мне кажется, нереально для 99.9% пользователей :)
                    Немного будет любителей пользоваться паролями по 20 случайных символов, вводимых по памяти. А если всё равно копипастить, то можно и весь ключ.
                    • 0
                      Ну можно пользоваться чем-то типа www.pwdhash.com (правда надо допиливать так, что бы он за имя домена считал ID сайта в ZeroNet) Кто-то может придумывать мнемонические схемы; то, что символы будут не совсем случайными, на практике, думаю, сильно переборщикам не поможет. Для замедления перебора можно делать много итераций шифрования (так, что бы шифрование занимало ~ 1 сек на слабом компьютере).
                      И самое главное — на сколько я вижу, это единственный способ попадать в свой аккаунт с разных компов без использования аппаратных криптосредств.
                      • 0
                        Ну, учитывая, что даже у обычных сайтов пароли хэшируют с солью даже с учётом того, что сам хэш доступен только после получения доступа к скрытой базе, то это мне очень, очень, очень не нравится :(
                        Способ попадать в аккаунт с разных компов — хранить где-то в доступном только для себя месте свой ключ. На физ. носителе или где-нибудь в облаке. Или в голове.
                        В конце концов, приватный ключ же может быть любым, и даже при фиксированной длине всегда можно использовать ключ вида «00000…0000МОЙКЛЮЧ».
                        • 0
                          В конце концов, приватный ключ же может быть любым, и даже при фиксированной длине всегда можно использовать ключ вида «00000…0000МОЙКЛЮЧ».
                          Это очень плохая идея. Т.к. при работе с паролями считают что у пароля заведомо низкая энтропия (используют алгоритмы, замедляющие перебор, и т.п.). При работе с ключами считают что у них энтропия заведомо достаточно высокая и операции с ключами проектируют так, что бы получить максимальное быстродействие (c учётом защиты от атак по побочным каналам). Поэтому использование легко запоминаемого ключа — это огромная дыра. Если что-то предполагается быть запомненным, то это должен быть только пароль.
                          К тому же в асимметричной криптографии нельзя просто так взять произвольный приватный ключ, обычно их рассчитывают одновременно с публичным ключом (есть исключения).
                          Способ попадать в аккаунт с разных компов — хранить где-то в доступном только для себя месте свой ключ. На физ. носителе или где-нибудь в облаке. Или в голове.
                          На физическом носителе можно хранить и пароль и ключ. В облаке — только зашифрованный пароль или зашифрованный ключ, но нужно где-то хранить пароль, на котором они зашифрованы. В голове — только пароль. Запоминание хорошего ключа бессмысленно, т.к. проще запомнить более короткий пароль, который обеспечит ту же стойкость системы. Так что всё сводится к двум вариантам — физический носитель или хороший пароль.
                          • 0
                            Погодите, а зачем нужен пароль при наличии не выложенного в публичный доступ ни в каком виде ключа? И как пароль (короткий) может давать такую же защиту как ключ (длинный)?
                            • 0
                              Погодите, а зачем нужен пароль при наличии не выложенного в публичный доступ ни в каком виде ключа?
                              Ну если ключ доступен пользователю, то пароль не нужен. «На физическом носителе можно хранить и пароль и ключ.» — я имел ввиду что или то, или то.
                              В оффлайн приложениях пароль обычно используется для генерации симметричного ключа шифрования и процедуру генерации ключа обычно делают вычислительно сложной. Стандартное решение — считать хэш от пароля, и потом хэш от этого хэша и так N итераций, а результат использовать в качестве ключа шифрования. N можно выбрать достаточно большим: миллион, миллиард,…
                              Такой метод увеличивает затраты времени и у честного пользователя, и у нарушителя в одинаковое количество раз, но пароль вводится не часто и его ввод занимает много времени, поэтому замедление в доли секунды будет честному пользователю незаметно. Для ключей шифрования для повышения стойкости увеличивают их длину. При этом замедление перебора экспоненциально, а замедление работы честного пользователя обычно около линейного.
                              Пример: при N = 10^9 подбирающему пароль нужно будет считать хэш 10^9 ~ 2^30 раза для каждого возможного пароля. Получится что для пароля из 15 символов (~98 бит энтропии) ему нужно будет сделать ~2^128 расчётов хэша. Т.е. если мы используем дальше AES128, то перебрать пароль будет не проще, чем перебрать сам ключ шифрования, что считается нереальным. При этом для честного кодирования 128 бит нужно запоминать строку из 20 символов. В асимметричной криптографии ключи обычно на порядок длиннее. Т.е. имеем пароль из 15 символов, либо симметричный ключ (на котором зашифрован приватный ключ) из 20 символов, либо прям сам приватный ключ из 158 (1024 битв) или больше символов.
                              Но пароль из 15 символов более-менее случайного вида — это хороший пароль. Плохой пароль, конечно, ни от чего не защитит.
                              • 0
                                Но если ключ зависит только от пароля, то один раз сгенерированные «радужные таблицы» дадут сразу все ключи. Надо тогда, всё-таки, ещё и «солить».
                                • 0
                                  1) Радужные таблицы используются для поиска пароля по известному хэшу. Обычно ключ шифрования не известен, так что радужные таблицы не применимы. Если ключ известен, то всё уже можно расшифровать без радужных таблиц и пароля.
                                  Радужные таблицы и файлы
                                  В принципе некоторые форматы шифрованных файлов хранят какой-то отпечаток ключа для быстрого (чуть дольше чем генерируется ключ из пароля) определения правильности ввода пароля. Если там не соли — то можно пользоваться радужными таблицами. Но обычно там соль есть и по сути хранение такого отпечатка не обязательно, можно обходиться без него. А если мы шифруем свой приватный ключ, то там такой отпечаток совсем не нужен.

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

                                  Если имеется ввиду, что можно сгенерировать всё множество ключей, которые могут быть получены из 15-ти символьных паролей, то тут не радужные таблицы, а просто огромный список ключей будет. Тут пункт 1) не действует, а пункты 2) и 3) актуальны. Может правда есть смысл солить.
                                  • 0
                                    Для генерации радужных таблиц потребуется времени строго больше чем для перебора 2^128 ключей (если брать цифры из моего примера выше), что делает их генерацию нереальной.
                                    Если генерация ключа — это что-то типа хэша от хэша от… от хэша пароля, то нет — делаем таблицу хэшей всех возможных паролей, а затем таблицу хэшей всех хэшей. Всё, две таблицы. В Вики расписано, кстати.
                                    • 0
                                      Да, тут это будет работать, вы правы :-)
                                      Изначально я имел ввиду другую схему с многократным шифрованием
                                      типа того:

                                      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 битной хэш-функции.
                                      Естественно, это всё на уровне «размышлений на диване» ;-)
  • 0
    предвижу создание в скором времени ZeroDNS
  • 0
    freenet?
  • 0
    Работает шустренько :-) Даже сайт на 166 Мб есть.
    Хорошо бы это в виде плагина к браузеру сделать (понятно, что это может быть на далёкую перспективу)
  • +1
    Это как гипертекстовый фидонет? Чтобы посмотрели другие, надо сначала всё скачать самому, даже то что не нужно?
  • 0
    Есть прокси из обычного инета: zero.network
    Кроме поисковика есть индекс сайтов: 1JF4oezBUFMCbbct1uUnXHf4y3W3grUsXP
    • 0
      Правда если смотреть через эту прокси, то в ZeroTalk последние сообщения не показываются… Не успевает она обновляться похоже.
  • 0
    Однако! А на какой стадии разработчики определяют свой проект по степени завершенности?
  • 0
    Я правильно понимаю, что это революция и появление чего-то сопоставимого с самим интернетом? По крайней мере, пока не было динамических сайтов, это была всего лишь милая поделка. А сейчас, похоже, начинается самое интересное.
    • 0
      см. выше. вся динамика через tcp/ip
  • 0
    Блин, еще один пункт из своей тетради «идеи настолько гениальные, что с их реализацией можно повременить» придется вычеркнуть.
    Авторам — респект и моя поддержка на гитхабе, автору статьи — большое спасибо!
  • 0
    Вот тут уже, вроде, научились делать приложения в блокчейне:
    bitcointalk.org/index.php?topic=345882.msg9573397#msg9573397 и пару сообщений ниже есть подробнее.
  • 0
    А мне нравится идея которую сделали разработчики в utorrent 3.4
    Пользователю всего лишь нужно поставить торрент-клиент и больше ничего, весь загружаемый через p2p контент можно просматривать в любом обычном браузере. Можно даже самому некое подобие http сайта слепить и раздавать его utorrent если есть статический IP или же если белый динамический (тогда возможно поможет услуга no-ip или ей подобные). Контент можно загружать как с p2p так и с обычных http сайтов.

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