Здравствуйте, Qulac, Вы писали:
Q>Смотря что считать децентрализацией, если криптографию — всегда должна присутствовать третья сторона которой доверяют абоненты. Даже если мы пересылаем симметричные ключи друг другу на почту, то третья сторона — это почтовые сервисы. В общем виде нужен удостоверяющий центр, который будет подписывать пару "открытый ключ — индикатор(email,phone,host и т.д)" тем самый подтверждая что предъявитель пары является владельцем индификатора.
У меня сугубо дилетантский взгляд на эти вещи; мне казалось что здесь главное — обеспечить хранение сообщения на временном сервере. Если A хочет передать B сообщение, то либо он может сделать, если они оба соединились онлайн; либо же надо, чтобы был третий участник C — вначале A передаст C сообщение, а потом C передаст сообщение B. Никто не пробовал в роли C использовать дополнительный дешёвый смартфон, который ловит в квартире вайфай и больше ни для чего не используется?
"Ты должен сделать добро из зла, потому что его больше не из чего сделать." Р.П. Уоррен
T>Под контролем над устройством ты понимаешь то, что никто не хучит передачу данных?
Под контролем устройства я понимаю встроенный в экран софт, который может отправлять снимки экрана по требованию нужных агентств. Встроенный кейлоггер, как вариант.
T>Хорошо, если мы представим что телефон на опенсорсной Ubuntu Touch, мессенджер тоже опенсорный
Опенсорсный, это хорошо. Ты его сам собирал, или кто-то другой? А ты этому кому-то другому веришь, или не очень? Если бы говорим о security, то, разумеется, верить такому нельзя. Собирать нужно самому. И не откуда-то взятым компилятором (откуда ты знаешь, что он там тебе влинкует, какие еще "библиотеки телеметрии"), а чтоб проверенным.
T> Можем такую конфигурацию считать гарантировано безопасной? Если нет, какие тут уязвимости?
Контроллер дисплея, например. И вообще все то, что иногда называют собирательным понятием "BIOS", подразумевая под этим "софт, который работает вне ОС". Всякие там IME, в которых регулярно находят новые бэкдоры, и делают вид, что их закрывают.
SK>опенсорс? значит любой может взять исходники и поднять у себя в изолированной сети всю его инфраструктуру?
Инфраструктура-то тебе зачем?
SK>не, не сможет? маленький пустячок помешает?. нет полных исходников сервера... SK>какая жаль.
Чего жаль-то? Какая тебе разница, что на сервере? Это всего лишь посредник, которых и так легион — все эти роутеры и прочие сетевые устройства. Какая разница, что там в них происходит, если у тебя end-to-end шифрование? Важно только то, что у тебя в клиенте. Ты должен доверять только клиенту. Но — полностью: включая железку, на которой он запущен.
SK>затем, что скриншотами занимается другое ведомство? затем, что не нужно класть все яйца в одну корзину?
Меня восхищает глубина познаний на тему "других ведомств". Но чтобы было понятно, ты сейчас пытаешься спорить с человеком, который не только _слышал_, но также _читал_ и даже _писал_ все это. Аргументы из мерии "я верую!" можешь предъявлять кому-то еще. Мне вера не требуется, ибо у меня есть знания.
На твоем телефоне. Клиентом OWS протокола (в данном случае whatsapp, но он тоже базируется на OWS, потому что оригинальный код libsignal писал один человек, Мокси — и это уж потом, года три спустя, я переписал на чистом эрланге без использования FFE).
SK>- как эти ключи попадут в мессенджер?
Мессенджер их генерирует, и отправляет на сервер публичные ключи. Вообще, все же на github'е — нешто так сложно посмотреть? Там очень простой и понятный код, выверенный за много лет.
K>У меня сугубо дилетантский взгляд на эти вещи; мне казалось что здесь главное — обеспечить хранение сообщения на временном сервере. Если A хочет передать B сообщение, то либо он может сделать, если они оба соединились онлайн; либо же надо, чтобы был третий участник C — вначале A передаст C сообщение, а потом C передаст сообщение B. Никто не пробовал в роли C использовать дополнительный дешёвый смартфон, который ловит в квартире вайфай и больше ни для чего не используется?
Вместо С проще использовать некий централизованный сервис. Тот самый "сервер Signal". Если проблема в том, что такой сервис могут блокировать — так и "телефон С" тоже могут. Проблема с "телефоном С" — как сделать так, чтбоы его могли обнаружить (discovery) и A, и B.
Здравствуйте, SkyDance, Вы писали:
SK>>опенсорс? значит любой может взять исходники и поднять у себя в изолированной сети всю его инфраструктуру?
SD>Инфраструктура-то тебе зачем?
Не понял ответа.
SK>>не, не сможет? маленький пустячок помешает?. нет полных исходников сервера... SK>>какая жаль.
SD>Чего жаль-то? Какая тебе разница, что на сервере? Это всего лишь посредник, которых и так легион — все эти роутеры и прочие сетевые устройства. Какая разница, что там в них происходит, если у тебя end-to-end шифрование? Важно только то, что у тебя в клиенте. Ты должен доверять только клиенту. Но — полностью: включая железку, на которой он запущен.
1) хочу свой корпоративный сервер onsite. Не хочу зависеть от чужой инфраструктуры (отказы чужих серверов, оплаты чужих каналов связи, сбоев чужого энергопитания, вандализма, боевых действий, нападения марсиан).
1) Все что происходит в Вегасе, должно остаться в Вегасе. Включая метаинформацию кто-с-кем-как-часто-как-долго-откуда(geo.loc)-куда(geo.loc).
1) — в подветке про ватсап с ключами развернуто напишу.
SK>>затем, что скриншотами занимается другое ведомство? затем, что не нужно класть все яйца в одну корзину?
SD>Меня восхищает глубина познаний на тему "других ведомств". Но чтобы было понятно, ты сейчас пытаешься спорить с человеком, который не только _слышал_, но также _читал_ и даже _писал_ все это. Аргументы из мерии "я верую!" можешь предъявлять кому-то еще. Мне вера не требуется, ибо у меня есть знания.
Пока у меня нет Знания что нечто безопасно — я верю/считаю это ненадежным (доступным третьим лицам).
Здравствуйте, SkyDance, Вы писали:
SK>>- где генерим? SK>>- чем генерим?
SD>На твоем телефоне. Клиентом OWS протокола (в данном случае whatsapp, но он тоже базируется на OWS, потому что оригинальный код libsignal писал один человек, Мокси — и это уж потом, года три спустя, я переписал на чистом эрланге без использования FFE).
То есть, я не могу сгенерить ключи на доверенном устройстве и перенести их?
Скажи еще, что я не могу посмотреть, сохранить их plain text (а заодно передать стороне Б открытый ключ другим каналом)?
SK>>- как эти ключи попадут в мессенджер?
SD>Мессенджер их генерирует, и отправляет на сервер публичные ключи. Вообще, все же на github'е — нешто так сложно посмотреть? Там очень простой и понятный код, выверенный за много лет.
Код сервера открыт?
Как мне убедится что сторона Б получит именно мой ключ (а я получу ключ именно стороны Б), а не сгенерированную сервером пару подложных ключей?
Чтобы исключить попытки передачи открытого ключа другим каналом связи, абоненты максимально запутались и не думали пытаться проверить, действительно ли ключ принадлежит стороне Б?
Можно еще вспомнить фееричную закладку в openssl, когда при определенном векторе генерились слабые/предопределенные ключи. Сколько лет её не замечали?
Вероятно у ватспа такого нет, ибо владея сервером это не требуется, но окончательно не исключаю.
Q>Смотря что считать децентрализацией, если криптографию — всегда должна присутствовать третья сторона которой доверяют абоненты. Даже если мы пересылаем симметричные ключи друг другу на почту, то третья сторона — это почтовые сервисы.
Зачем? Пресса! Газета бесплатных объявлений (а даже и платных — опубликовать 2 строки не так дорого). Для надежности повторить в нескольких разных изданиях. Заодно и hardcopy получится.
SK>Скажи еще, что я не могу посмотреть, сохранить их plain text (а заодно передать стороне Б открытый ключ другим каналом)?
подсмотреть ключ, имея доступ к твоему клиенту, не так сложно
SK>Код сервера открыт? SK>Как мне убедится что сторона Б получит именно мой ключ (а я получу ключ именно стороны Б), а не сгенерированную сервером пару подложных ключей?
" сделано для чего?
SK>Чтобы исключить попытки передачи открытого ключа другим каналом связи, абоненты максимально запутались и не думали пытаться проверить, действительно ли ключ принадлежит стороне Б?
я тебе прислал популярную статью но ты даже не попытался прочитать. там как раз объясняется зачем — на случай утечки ключа.
SK>Можно еще вспомнить фееричную закладку в openssl, когда при определенном векторе генерились слабые/предопределенные ключи. Сколько лет её не замечали?
ты еще heartbleed вспомни.
а вообще как правильно пишут, если тобой интересуются 3х буквенные агенства, то никакое шифрование не поможет, будут снимать данные напрямую с телефона.
шифрование в мессенджерах предназначено против массовой слежки, чтобы тащмайор не мог залогать сообщения присосавшись к каналу твоего мобильного оператора.
SK>1) хочу свой корпоративный сервер onsite. Не хочу зависеть от чужой инфраструктуры (отказы чужих серверов, оплаты чужих каналов связи, сбоев чужого энергопитания, вандализма, боевых действий, нападения марсиан).
Погоди-погоди. Я отвечал на вот этот вот вброс:
SK>А разве "сигнал" не зашкварился на сливе в АНБ
И ответил вполне конкретно и по делу. Нет, "сигнал" никуда не шкварился, и ты можешь это проверить прямо в их репозитории. Не надо тут уводить дискуссию на тему "я хочу свой сервер поднять".
SK>1) Все что происходит в Вегасе, должно остаться в Вегасе. Включая метаинформацию кто-с-кем-как-часто-как-долго-откуда(geo.loc)-куда(geo.loc).
Коль у тебя настолько необычные желания, ну что же, пиши свой сервер. Это, кстати, нетрудно, ибо бОльшая часть кода никуда не делась. В общем-то, это довольно простая задача, ведь все, что требуется — взять обычный опен-сорсный джаббер-сервер (рекомендую ejabberd ) и добавить туда e2ee (расширив соответствующие IQ).
SK>Пока у меня нет Знания что нечто безопасно — я верю/считаю это ненадежным (доступным третьим лицам).
Мы, конечно, можем обсудить твои знания, но тогда давай делать это цивилизованно — без поливания грязью по типу "зашкварился на сливе".
SK>То есть, я не могу сгенерить ключи на доверенном устройстве и перенести их?
Ключи чего? Шифрования каждого отдельного сообщения? А в чем смысл этого мероприятия? Если ты не доверяешь клиенту whatsapp, какая разница, где ты генерируешь ключи, ведь клиент может их переслать тов. майору. А если доверяешь, то зачем отдельное устройство?
SK>Скажи еще, что я не могу посмотреть, сохранить их plain text (а заодно передать стороне Б открытый ключ другим каналом)?
Про какие именно ключи сейчас речь? Про ключи, идентифирующие конкретного клиента?
Передать открытый ключ — это пожалуйста, для того QR код и придуман. Берешь "сторону Б", сканируешь, и тем самым идентифицируешь "это сторона А".
Про "посмотреть и сохранить в plain text" не понял. Ты хочешь экспортировать ключи из whatsapp'а? Вообще, AFAIK, клиент их хранит в защищенном локальном хранилище (они не переносятся на другой телефон, — поэтому при смене телефона все твои "стороны Б" получат уведомление "у стороны А сменился ключ".
Или речь про одноразовые ключи шифрования (для каждого сообщения свой)?
SK>Код сервера открыт?
Вот что в лоб, что по лбу. Да какая разница, открыт код сервера, или нет? Сервер — это просто дисковое хранилище, чтобы два клиента могли общаться без прямого соединения. Для простоты, можешь считать что сервера нет, и клиенты соединяются напрямую.
SK>Как мне убедится что сторона Б получит именно мой ключ (а я получу ключ именно стороны Б), а не сгенерированную сервером пару подложных ключей?
Это для того, чтобы *КАЖДОЕ* сообщение шифровалось *ОТДЕЛЬНЫМ* ключом. Так что если кто-то смог взломать одиночный ключ, это никак не повлияло на все остальные (non-repudiation guarantee).
SK>Чтобы исключить попытки передачи открытого ключа другим каналом связи, абоненты максимально запутались и не думали пытаться проверить, действительно ли ключ принадлежит стороне Б?
Говорю же, изучи хотя бы whitepapers, если исходный код слишком сложен для чтения.
SK>Можно еще вспомнить фееричную закладку в openssl, когда при определенном векторе генерились слабые/предопределенные ключи. Сколько лет её не замечали?
Сколько? И откуда такие точные знания, что вот там прямо-таки "закладка", а не банальное "не предусмотрели"?
SK>Вероятно у ватспа такого нет, ибо владея сервером это не требуется, но окончательно не исключаю.
Плохо, когда отсутствие знаний заменяется "ибо верую!"
Здравствуйте, SkyDance, Вы писали:
SD>Контроллер дисплея, например. И вообще все то, что иногда называют собирательным понятием "BIOS", подразумевая под этим "софт, который работает вне ОС". Всякие там IME, в которых регулярно находят новые бэкдоры, и делают вид, что их закрывают.
Думал-думал на досуге, как с этим быть, и придумал только такое — устройство за роутером, который позволяет конектиться только на адрес сервера мессенджера. Входящие соединения, понятно, рубит.
Это ограничивает параоника в мобильности — должен быть за роутером, но кажись от бэкдоров спасает?
Здравствуйте, tapatoon, Вы писали:
T>Думал-думал на досуге, как с этим быть, и придумал только такое — устройство за роутером, который позволяет конектиться только на адрес сервера мессенджера. Входящие соединения, понятно, рубит. T>Это ограничивает параоника в мобильности — должен быть за роутером, но кажись от бэкдоров спасает?
А теперь подумай от чего ты защищаться собрался шифрованием.
А то обложился такой всем параноидальным, а в итоге банальный терморектальный криптоанализ откроет все замки
Здравствуйте, SkyDance, Вы писали:
SD>Чего жаль-то? Какая тебе разница, что на сервере? Это всего лишь посредник, которых и так легион — все эти роутеры и прочие сетевые устройства. Какая разница, что там в них происходит, если у тебя end-to-end шифрование? Важно только то, что у тебя в клиенте. Ты должен доверять только клиенту. Но — полностью: включая железку, на которой он запущен.
Какая манипуляция. Приравнять сервер, который знает протокол и природу пересылаемых через него данных с роутерами...
Роутеры видят кто кому через Signal сообщение пересылает?
Или может всё же в протоколе для посторонних роутеров всё шифруется и они не могут адресатов сообщений определить?
А вот уже серверы Signal наверно умеют определять кому и от кого зашифрованное сообщение нужно отправить, если получатель не в сети, то какое-то время хранят у себя это сообщение?
В соседней ветке у тебя: "Опенсорсный, это хорошо. Ты его сам собирал, или кто-то другой? А ты этому кому-то другому веришь, или не очень? Если бы говорим о security, то, разумеется, верить такому нельзя. Собирать нужно самому. И не откуда-то взятым компилятором (откуда ты знаешь, что он там тебе влинкует, какие еще "библиотеки телеметрии"), а чтоб проверенным.".
А как Signal, к которому ты имеешь отношение: нужно просто верить, что на сервере ничего такого нет, даже при условии, что исходников нет.
Начинаются рассказы будто вообще технически и нельзя ничего такого там нагородить.
Ну, правда правда там все честные, никому никакие ключи доступа не дадут и вообще вот именно в случае с Signal этого никак быть не может.
Сомневаешься — так просто тупой, не знаешь предметную область
Здравствуйте, karbofos42, Вы писали:
K>банальный терморектальный криптоанализ откроет все замки
Кстати да, такие меры защиты имеют смысл для людей, которым на самом деле есть что скрывать.
То есть тогда надо скрыть и IP/локацию общающихся. Хм... Приходит на ум только общение через какой-нибудь популярный ресурс типа VK обычными в виду непримечальными сообщениями, которые как-то расшифровываются... Типа слиться с толпой
T>Думал-думал на досуге, как с этим быть, и придумал только такое — устройство за роутером, который позволяет конектиться только на адрес сервера мессенджера.
Так жучок может в обход твоего роутера ходить. Например, через шпионскую сеть Apple систему FindMy (оно там Bluetooth/UWB умеет применять). Или вовсе через NFC какой. А то и через спутник — благо, сейчас спутники на НОО вполне соединяются с обычными телефонами.
K>А вот уже серверы Signal наверно умеют определять кому и от кого зашифрованное сообщение нужно отправить, если получатель не в сети, то какое-то время хранят у себя это сообщение?
Ты тоже из тех, кто "не знаю, но верую"?
Нет, сервер signal не знает, кто тебе присылает сообщение, благодаря технике sealed sender: https://signal.org/blog/sealed-sender/
K>А как Signal, к которому ты имеешь отношение: нужно просто верить, что на сервере ничего такого нет, даже при условии, что исходников нет.
Объясняю последний раз: совершенно не важно, что там есть на сервере. Он используется именно как роутер. Важно лишь то, что у тебя на клиенте. В отличие от многих других мессенджеров, клиент signal'а ты действительно можешь собрать сам, используя те средства, которым ты доверяешь.
K>Ну, правда правда там все честные, никому никакие ключи доступа не дадут и вообще вот именно в случае с Signal этого никак быть не может. K>Сомневаешься — так просто тупой, не знаешь предметную область
Сомневаться ты можешь сколь угодно, но если собираешься поливать грязью — хотя бы изучи предметную область, чтобы поливание было предметным, а не сродни бабкам у подъезда с их "проститутками".
Здравствуйте, SkyDance, Вы писали:
SD>Так жучок может в обход твоего роутера ходить. Например, через шпионскую сеть Apple систему FindMy (оно там Bluetooth/UWB умеет применять). Или вовсе через NFC какой. А то и через спутник — благо, сейчас спутники на НОО вполне соединяются с обычными телефонами.
Ясно. Короче, только комп со шнуром и ПО собранным собственноручно на компиляторе, который тоже сам собрал (слышал, что у гугла в билдах сначала собирается компилер)
Здравствуйте, wl., Вы писали:
wl.>то есть учетки не связаны, но вся переписка от другого аккаунта у меня есть
Вацап бекапы переписки на Андроиде хранит в гугл драйве, на айОсе в айклауде. Так что видимо оно там чего-то с бекапами напутало и в новый акк историю старого загрузило.
Забавно что при этом официального способа перенести историю сообщений с Андроида в айОс — нет
Здравствуйте, Khimik, Вы писали:
K>Подскажите, какие сейчас существуют месседжеры, с которыми разработчик гарантирует, что сообщения в принципе никто не перехватывает и не читает.
Такие, где нет регистрации по паспорту и SMS. И по ID-кодам мобильного телефона (вроде IMEI).
Такие, где нет централизированной организации издающей приложение мессенджера и обслуживающей сервера.
Tox, разве что. Jami -- под вопросом, собеседник видит твой IP. В Tox при звонке тоже.
SimpleX -- под очевидным вопросом (собственно когда большая часть серверов принадлежит самим разработчикам,
всё очевидно, как там всё анонимизировано).
Есть ещё несколько совсем малопопулярных мессенджеров, основанных на IPFS или Bittorrent DHT -- не знаю.
K> Я краем уха слышал про три таких: Status, Session, Adamant. Про их преимущества автор, которого я читал, писал так: K>Абсолютная анонимность, бескомпромиссное Р2Р-шифрование;
Щааааз.
K> использование техник обфускации геолокации и прогон трафика через Tor; удаление из передаваемых сообщений метаданных; никаких требований к регистрации и сборов пользовательских данных; никакой слежки, никаких номеров мобильных и адресов электронных почт. Вся коммуникация живет онлайн, бок о бок с остальными объектами, фиксируемыми в блокчейне: криптовалютами, децентрализованными приложениями, NFT.
Это всё обфусцированное враньё. Пока за обслуживание мессенджера кто-то платит -- он что-то с этого имеет.
Может не так непосредственно, как в мессенджере Max, но тем не менее.
K>Но далее автор писал, что все эти три месседжера пока очень неудобные. Кто-нибудь знает о чём речь?
Когда мессенджер делают три любителя раз в три года, там всё глючное и неудобное.
Там нет смайликов и эмоджей, стикеров и прочих херовин, не знаю как они сейчас называются.
Там картинку бывает не вставить.
Когда мессенджер работает через DHT-сеть, то чтоб принять/отправить сообщение или позвонить
нужно его включить и ждать минут 10 как минимум. Позвонить может вообще не удастся если
оба абонента за непробиваемым NAT: Turn-серверов нет же.
При работе через DHT-сеть нельзя получить "нотификацию" через FCM (Firebase Cloud Message),
нужно постоянно держать приложение включённым, оно постоянно создаёт траффик и сажает батарейку
за четыре часа.
