Почитал. Ну, в общем, создается впечатление, что всё уже есть, всё готово. I2P дает неубиваемый и неконтроллируемый интернет, мессенджеров также хватает на любой вкус. Если есть желание создать мессенджер без промежуточного хранения и без использования OpenSSL (в котором могут быть бэкдоры) - это можно сделать.
Решение какой именно задачи Вас интересует? Анонимность? Защищенность канала?
Я думаю будет интересно протестировать следующие задачи: - ассинхронное групповое общение. Типа Slack, когда я захожу в групповой чат, читаю переписку, отвечаю, закачиваю и скачиваю файлы и затем выхожу. При отсутствии сервера все сообщения должны храниться на устройствах участников этой группы и при моем появлении в сети мое устройство должно синхронизироваться с другими. Мне кажется, в i2p это реализовано хуже по сравнению с zeronet или ipfs. Я предлагаю протестировать, для этого, я думаю, нас должно быть больше 2х. - устойчивость к блокировке сервиса. Я исхожу из предположения, что в наихудшем сценарии часть https служб будет работать, типа государственные службы и пр. но при этом могут блокироваться порты других сервисов (например torrent на нашей фирме) а также анализироваться пакеты данных на соответсвие их https запросам. i2p вроде использует особые порты для общения?
Про групповые чаты мне нужно продумать детали, но в целом то, как Вы описали, выглядит достаточно разумно. Если где-то это реализовано кривовато - я не думаю, что это проблема подхода, скорее это проблема конкретной реализации
( ... )
Тут в голову пришло: в Вашей схеме группового чата возможно использование серверов для хранения данных. Только данные там должны храниться зашифрованные, и сервер не должен иметь к ним ключей. Чисто сторидж шифрованного контента. Обмен ключами должен производиться другими каналами. Хоть бумажным письмом по почте. Или морзянка по радио. Утрирую
То что вы предлажили уже реализовано в Keybase и Element. При использовании криптографии с открытым ключем не нужно хранить ключи на сервере, через сервер проходят только открытые ключи. Групповое общение, конечно, сложно организовать, т.к. для группы создается пара ключей одинаковая для все группы, этот вопрос решили в https://nacl.cr.yp.to/ для Keybase и https://matrix.org/ для Element. Но в случае с использованием сервера есть уязвимость, что айпишник сервера может быть очень быстро заблокирован интернет сервис провайдером. Распределенные системы гораздо более выживаемые.
>> айпишник сервера может быть очень быстро заблокирован
Это не так просто. Захостить, например, на гугле или чем-то таком. Да еще и в облаке. Заблокируют гугл? Кажется, в РФ уже пробовали. Продержалось недолго.
Сам Гугл может заблокировать. Я помню лет 10 назад на какойто конференции Брин чтото сказал нехорошее, это было записано на видео, люди стали делиться этим видео и обсуждать. Моментально вычистили из показа все сайты на которых это видео хостилось, затем сами новостные ресурсы стали чистить сообщения и форумы типа "не соответсвует теме". Я пробовал другие поисковики типа Бинг и Яндекс. Не покаызвали тоже, ну Яндекс наверное потому что он в основном русскоязычный. Я проверял где можно это видео найти через месяц после события и через год, не находил. Довольно быстро и добротно зачистили.
Я вот что еще Вам скажу: в данном вопросе наибольшей уязвимостью, как ни странно, является человеческий фактор. Пример: предположим, у Вас есть самый надежный гарантированно без бэкдоров шифрованный чат. Как Вы убедитесь, что ни один из участников чата не является сотрудником ФСБ или не сольет "куда слеует" все, что следует?
Для этого и существует подписывание девайсов в Кейбейз и Элементс. Например в Элементс если ктото присоединяется к беседе с использованием некоторого девайса, все собеседники должны подтвердить что этот девайс принадлежит именно пользователю которого все собеседники знают, обычно используя другой канал. Т.е. если пользователь не передаст свой девайс сотрудникам ФСБ то по-другому сотрудник не сможет присоедениться к беседе. Т.е. человеческий фактор, только немного другой.
Ну, в общем, создается впечатление, что всё уже есть, всё готово. I2P дает неубиваемый и неконтроллируемый интернет, мессенджеров также хватает на любой вкус.
Если есть желание создать мессенджер без промежуточного хранения и без использования OpenSSL (в котором могут быть бэкдоры) - это можно сделать.
Решение какой именно задачи Вас интересует? Анонимность? Защищенность канала?
Reply
- ассинхронное групповое общение. Типа Slack, когда я захожу в групповой чат, читаю переписку, отвечаю, закачиваю и скачиваю файлы и затем выхожу. При отсутствии сервера все сообщения должны храниться на устройствах участников этой группы и при моем появлении в сети мое устройство должно синхронизироваться с другими. Мне кажется, в i2p это реализовано хуже по сравнению с zeronet или ipfs. Я предлагаю протестировать, для этого, я думаю, нас должно быть больше 2х.
- устойчивость к блокировке сервиса. Я исхожу из предположения, что в наихудшем сценарии часть https служб будет работать, типа государственные службы и пр. но при этом могут блокироваться порты других сервисов (например torrent на нашей фирме) а также анализироваться пакеты данных на соответсвие их https запросам. i2p вроде использует особые порты для общения?
Reply
Reply
Reply
Reply
Reply
Это не так просто. Захостить, например, на гугле или чем-то таком. Да еще и в облаке. Заблокируют гугл? Кажется, в РФ уже пробовали. Продержалось недолго.
Reply
Reply
Reply
Reply
Reply
Leave a comment