Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 35
«Существует список известных узлов, называемый netDb, изменяющийся в процессе работе, информация о новых узлах поступает от других узлов. „
Значит эти известные узлы должны иметь белые айпишники?
Значит эти известные узлы должны иметь белые айпишники?
Нет. Это могут быть IP-адреса роутеров, определённые порты на которых проброшены на I2P-роутер. Сам этот I2P-роутер может быть за NAT.
В целом да. Иначе произвольный маршутизатор не сможет переслать ему никакое сообщение если не сможет установить с ним соединение, что резко ограничивает возможности. В первую очередь такой маршутизатор фактически не сможет участовать в передаче транзитного трафика, кроме того входящие тоннели можно строить только через маршутизаторы, с которыми уже имеется соединение.
С другой стороны хостить, например, свой сайт можно и не имея «белого» ай-пи — достаточно надлежашим образом тоннели для LeaseSet-а.
С другой стороны хостить, например, свой сайт можно и не имея «белого» ай-пи — достаточно надлежашим образом тоннели для LeaseSet-а.
А зачем шифровать IV, да еще и в режиме ECB?
На этот вопрос я бы тоже хотел знать ответ. Я когда на это наткнулся, то не мог понять, откуда следует брать IV для шифрования IV, пока не осознал что используется ECB (кстати этот момент в официальной документации опущен). Более того, шифровать IV нужно дважды.
У меня сложилось впечтление, что I2P был начат студентами, пытавшимся применить на практике знания, полученные на лекциях, возможно не всегда целесообразно.
В любом случае при разработке клиента мы не имеем возможности изменить протокол, а вынуждены реализовывать то, что есть, чтобы взаимодествовать с другими узлами сети.
У меня сложилось впечтление, что I2P был начат студентами, пытавшимся применить на практике знания, полученные на лекциях, возможно не всегда целесообразно.
В любом случае при разработке клиента мы не имеем возможности изменить протокол, а вынуждены реализовывать то, что есть, чтобы взаимодествовать с другими узлами сети.
А можете немного подробнее объяснить, если вам не трудно: «При этом IV шифруется тем же самым ключом дважды: до шифрования и после, называется это двойным шифрованием (double encryption)» — что имеется в виду под «до шифрования» и «после шифрования»? IV ведь не является частью открытого текста, чем IV до шифрования отличается от того, что после?
У вас имеется IV, приходящий в сообщении TunnelData, являющийся часть открытого в смысле тоннеля текста.
www.i2p2.de/tunnel_message_spec.html
Вы должны его, в зависимости от стороны, зашифровать/расшифровать вашим ключем для IV, затем полученное значение использовать в качестве IV для шифрования самого содержимого, затем то же самое проделать с IV повторно, потом сообщение с уже перешифрованным IV идет дальше.
www.i2p2.de/tunnel_message_spec.html
Вы должны его, в зависимости от стороны, зашифровать/расшифровать вашим ключем для IV, затем полученное значение использовать в качестве IV для шифрования самого содержимого, затем то же самое проделать с IV повторно, потом сообщение с уже перешифрованным IV идет дальше.
Получается, у нас изначально есть:
— KeyIV — ключ для IV
— KeyMessage — ключ для сообщения
— PlainIV — открытый IV
— PlainMessage — открытый текст
EncryptedTempIV = AES(plaintext = PlainIV, key = KeyIV, mode = ECB)
EncryptedMessage = AES(plaintext = PlainMessage, key = KeyMessage, iv = EncryptedTempIV, mode = CBC)
EncryptedIV = ???
FinalMessage = Pack(EncryptedIV, EncryptedMessage)
Я вижу несколько вариантов того, как можно получить EncryptedIV:
a) AES(plaintext = EncryptedTempIV, key = KeyIV, mode = ECB)
b) AES(plaintext = EncryptedTempIV, key = KeyIV, iv = PlainIV, mode = CBC)
c) AES(plaintext = EncryptedTempIV, key = KeyMessage, mode = ECB)
d) четвертая смешная опция
К первому варианту (a) — авторы точно уверены, что Encrypt(Encrypt(x)), где Encrypt(x) := AES(plaintext = x, key = SAME_KEY, mode = ECB) — это вообще хорошая идея? В голову сразу приходит пример с гаммированием и полной обратимостью в случае одинакового ключа — кто-то вообще проводил анализ того, что получается с данными, если их дважды зашифровать одинаковым ключом?
Какой из вариантов используется на самом деле?
— KeyIV — ключ для IV
— KeyMessage — ключ для сообщения
— PlainIV — открытый IV
— PlainMessage — открытый текст
EncryptedTempIV = AES(plaintext = PlainIV, key = KeyIV, mode = ECB)
EncryptedMessage = AES(plaintext = PlainMessage, key = KeyMessage, iv = EncryptedTempIV, mode = CBC)
EncryptedIV = ???
FinalMessage = Pack(EncryptedIV, EncryptedMessage)
Я вижу несколько вариантов того, как можно получить EncryptedIV:
a) AES(plaintext = EncryptedTempIV, key = KeyIV, mode = ECB)
b) AES(plaintext = EncryptedTempIV, key = KeyIV, iv = PlainIV, mode = CBC)
c) AES(plaintext = EncryptedTempIV, key = KeyMessage, mode = ECB)
d) четвертая смешная опция
К первому варианту (a) — авторы точно уверены, что Encrypt(Encrypt(x)), где Encrypt(x) := AES(plaintext = x, key = SAME_KEY, mode = ECB) — это вообще хорошая идея? В голову сразу приходит пример с гаммированием и полной обратимостью в случае одинакового ключа — кто-то вообще проводил анализ того, что получается с данными, если их дважды зашифровать одинаковым ключом?
Какой из вариантов используется на самом деле?
Используется именно вариант a). Дважды тот же самый ключ.
Насколько я понимаю они таким образом пытались убрать IV, передаваемый открыто.
Согласен что идея дурацкая, как надевать два презерватива одновременно.
Я уверен лишь в том, что используется именно этот вариант — иначе другие узлы не смогли бы понять мои сообщения, равно как и я их.
Насколько я понимаю они таким образом пытались убрать IV, передаваемый открыто.
Согласен что идея дурацкая, как надевать два презерватива одновременно.
Я уверен лишь в том, что используется именно этот вариант — иначе другие узлы не смогли бы понять мои сообщения, равно как и я их.
Если вы держите веб-сайт, то задача спецслужбы заколючается в определении I2P адреса вашего маршутизатора, к которому прицеплен ваш сайт. Для этого нужно проследить маршрут какого нибудь из ваших входящих туннелей, который знаете только вы, как создатель этого тоннеля. Участники же знают только адреса следующих в тоннеле узлов. Посколько туннели как правило бывают в 3 узла, то достаточно придти в гости к этим 3 участникам. Проблема только в том, что эти узлы скорее всего окажутся в разных странах. А вот что все они могут принадлежать одному владельцу (спецслужбе) это запросто.
IP всех маршутизаторов публичны, более того текущий список можно скачать с ряда ftp-серверов.
Роутер сервера в принципе может узнать IP адресов всех узлов созданного им тоннеля, но на самом деле ему это не нужно — он формирует лишь цепочку I2P адресов, входящих в тоннель, и отсылает сообщение первому из них через какой нибудь свой исходящий тоннель.
В реальности IP адреса требуется знать только для пересылки сообщений между тоннелями.
Роутер сервера в принципе может узнать IP адресов всех узлов созданного им тоннеля, но на самом деле ему это не нужно — он формирует лишь цепочку I2P адресов, входящих в тоннель, и отсылает сообщение первому из них через какой нибудь свой исходящий тоннель.
В реальности IP адреса требуется знать только для пересылки сообщений между тоннелями.
Наоборот для построения исходящего тоннеля нужен входящий, потому что иначе нельзя будет узнать результат создания тоннеля.
На самом деле запросы на создание тоннелей можно посылать и непосрдественно, но чтобы не заморачиваться ввели понятие «нулевых тоннелей», который начинаются и заканчиваются на своем маршутизаторе и создаются автоматически при страрте. Вот через них и создают первые тоннели.
Когда вы вводите адрес то сначала маршутизатор найдет по вашему адресу 32-х байтный хэш I2P адреса вашего сайта. Теперь имея это число вам нужно найти его какой нибудь входящий тоннель, запросив для этого его LeaseSet. Для этого вы выбираете какой нибудь достаточно, как вы думаете хороший, маршутизатор и посылаете туда запрос с этим адресом. Тут возможно 3 варианта:
1. Маршутизатор вернул вам LeaseSet
2. Маршутизатор сказал вам что не знает такого и возвращает список других маршутизаторов, которые по его мнению знают
3. Ничего вообще не отвечает
В варианте 2 пытаемся послать запрос тем маршутизатором, которые сказали. В варианте 3 повторям попытку используя другие тоннели, и, возможно, другой маршутизатор.
Когда вы получили нужный вам тоннель, вы отсылаете и шифруете сообщение для маршутизатора ключем, указанным в LeaseSet-е с точкой назначения I2P адресом нужного вам сайта.
На самом деле запросы на создание тоннелей можно посылать и непосрдественно, но чтобы не заморачиваться ввели понятие «нулевых тоннелей», который начинаются и заканчиваются на своем маршутизаторе и создаются автоматически при страрте. Вот через них и создают первые тоннели.
Когда вы вводите адрес то сначала маршутизатор найдет по вашему адресу 32-х байтный хэш I2P адреса вашего сайта. Теперь имея это число вам нужно найти его какой нибудь входящий тоннель, запросив для этого его LeaseSet. Для этого вы выбираете какой нибудь достаточно, как вы думаете хороший, маршутизатор и посылаете туда запрос с этим адресом. Тут возможно 3 варианта:
1. Маршутизатор вернул вам LeaseSet
2. Маршутизатор сказал вам что не знает такого и возвращает список других маршутизаторов, которые по его мнению знают
3. Ничего вообще не отвечает
В варианте 2 пытаемся послать запрос тем маршутизатором, которые сказали. В варианте 3 повторям попытку используя другие тоннели, и, возможно, другой маршутизатор.
Когда вы получили нужный вам тоннель, вы отсылаете и шифруете сообщение для маршутизатора ключем, указанным в LeaseSet-е с точкой назначения I2P адресом нужного вам сайта.
LeaseSet всегда одинаковый. Маршутизатор просто держат компии и синхронизируют их.
Все маршруты объединены в один LeaseSet
Все маршруты объединены в один LeaseSet
forum.i2p формирует LeaseSet сам, выбирая из списка входящих тоннелей какие считает нужным. Затем он рассылает его нескольким маршутизаторам, а те передают дальше друг друга.
Что будет если попытаться себя за кого то другого, я, честно говоря, не знаю. Самому интересно. Возможно это у них дыра.
Что будет если попытаться себя за кого то другого, я, честно говоря, не знаю. Самому интересно. Возможно это у них дыра.
LeaseSet это множество тоннелей, ведущих к данной точке назначения. Для одного адреса LeaseSet всегда одинков, если в сети появится другой LeaseSet с тем же адресом, то правильным будет считаться более поздний.
Вы запрашиваете LeaseSet через тоннель, и если тот маршутизатор, который вы запрашиваете, окажется принадлежащими спецслужбам, то единственно что они могут узнать что некто интересуется этим адресом, а кто именно они не знают, потому как не знают, откуда идет ваш исходящий тоннель.
Вы запрашиваете LeaseSet через тоннель, и если тот маршутизатор, который вы запрашиваете, окажется принадлежащими спецслужбам, то единственно что они могут узнать что некто интересуется этим адресом, а кто именно они не знают, потому как не знают, откуда идет ваш исходящий тоннель.
Для этого вы выбираете какой нибудь достаточно, как вы думаете хороший, маршутизатор и посылаете туда запрос с этим адресом.Напрямую или через цепочку?
«Чеснок». Передача сообщений или последовательности между двумя кончеными узлами произвольным маршрутом и тоннелями
После этой фразы дальше читать стало гораздо веселее!
Спасибо, исправил.
Там дальше ещё много забавного; «оригинальное незашифрованное сообщение должно быть последовательно расшифровано перед его отправкой», например.
Это звучит забавно, но это именно так. Незашифрованное сообщение следует расшифровать.
Алгоритмы шифрования таковы: есть две функции, Encrypt и Decrypt. Они обладают свойством: Encrypt(Decrypt(A)) = A и Decrypt(Encrypt(B)) = B. Из этого свойства следует, что вообще-то неважно, какая из них собственно «шифрует» а вторая — «расшифровывает», важно, что они работают в паре: если шифровали первой, расшифровывать второй, и наоборот, если шифровали второй, расшифровывать первой. Но для определённости всё равно одну из них называют Encrypt, другую Decrypt.
Это используется не только в i2p. Например, известный алгоритм 3DES (Triple DES) на самом деле есть трижды применённый DES по схеме EDE (на каждом этапе — свой подключ). Т.е. шифруем с помощью функции DES Encrypt первым подключем, потом полученное шифруем функцией DES Decrypt со вторым ключем и потом полученное наконец шифруем функцией DES Encrypt с третьим ключом, а результат — есть результат шифрования 3DES. Для расшифровки, соответственно, DED с теми же ключами. Поскольку все ключи разные и независимые, в целом схема в три раза сильнее DES — 168 бит против 56.
Это используется не только в i2p. Например, известный алгоритм 3DES (Triple DES) на самом деле есть трижды применённый DES по схеме EDE (на каждом этапе — свой подключ). Т.е. шифруем с помощью функции DES Encrypt первым подключем, потом полученное шифруем функцией DES Decrypt со вторым ключем и потом полученное наконец шифруем функцией DES Encrypt с третьим ключом, а результат — есть результат шифрования 3DES. Для расшифровки, соответственно, DED с теми же ключами. Поскольку все ключи разные и независимые, в целом схема в три раза сильнее DES — 168 бит против 56.
Исходный код проекта в текущем состоянии располагается на гитхабе.Вы не сравнивали его с i2pcpp (на Гитхабе и оригинал в i2p)?
А у вас на гитхабе всё выложено?
Там в некоторых файлах Log.h инклудится, но я что-то его не вижу в репозитории.
И ещё, где точка входа а-ля main.cpp?
Там в некоторых файлах Log.h инклудится, но я что-то его не вижу в репозитории.
И ещё, где точка входа а-ля main.cpp?
Читал статью и не мог отделаться от выстраивания аналогий с соответствующей частью сети Tor. В Tor для обслуживания сайтов появляется две новых роли: introduction points и rendezvous points. Никак не могу взять в толк, кто в I2P аналог introduction point, а кто rendezvous point.
В I2P есть понятие floodfill-ов, это такие узлы которые обладают достаточно полной информации о сети, и, кроме того, берут на себя обязательства сообщать всю новую информацию другим floodfill-ам. Фактические это некие «справочники» сети, сообщающие любому желающему как обратиться к тому или иному узлу. Обычные маршутизаторы занимаются только построением тоннелей и пересылкой через них данных.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Основы разработки клиента сети I2P