nprofile1qy2hwumn8ghj7un9d3shjtnyd968gmewwp6kyqpqw2n3refqh4tkdacss9v639puv2pcntjsuvzflhkxta2qcwfzgfrq6j3m7k (nprofile…3m7k)
привет,
предполагаю, что это ты мне ответил:) на вот эту ссылку
https://arxiv.org/pdf/2512.15510v1
верну ее для сохранения контекста.
>Продвинутые механизмы защиты в I2P
спасибо. да, меры безусловно рабочие, и в целом затрудняют пассивные атаки, но впрямую i2perception они (за исключением возможно мультихоуминга, его есть смысл попробывать) не противодействуют.
как я понял, суть i2perception - в корреляции поведения(таймингов) роутера (изначально открытая природа публикации RouterInfo необходимая для работы сети) и некоторого скрытого сервиса (который публикуется на какомто роутере, без конкретного идента).
атакующий поднимает несколько флудфилов,наблюдает, собирает статистику, отслеживает включение выключение роутеров и таргет скрытосервиса, и через какойто промежуток времени (если скрытосервис долгоживущий) нормальное распределение сузит список вероятных роутеров хостящих скрытосервис до минимума.
>Дока про туннели
там есть про
trustedRouters List of comma-separated b64 addresses of routers to choose from for first hop (default: unset)
а вот как это настроить правильно и как проверить что оно работает как задумано - непонятно.
моя мысль была такая
разделить -
1. роутер с опубликованым сервисом (b33) имеющий список доверенных guard нод (для первого хопа) для выхода в сеть, но сам в транзите не участвующий (hidden=true).
2. и собственно несколько полноценных транзитных роутеров (без опубликованных сервисов) к которым будет подмешиваться трафик моего сервиса.
да, выглядит, как тотже мультихоуминг - увеличиваем количество роутеров, чем больше - тем лучше, размазываем корреляцию.
...но выглядит как экстенсивный путь.
а интенсивный имо - нужно иметь возможность изменять поведение (настройки) роутера на котором опубликован сервис, чтобы затруднять подобный тип пассивных атак (типа случайный джиттер при публикации роутера в сети? или лизсета)
понятно, что это не закроет выход из строя датацентра - тут, только варианты мультихоуминга
но вот что напрягает - авторы исследования видимо с разработчиками джава роутера только поработали
[43]I2PRelease, “I2P 2.8.0 Released,” 2025, accessed: 2025-07-11. [Online].
Available: https://geti2p.net/en/blog/post/2025/02/03/i2p-release-2.8.0
"Other changes were implemented to reduce the observability of events like a router rebooting or shutting down."
про i2pd ничего нет.
iwojima (硫島於闇網)
npub1x6…2rtpr
2026-02-03 07:29:19 UTC
in reply to nevent1q…w286
Author Public Key
npub1x629ghs30yn64sldun8cdfvhzxc4kmlaelvwpn5hksf5zxac25xsw2rtprSeen on
wss://relay.ditto.pubPublished at
2026-02-03 07:29:19 UTCEvent JSON
{
"id": "35f627b89d719e8d2a75eed783dce4a4c33c0b6dfd9bd237bb5b8cb047bd7eae",
"pubkey": "3694545e117927aac3ede4cf86a59711b15b6ffdcfd8e0ce97b413411bb8550d",
"created_at": 1770103759,
"kind": 1,
"tags": [
[
"p",
"72a711e520bd5766f7108159a8943c628389ae50e3049fdec65f540c39224246",
"wss://relay.ditto.pub"
],
[
"p",
"cdc402cda2e8c9e4da0583adff7b73e2c308241ca6ca52b20c75e1a507638237",
"wss://relay.ditto.pub"
],
[
"e",
"88e4b8849bac42eb783f39c840395fc303fbc114bcd88adf7d5d7e5eb3b8773a",
"wss://relay.ditto.pub",
"reply"
],
[
"proxy",
"https://clubcyberia.co/objects/033e5753-f75e-4618-bc72-325fd705b5b1",
"activitypub"
],
[
"client",
"Mostr",
"31990:6be38f8c63df7dbf84db7ec4a6e6fbbd8d19dca3b980efad18585c46f04b26f9:mostr",
"wss://relay.ditto.pub"
]
],
"content": "nostr:nprofile1qy2hwumn8ghj7un9d3shjtnyd968gmewwp6kyqpqw2n3refqh4tkdacss9v639puv2pcntjsuvzflhkxta2qcwfzgfrq6j3m7k \nпривет,\nпредполагаю, что это ты мне ответил:) на вот эту ссылку\nhttps://arxiv.org/pdf/2512.15510v1\nверну ее для сохранения контекста.\n\n\u003eПродвинутые механизмы защиты в I2P\nспасибо. да, меры безусловно рабочие, и в целом затрудняют пассивные атаки, но впрямую i2perception они (за исключением возможно мультихоуминга, его есть смысл попробывать) не противодействуют.\n\nкак я понял, суть i2perception - в корреляции поведения(таймингов) роутера (изначально открытая природа публикации RouterInfo необходимая для работы сети) и некоторого скрытого сервиса (который публикуется на какомто роутере, без конкретного идента).\nатакующий поднимает несколько флудфилов,наблюдает, собирает статистику, отслеживает включение выключение роутеров и таргет скрытосервиса, и через какойто промежуток времени (если скрытосервис долгоживущий) нормальное распределение сузит список вероятных роутеров хостящих скрытосервис до минимума.\n\n\u003eДока про туннели\nтам есть про \ntrustedRouters \tList of comma-separated b64 addresses of routers to choose from for first hop (default: unset)\n\nа вот как это настроить правильно и как проверить что оно работает как задумано - непонятно.\n\nмоя мысль была такая\nразделить - \n1. роутер с опубликованым сервисом (b33) имеющий список доверенных guard нод (для первого хопа) для выхода в сеть, но сам в транзите не участвующий (hidden=true).\n2. и собственно несколько полноценных транзитных роутеров (без опубликованных сервисов) к которым будет подмешиваться трафик моего сервиса. \nда, выглядит, как тотже мультихоуминг - увеличиваем количество роутеров, чем больше - тем лучше, размазываем корреляцию.\n\n...но выглядит как экстенсивный путь.\nа интенсивный имо - нужно иметь возможность изменять поведение (настройки) роутера на котором опубликован сервис, чтобы затруднять подобный тип пассивных атак (типа случайный джиттер при публикации роутера в сети? или лизсета)\nпонятно, что это не закроет выход из строя датацентра - тут, только варианты мультихоуминга\nно вот что напрягает - авторы исследования видимо с разработчиками джава роутера только поработали\n[43]I2PRelease, “I2P 2.8.0 Released,” 2025, accessed: 2025-07-11. [Online].\nAvailable: https://geti2p.net/en/blog/post/2025/02/03/i2p-release-2.8.0\n\"Other changes were implemented to reduce the observability of events like a router rebooting or shutting down.\"\nпро i2pd ничего нет.",
"sig": "e3b3b5b67bef2de08954c22c76c076de44a4874cc9bdafe0e7becd65537dc0defdef597a565dc5fa958bd07ba87ede4d3b533a8a9e29be3faea529f8996072f3"
}