Нет, похоже, это Вы не понимаете, что предлагаете просто вложить в эту систему готовую DDoS атаку на саму себя.
Даже DHT-запросы в торрент-клиентах вызывают кратковременные сетевые штормы. Но они затрагивают только каналы связи, а не клиентские машины, т.к. вычисление хешей даже по SHA-1 - достаточно легковесная процедура.
А вот аутентификация по открытому ключу - это уже серьезно будет нагружать компьютеры и устройства пользователей. И это будет работать примерно так:
Алиса хочет связаться с Бобом, но не знает его адреса.
Алиса посылает запрос "Где Боб" Кэрол и Тренту, удостоверив его своей цифровой подписью (эту нагрузку пока что можно игнорировать).
Но Кэрол и Трент уже забыли, кто такая Алиса (не имеют её публичного ключа).
Они начинают рассылать запросы "Кто такая Алиса?" по всем своим знакомым, подписывая своей ЭЦП (вот появилась первая нагрузка на промежуточные узлы).
Знакомые, допустим, знают Кэрол и Трента (имеют их публичные ключи). Но чтобы убедиться, что сообщение пришло от них, должны расшифровать их ЭЦП и удостовериться в их целостности и непротиворечивости.
Допустим, они знают Алису и могут сообщить Кэрол и Тренту ее публичный ключ.
Кэрол и Трент, слегка успокоившись, приступают к обработке запроса Алисы.
Но они тоже не знают, где Боб. Так что поиск с шифрованием/расшифровыванием запросов продолжается.
В конце концов TTL первоначального запроса исчерпывается или все же находится кто-то, кто знает и где Боб и запрашивающего.
Тогда он отвечает и отправляет ответ обратно, подписывая своей ЭЦП.
Ответ проходит уже без поиска пути назначения, но всё равно узлам по всей цепочке надо удостовериться, что информация пришла от того, от кого надо. Т.е. опять тягомотина с расшифровыванием и шифрованием.
Наконец, информация о Бобе приходит к Алисе.
Та, радостная, шлет ему сакраментальное "Hello Bob!"
Но Боб тоже успел забыть, кто такая Алиса.
И шлет по всем своим знакомым запрос "Who is fu***ng Alice?"
Достаточно знать сам хеш пароля. А он уже будет известен.
Обычно де при аутентификации передается пара (логин, хеш пароля). Но этот метод уязвим перед "атакой повтором". Перехватив один раз передаваемый хеш, можно затем передавать самому.
Для противодействия этому применяют динамическое соление. Каждый раз, при аутентификации клиенту передается некая случайеая "соль". Она дописывается к хешу пароля м снова хешируется. При получении такого двойного хеша сервер тоже берет хранимый хеш пароля, дописывает к нему "соль", если она еще не "протухла" и снова хеширует. Потом сравнивает с тем, что пришло.
Т.е. таким образом передается всегда разный хеш. Это помогает от перехвата.
Но не помогает, если тот-кого-нельзя-называть получит доступ к устройству с хранящимся несолёным хешем пароля.
Вот попадает устройство, являющееся DHT-узлом в руки того-кого-нельзя-называть. А в этом устройстве куча логинов и парольных хешей.
Тот-кого-нельзя-называть копирует парольную пару и использует её для входа под чужим логином.
И всякие ухищрения, типа динамического соления, не помогают, потому что они затрудняют подбор пароля при перехвате хеша. А здесь ничего не перехватывается а просто задаром получается несолёный хеш.
И чем больше устройств в сети, тем больше вероятность того, что одно из них взломают.
А то нашему Самсунгу узе 15 лет. AVI он нормально воспроизводит, кроме "битых". А вот MKV не все. А медиацентр домосборный, слабенький - не хватает ему мощи "на лету" перекодировать форматы. Начинаются фризы на тяжелых фильмах.
Хочу всеядный, с DLNA и чтобы с веб-интерфейсом. А у LG его нет :( Или я не нашел.
А ведь раньше, до того как продаться мелкомягким, Skype использовал гибридную децентрализованную систему.
Т.е. центральных серверов не было, но некоторые мощные клиенты могли взять на себя функции супернод - координационных узлов. Они выполняли роли STUN-серверов, а при необходимости пропускали через себя трафик других клиентов (TURN).
Так что, распределенные сети мессенджеров - это уже было.
Дык, бутстрап содержит список официальных агрегаторов - резервирование на случай перебоев доступа.
А товарищимайоры делают фейковые агрегаторы (как IKnowWhatYouDownload), чтобы ловить участников поиска (иначе без поиска это уже не DHT-сеть). А при необходимости эти фейковые агрегаторы начинают выдавать пургу, затрудняя или совсем задудосивая поиск).
Вспомнил еще казус, к делу не относящийся, но показательный:
Samsung отказался от поддержки на своих устройствах кодеков DivX/XviD, т.к. по сети распространяется много пиратских фильмов в формате .avi, использующем эти кодеки.
Дык, он, еще когда у нас его мессенджер блочили, заявлял, что готов предоставлять IP и другие данные по обоснованным юридическим запросам. Но ключи может предоставить только железные, т.к. при сквозном шифровании ключи хранятся только у клиентов.
Но спецслужбам (нашим ли, французским, еще чьим-то) этого мало. Они требовали отказа от сквозного шифрования, внедрения бэкдоров и возможности просматривать переписку любого клиента без ведома и согласия Телеги.
Как изначально клиент получает список других участников DHT? А без него, найти их самостоятельно проблематично.
В локалке можно отправить широковещательный запрос на UDP#6881. Но не факт, что кто-то найдется.
Можно пошерстить по списку прошлых сидов/пиров. Но как быть тем, кто скачал первый и единственный торрент с RuTracker, а анонсеры заблочкны и никакого адреса он получить не может?
Говорят, что есть какие-то bootstrap-списки в открытом доступе, содержащие адреса DHT-агрегаторов. Но насколько они актуальны?
Прошу прощения, но "с какой целью интересуетесь" относилось не к Вам, а к пиру, приславшего DHT-запрос. Мол, цель-то одна - скачивание.
Но вот сам факт запроса вовсе не свидетельствует о том, что такая раздача у запрашиваемого клиента есть.
Разумеется, не свидетельствует. Но DHT работает по принципу расширяющегося поиска. Не нашлась раздача среди ближайшего окружения - найдется на следующем круге поиска. Или на следующем. По "теории шести рукопожатий", если пиринговая сеть связная, то найдется всё.
Криптография с открытым ключом, а не хеширование?
Нет, похоже, это Вы не понимаете, что предлагаете просто вложить в эту систему готовую DDoS атаку на саму себя.
Даже DHT-запросы в торрент-клиентах вызывают кратковременные сетевые штормы. Но они затрагивают только каналы связи, а не клиентские машины, т.к. вычисление хешей даже по SHA-1 - достаточно легковесная процедура.
А вот аутентификация по открытому ключу - это уже серьезно будет нагружать компьютеры и устройства пользователей. И это будет работать примерно так:
Алиса хочет связаться с Бобом, но не знает его адреса.
Алиса посылает запрос "Где Боб" Кэрол и Тренту, удостоверив его своей цифровой подписью (эту нагрузку пока что можно игнорировать).
Но Кэрол и Трент уже забыли, кто такая Алиса (не имеют её публичного ключа).
Они начинают рассылать запросы "Кто такая Алиса?" по всем своим знакомым, подписывая своей ЭЦП (вот появилась первая нагрузка на промежуточные узлы).
Знакомые, допустим, знают Кэрол и Трента (имеют их публичные ключи). Но чтобы убедиться, что сообщение пришло от них, должны расшифровать их ЭЦП и удостовериться в их целостности и непротиворечивости.
Допустим, они знают Алису и могут сообщить Кэрол и Тренту ее публичный ключ.
Кэрол и Трент, слегка успокоившись, приступают к обработке запроса Алисы.
Но они тоже не знают, где Боб. Так что поиск с шифрованием/расшифровыванием запросов продолжается.
В конце концов TTL первоначального запроса исчерпывается или все же находится кто-то, кто знает и где Боб и запрашивающего.
Тогда он отвечает и отправляет ответ обратно, подписывая своей ЭЦП.
Ответ проходит уже без поиска пути назначения, но всё равно узлам по всей цепочке надо удостовериться, что информация пришла от того, от кого надо. Т.е. опять тягомотина с расшифровыванием и шифрованием.
Наконец, информация о Бобе приходит к Алисе.
Та, радостная, шлет ему сакраментальное "Hello Bob!"
Но Боб тоже успел забыть, кто такая Алиса.
И шлет по всем своим знакомым запрос "Who is fu***ng Alice?"
Развлекуха продолжается.
How do you like this Elon Musk?
А зачем узнавать пароль?
Достаточно знать сам хеш пароля. А он уже будет известен.
Обычно де при аутентификации передается пара (логин, хеш пароля). Но этот метод уязвим перед "атакой повтором". Перехватив один раз передаваемый хеш, можно затем передавать самому.
Для противодействия этому применяют динамическое соление. Каждый раз, при аутентификации клиенту передается некая случайеая "соль". Она дописывается к хешу пароля м снова хешируется. При получении такого двойного хеша сервер тоже берет хранимый хеш пароля, дописывает к нему "соль", если она еще не "протухла" и снова хеширует. Потом сравнивает с тем, что пришло.
Т.е. таким образом передается всегда разный хеш. Это помогает от перехвата.
Но не помогает, если тот-кого-нельзя-называть получит доступ к устройству с хранящимся несолёным хешем пароля.
Как это нет вероятности?
Вот попадает устройство, являющееся DHT-узлом в руки того-кого-нельзя-называть. А в этом устройстве куча логинов и парольных хешей.
Тот-кого-нельзя-называть копирует парольную пару и использует её для входа под чужим логином.
И всякие ухищрения, типа динамического соления, не помогают, потому что они затрудняют подбор пароля при перехвате хеша. А здесь ничего не перехватывается а просто задаром получается несолёный хеш.
И чем больше устройств в сети, тем больше вероятность того, что одно из них взломают.
Читаю заголовок ...
Так обнаружение было с использованием ML тли атака?
А теперь LG как?
А то нашему Самсунгу узе 15 лет. AVI он нормально воспроизводит, кроме "битых". А вот MKV не все. А медиацентр домосборный, слабенький - не хватает ему мощи "на лету" перекодировать форматы. Начинаются фризы на тяжелых фильмах.
Хочу всеядный, с DLNA и чтобы с веб-интерфейсом. А у LG его нет :( Или я не нашел.
Это не аутентификация. Это просто сеансовая регистрация.
Для аутентификации логин (номер) и хеш пароля должен где-то храниться. Но не на сервере, т.е. сеть одноранговая.
Т.е. хранение должно быть так же распределенным и с поддержанием целостности, даже если большая часть клиентов выйдет из неё.
В то же время, чем больше узлов хранит аутентификационную пару пользователя, тем выше вероятность компрометации.
Кажется, была здесь статья, как реализовать аутентификацию в децентрализованных сетях. Но вряд ли найду ...
"Поваренную книгу" читал. Забавно. Но в научно-популярных книгах по химии, изданных в 60-х годах, еще и не такое можно было найти :D
Стоп! ...
А ведь раньше, до того как продаться мелкомягким, Skype использовал гибридную децентрализованную систему.
Т.е. центральных серверов не было, но некоторые мощные клиенты могли взять на себя функции супернод - координационных узлов. Они выполняли роли STUN-серверов, а при необходимости пропускали через себя трафик других клиентов (TURN).
Так что, распределенные сети мессенджеров - это уже было.
P.S. Хотя насчет STUN на супернодах я не уверен.
Дык, бутстрап содержит список официальных агрегаторов - резервирование на случай перебоев доступа.
А товарищимайоры делают фейковые агрегаторы (как IKnowWhatYouDownload), чтобы ловить участников поиска (иначе без поиска это уже не DHT-сеть). А при необходимости эти фейковые агрегаторы начинают выдавать пургу, затрудняя или совсем задудосивая поиск).
Не китайцами одними ... Другие южнокорейцы (LG, Hyundai) не спешат перенимать столь бесценный опыт.
Да, мессенджеры будут прижимать жестко.
И вот тут такие агрегаторы-ловушки будут задействованы на полную. Будут фиксировать попытки использования этой сети.
И это не считая того, что полицейские будут просить "предъявить телефончик" на предмет проверки установленного приложения.
Вспомнил еще казус, к делу не относящийся, но показательный:
Samsung отказался от поддержки на своих устройствах кодеков DivX/XviD, т.к. по сети распространяется много пиратских фильмов в формате .avi, использующем эти кодеки.
Дык, он, еще когда у нас его мессенджер блочили, заявлял, что готов предоставлять IP и другие данные по обоснованным юридическим запросам. Но ключи может предоставить только железные, т.к. при сквозном шифровании ключи хранятся только у клиентов.
Но спецслужбам (нашим ли, французским, еще чьим-то) этого мало. Они требовали отказа от сквозного шифрования, внедрения бэкдоров и возможности просматривать переписку любого клиента без ведома и согласия Телеги.
Формально Дуров тоже не принимал участия в распространении детского порно, сделках с запрещенными веществами и террористических атаках ...
Del
Что-то подобное я предполагал.
Но этот подход чувствителен к блокировкам. Если блочат анонсеры, то кто мешает блочить и такие DHT-агрегаторы?
У меня вот какие непонятки:
Как изначально клиент получает список других участников DHT? А без него, найти их самостоятельно проблематично.
В локалке можно отправить широковещательный запрос на UDP#6881. Но не факт, что кто-то найдется.
Можно пошерстить по списку прошлых сидов/пиров. Но как быть тем, кто скачал первый и единственный торрент с RuTracker, а анонсеры заблочкны и никакого адреса он получить не может?
Говорят, что есть какие-то bootstrap-списки в открытом доступе, содержащие адреса DHT-агрегаторов. Но насколько они актуальны?
Прошу прощения, но "с какой целью интересуетесь" относилось не к Вам, а к пиру, приславшего DHT-запрос. Мол, цель-то одна - скачивание.
Разумеется, не свидетельствует. Но DHT работает по принципу расширяющегося поиска. Не нашлась раздача среди ближайшего окружения - найдется на следующем круге поиска. Или на следующем. По "теории шести рукопожатий", если пиринговая сеть связная, то найдется всё.
Что-то это какой-то бешеный заяц - меняет направление на противоположное.
Но если заяц еще способен резко затормозить или сменить направление движения, то ЛА так не может:
Даже если бы у ЛА был реверсивный двигатель - резко затормозить, развернуться и опять врубить тягу ему не дано.
Поэтому, скорость может изменяться очень незначительно. И то за счет повышенного сопротивления воздуха на маневре.
А вот направление может изменяться. Но не сильно и не мгновенно, а по дуге с ограничением по минимальному радиусу.
Дык, "а с какой целью интересуетесь"?
В смысле, какая еще может быть цель запроса наличия раздачи с заданным хешем, кроме желания скачать эту раздачу?