Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 48
И как найти нужный сайт?
Сейчас в сети есть поисковик http://127.0.0.1:43110/1ZeroeuDnL2jNS6t1epQa1SPvC91KG8ER
Для примера, в сети есть простой сайт
http://127.0.0.1:43110/1FhhawHHvgLg5LS1w3w7DxT8KJSPihG9Cv
Это ZeroHabr
http://127.0.0.1:43110/1FhhawHHvgLg5LS1w3w7DxT8KJSPihG9Cv
Это ZeroHabr
А если контент не статический?
Чуть выше привел пример — есть форум в сети, контент там не статический, кроме того есть WebRTC которые позволяют реализовать любой динамический контент.
Да, я видел, что упоминание об этом есть, но нет информации о реализации этого.
$.post(«demo.zeronet.io/ZeroBoard/add.php», {«body»: body, «auth_key»: auth_key, «hash»: hash}).always(@submittedMessage)
без комментариев
То есть мои данные будут гулять по тысячам компьютеров? перед тем как попасть на сервер? Или я чего-то не понимаю?
т.е. для публикации коммента на ZeroBoard, будет отправлен стандартный http (не шифрованный) запрос через стандартный tcp/ip.
таким образом ну пути прохождения запроса будет известен не только факт вашей публикации, но и содержимое. неговоря о лёгкой блокировке возможности отправки как таковой.
Я понимаю, что это «концепт», но он из разряда вредных. И не годится для утверждения: «сайты могут иметь динамический контент»
таким образом ну пути прохождения запроса будет известен не только факт вашей публикации, но и содержимое. неговоря о лёгкой блокировке возможности отправки как таковой.
Я понимаю, что это «концепт», но он из разряда вредных. И не годится для утверждения: «сайты могут иметь динамический контент»
Так и какая же это распределенность, если всё равно есть сервер с форумом? Просто блокируешь адрес сервера или демонтируешь сервер ломом и всё — нету форума.
Если нужно сделать сайт с CMS, получается, нужно и саму CMS распространять всем вместе с сайтом? А если это будет что-то например на Django? Как тут быть? Никак?
В дополнение к этой штуке идеально бы вписаля какйо-нибудь dnsmasq
поисковик работает через вполне себе централизованный web ресурс:
127.0.0.1:43110/media/1ZeroeuDnL2jNS6t1epQa1SPvC91KG8ER/index.html
39: xmlhttp.open(«POST»,«zeronetproxy.tk/zeronet/zerosearch/add.php»,true);
По всей видимости можно хостить только статичные сайты.
127.0.0.1:43110/media/1ZeroeuDnL2jNS6t1epQa1SPvC91KG8ER/index.html
39: xmlhttp.open(«POST»,«zeronetproxy.tk/zeronet/zerosearch/add.php»,true);
По всей видимости можно хостить только статичные сайты.
ZeroBoard тоже самое:
habrahabr.ru/post/250945/#comment_8289093
habrahabr.ru/post/250945/#comment_8289093
Распределенностью здесь даже не пахнет, по сути распределен только статический контент, а данамика работает по старинке на одном сервере, который можно спокойно прикрыть. Думаю, полноценное решение было бы возможность выполнять динамику в какой-то песочнице у пользователя или возможно даже распределенно между пользователями, что конечно не очень просто.
Да, для динамики нужно ещё распределённую БД с авторизацией (защитой данных) и распределённый (скриптовый?) «серверный» язык. Ну, или, по крайней мере, если взять двухзвенную архитектуру с отнсительно «толстыми» JS-клиентами, то хотя бы просто распределённую БД с авторизацией и http-интерфейсом.
Размышления с дивана о возможной архитектуре такой БД
Предположим, изначально база создаётся в виде базовой (файловой?) структуры, подписанной администратором БД и включающей описания в себя структуры хранимых данных и таблицу прав доступа с правами пользователей и их публичными подписями. Каждый зарегистрированный пользователь может «делать записи» в неё путём добавления записей о действиях, подписанных своей подписью — если подпись верна, то запись при чтении базы учитывается «поверх» основной (подписанной администратором) базы, если не верна — то не учитывается. Записи о заявке на регистрацию видны администратору, и он может их внести в базу путём добавления в таблицу прав доступа (кроме него никто не может, т.к. таблица входит в структуру, невалидную без его подписи). Также администратор может «аппрувить» записи в основную структуру — удалять отдельные записи, подписанные пользователями, перенося данные из них в основную подписанную структуру.
Мои пять копеек с дивана:
Так же можно делать приватный контент, который хранится в БД в зашифрованном на ключе пользователя виде. Например личные сообщения можно подписывать ключём отправителя плюс шифровать ключами отправителя и получателя.
Если при этом закрытый ключ пользователя шифровать на пароле и хранить тут же в БД, то получается возможность логиниться по паролю с любого компа, как на обычный сайт.
Если при этом закрытый ключ пользователя шифровать на пароле и хранить тут же в БД, то получается возможность логиниться по паролю с любого компа, как на обычный сайт.
Скрытый текст
Так же можно делать приватный контент, который хранится в БД в зашифрованном на ключе пользователя виде. Например личные сообщения можно подписывать ключём отправителя плюс шифровать ключами отправителя и получателя.Да, хорошая идея. Я, собственно, с чего-то похожего и начинал рассуждения, но к тому времени, как додумался до подписей и «накладных» записей — уже забыл, что изначально-то как раз собирался защитить приватные данные.
закрытый ключ пользователя шифровать на пароле и хранить тут же в БДНе стоит. Это ж всё равно что хранить хэш пароля в открытом доступе.
Похоже, ZeroTalk как-то похоже на это и работает — http-сервер, по утверждению автора, используется только для регистрации новых пользователей.
закрытый ключ пользователя шифровать на пароле и хранить тут же в БД
Не стоит. Это ж всё равно что хранить хэш пароля в открытом доступе.
Я согласен с тем, что решение спорное, но зато хорошие возможности :-) Если хороший пароль (например случайный 20 символов с буквами, цифрами, спецсимволами ~= 128 бит энтропии), то публикация хэша к нему не создаёт угрозы взлома или расшифрования чего-либо. Ну и это больше похоже на хранение не просто хэша, а хорошо солёного хэша в открытом виде.
хороший пароль (например случайный 20 символов с буквами, цифрами, спецсимволами ~= 128 бит энтропии)Ну, такой запоминать, мне кажется, нереально для 99.9% пользователей :)
Немного будет любителей пользоваться паролями по 20 случайных символов, вводимых по памяти. А если всё равно копипастить, то можно и весь ключ.
Ну можно пользоваться чем-то типа www.pwdhash.com (правда надо допиливать так, что бы он за имя домена считал ID сайта в ZeroNet) Кто-то может придумывать мнемонические схемы; то, что символы будут не совсем случайными, на практике, думаю, сильно переборщикам не поможет. Для замедления перебора можно делать много итераций шифрования (так, что бы шифрование занимало ~ 1 сек на слабом компьютере).
И самое главное — на сколько я вижу, это единственный способ попадать в свой аккаунт с разных компов без использования аппаратных криптосредств.
И самое главное — на сколько я вижу, это единственный способ попадать в свой аккаунт с разных компов без использования аппаратных криптосредств.
Ну, учитывая, что даже у обычных сайтов пароли хэшируют с солью даже с учётом того, что сам хэш доступен только после получения доступа к скрытой базе, то это мне очень, очень, очень не нравится :(
Способ попадать в аккаунт с разных компов — хранить где-то в доступном только для себя месте свой ключ. На физ. носителе или где-нибудь в облаке. Или в голове.
В конце концов, приватный ключ же может быть любым, и даже при фиксированной длине всегда можно использовать ключ вида «00000…0000МОЙКЛЮЧ».
Способ попадать в аккаунт с разных компов — хранить где-то в доступном только для себя месте свой ключ. На физ. носителе или где-нибудь в облаке. Или в голове.
В конце концов, приватный ключ же может быть любым, и даже при фиксированной длине всегда можно использовать ключ вида «00000…0000МОЙКЛЮЧ».
В конце концов, приватный ключ же может быть любым, и даже при фиксированной длине всегда можно использовать ключ вида «00000…0000МОЙКЛЮЧ».Это очень плохая идея. Т.к. при работе с паролями считают что у пароля заведомо низкая энтропия (используют алгоритмы, замедляющие перебор, и т.п.). При работе с ключами считают что у них энтропия заведомо достаточно высокая и операции с ключами проектируют так, что бы получить максимальное быстродействие (c учётом защиты от атак по побочным каналам). Поэтому использование легко запоминаемого ключа — это огромная дыра. Если что-то предполагается быть запомненным, то это должен быть только пароль.
К тому же в асимметричной криптографии нельзя просто так взять произвольный приватный ключ, обычно их рассчитывают одновременно с публичным ключом (есть исключения).
Способ попадать в аккаунт с разных компов — хранить где-то в доступном только для себя месте свой ключ. На физ. носителе или где-нибудь в облаке. Или в голове.На физическом носителе можно хранить и пароль и ключ. В облаке — только зашифрованный пароль или зашифрованный ключ, но нужно где-то хранить пароль, на котором они зашифрованы. В голове — только пароль. Запоминание хорошего ключа бессмысленно, т.к. проще запомнить более короткий пароль, который обеспечит ту же стойкость системы. Так что всё сводится к двум вариантам — физический носитель или хороший пароль.
Погодите, а зачем нужен пароль при наличии не выложенного в публичный доступ ни в каком виде ключа? И как пароль (короткий) может давать такую же защиту как ключ (длинный)?
Погодите, а зачем нужен пароль при наличии не выложенного в публичный доступ ни в каком виде ключа?Ну если ключ доступен пользователю, то пароль не нужен. «На физическом носителе можно хранить и пароль и ключ.» — я имел ввиду что или то, или то.
В оффлайн приложениях пароль обычно используется для генерации симметричного ключа шифрования и процедуру генерации ключа обычно делают вычислительно сложной. Стандартное решение — считать хэш от пароля, и потом хэш от этого хэша и так N итераций, а результат использовать в качестве ключа шифрования. N можно выбрать достаточно большим: миллион, миллиард,…
Такой метод увеличивает затраты времени и у честного пользователя, и у нарушителя в одинаковое количество раз, но пароль вводится не часто и его ввод занимает много времени, поэтому замедление в доли секунды будет честному пользователю незаметно. Для ключей шифрования для повышения стойкости увеличивают их длину. При этом замедление перебора экспоненциально, а замедление работы честного пользователя обычно около линейного.
Пример: при N = 10^9 подбирающему пароль нужно будет считать хэш 10^9 ~ 2^30 раза для каждого возможного пароля. Получится что для пароля из 15 символов (~98 бит энтропии) ему нужно будет сделать ~2^128 расчётов хэша. Т.е. если мы используем дальше AES128, то перебрать пароль будет не проще, чем перебрать сам ключ шифрования, что считается нереальным. При этом для честного кодирования 128 бит нужно запоминать строку из 20 символов. В асимметричной криптографии ключи обычно на порядок длиннее. Т.е. имеем пароль из 15 символов, либо симметричный ключ (на котором зашифрован приватный ключ) из 20 символов, либо прям сам приватный ключ из 158 (1024 битв) или больше символов.
Но пароль из 15 символов более-менее случайного вида — это хороший пароль. Плохой пароль, конечно, ни от чего не защитит.
Но если ключ зависит только от пароля, то один раз сгенерированные «радужные таблицы» дадут сразу все ключи. Надо тогда, всё-таки, ещё и «солить».
1) Радужные таблицы используются для поиска пароля по известному хэшу. Обычно ключ шифрования не известен, так что радужные таблицы не применимы. Если ключ известен, то всё уже можно расшифровать без радужных таблиц и пароля.
2) Для генерации радужных таблиц потребуется времени строго больше чем для перебора 2^128 ключей (если брать цифры из моего примера выше), что делает их генерацию нереальной.
3) Если надо солить — то кто против? ;-)
Если имеется ввиду, что можно сгенерировать всё множество ключей, которые могут быть получены из 15-ти символьных паролей, то тут не радужные таблицы, а просто огромный список ключей будет. Тут пункт 1) не действует, а пункты 2) и 3) актуальны. Может правда есть смысл солить.
Радужные таблицы и файлы
В принципе некоторые форматы шифрованных файлов хранят какой-то отпечаток ключа для быстрого (чуть дольше чем генерируется ключ из пароля) определения правильности ввода пароля. Если там не соли — то можно пользоваться радужными таблицами. Но обычно там соль есть и по сути хранение такого отпечатка не обязательно, можно обходиться без него. А если мы шифруем свой приватный ключ, то там такой отпечаток совсем не нужен.
2) Для генерации радужных таблиц потребуется времени строго больше чем для перебора 2^128 ключей (если брать цифры из моего примера выше), что делает их генерацию нереальной.
3) Если надо солить — то кто против? ;-)
Если имеется ввиду, что можно сгенерировать всё множество ключей, которые могут быть получены из 15-ти символьных паролей, то тут не радужные таблицы, а просто огромный список ключей будет. Тут пункт 1) не действует, а пункты 2) и 3) актуальны. Может правда есть смысл солить.
Для генерации радужных таблиц потребуется времени строго больше чем для перебора 2^128 ключей (если брать цифры из моего примера выше), что делает их генерацию нереальной.Если генерация ключа — это что-то типа хэша от хэша от… от хэша пароля, то нет — делаем таблицу хэшей всех возможных паролей, а затем таблицу хэшей всех хэшей. Всё, две таблицы. В Вики расписано, кстати.
Да, тут это будет работать, вы правы :-)
Изначально я имел ввиду другую схему с многократным шифрованием
типа того:
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 битной хэш-функции.
Естественно, это всё на уровне «размышлений на диване» ;-)
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 битной хэш-функции.
Естественно, это всё на уровне «размышлений на диване» ;-)
предвижу создание в скором времени ZeroDNS
freenet?
Работает шустренько :-) Даже сайт на 166 Мб есть.
Хорошо бы это в виде плагина к браузеру сделать (понятно, что это может быть на далёкую перспективу)
Хорошо бы это в виде плагина к браузеру сделать (понятно, что это может быть на далёкую перспективу)
Это как гипертекстовый фидонет? Чтобы посмотрели другие, надо сначала всё скачать самому, даже то что не нужно?
Есть прокси из обычного инета: zero.network
Кроме поисковика есть индекс сайтов: 1JF4oezBUFMCbbct1uUnXHf4y3W3grUsXP
Кроме поисковика есть индекс сайтов: 1JF4oezBUFMCbbct1uUnXHf4y3W3grUsXP
Однако! А на какой стадии разработчики определяют свой проект по степени завершенности?
Я правильно понимаю, что это революция и появление чего-то сопоставимого с самим интернетом? По крайней мере, пока не было динамических сайтов, это была всего лишь милая поделка. А сейчас, похоже, начинается самое интересное.
Блин, еще один пункт из своей тетради «идеи настолько гениальные, что с их реализацией можно повременить» придется вычеркнуть.
Авторам — респект и моя поддержка на гитхабе, автору статьи — большое спасибо!
Авторам — респект и моя поддержка на гитхабе, автору статьи — большое спасибо!
Вот тут уже, вроде, научились делать приложения в блокчейне:
bitcointalk.org/index.php?topic=345882.msg9573397#msg9573397 и пару сообщений ниже есть подробнее.
bitcointalk.org/index.php?topic=345882.msg9573397#msg9573397 и пару сообщений ниже есть подробнее.
А мне нравится идея которую сделали разработчики в utorrent 3.4
Пользователю всего лишь нужно поставить торрент-клиент и больше ничего, весь загружаемый через p2p контент можно просматривать в любом обычном браузере. Можно даже самому некое подобие http сайта слепить и раздавать его utorrent если есть статический IP или же если белый динамический (тогда возможно поможет услуга no-ip или ей подобные). Контент можно загружать как с p2p так и с обычных http сайтов.
Пользователю всего лишь нужно поставить торрент-клиент и больше ничего, весь загружаемый через p2p контент можно просматривать в любом обычном браузере. Можно даже самому некое подобие http сайта слепить и раздавать его utorrent если есть статический IP или же если белый динамический (тогда возможно поможет услуга no-ip или ей подобные). Контент можно загружать как с p2p так и с обычных http сайтов.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
ZeroNet — Распределенные сайты через Bittorrent и Bitcoin