Подскажите, какие сейчас существуют месседжеры, с которыми разработчик гарантирует, что сообщения в принципе никто не перехватывает и не читает. Я краем уха слышал про три таких: Status, Session, Adamant. Про их преимущества автор, которого я читал, писал так:
Абсолютная анонимность, бескомпромиссное Р2Р-шифрование; использование техник обфускации геолокации и прогон трафика через Tor; удаление из передаваемых сообщений метаданных; никаких требований к регистрации и сборов пользовательских данных; никакой слежки, никаких номеров мобильных и адресов электронных почт. Вся коммуникация живет онлайн, бок о бок с остальными объектами, фиксируемыми в блокчейне: криптовалютами, децентрализованными приложениями, NFT.
Но далее автор писал, что все эти три месседжера пока очень неудобные. Кто-нибудь знает о чём речь?
"Ты должен сделать добро из зла, потому что его больше не из чего сделать." Р.П. Уоррен
K>Абсолютная анонимность, бескомпромиссное Р2Р-шифрование;
freenet+frost, лет 10 назад было ещё живо, сейчас не знаю
Данное сообщение является художественным произведением и освещает вымышленные события в вымышленном мире. Все совпадения с реальностью являются случайными. Не является инвестиционной рекомендацией.
SK>Речь о мессенджерах в которых сидит по 1.5 унылых анонима торгующих друг с другом наркотой и обменивающихся детским порном.
Увы, на сейчас наверное да. Но как-то от всего этого цифрового концлагеря пора дистанцироваться.
Сегодняшняя новость: "Таможенная и пограничная служба США теперь требует от путешественников из 42 стран с безвизовым режимом раскрывать историю соцсетей в промежутке до пяти лет при запросе разрешения на въезд в Соединенные Штаты" — это тупо распространяющаяся тенденция, и скоро каждый силовик каждой страны посчитает своим долгом держать нос в личной переписке. А с учётом падения уровня жизни, половина этих чиновников станут сливать все найденные данные растущему криминалу.
Похоже, уже пора почту и всякие "Валера, СТО" держать в мессенджерах и соцсетях "для предъявления", а для всего личного подбирать какое-то безопасное решение.
Здравствуйте, hi_octane, Вы писали:
_>Сегодняшняя новость: "Таможенная и пограничная служба США теперь требует от путешественников из 42 стран с безвизовым режимом раскрывать историю соцсетей в промежутке до пяти лет при запросе разрешения на въезд в Соединенные Штаты" — это тупо распространяющаяся тенденция, и скоро каждый силовик каждой страны посчитает своим долгом держать нос в личной переписке. А с учётом падения уровня жизни, половина этих чиновников станут сливать все найденные данные растущему криминалу.
Ещё небось и во въезде могут отказать, если у тебя действительно нет блога.
_>Похоже, уже пора почту и всякие "Валера, СТО" держать в мессенджерах и соцсетях "для предъявления", а для всего личного подбирать какое-то безопасное решение.
Похоже, пора уже предлагать услугу "ведение блога в социальных сетях для предъявкения на границе".
Здравствуйте, Stanislaw K, Вы писали:
K>>Кто-нибудь знает о чём речь?
SK>Речь о мессенджерах в которых сидит по 1.5 унылых анонима торгующих друг с другом наркотой и обменивающихся детским порном.
На всякий случай:
Статья 23
1. Каждый имеет право на неприкосновенность частной жизни, личную и семейную тайну, защиту своей чести и доброго имени.
2. Каждый имеет право на тайну переписки, телефонных переговоров, почтовых, телеграфных и иных сообщений. Ограничение этого права допускается только на основании судебного решения.
"Ты должен сделать добро из зла, потому что его больше не из чего сделать." Р.П. Уоррен
Здравствуйте, Khimik, Вы писали:
SK>>Речь о мессенджерах в которых сидит по 1.5 унылых анонима торгующих друг с другом наркотой и обменивающихся детским порном. K>На всякий случай: K>
Статья 23
K>1. Каждый имеет право на неприкосновенность частной жизни, личную и семейную тайну, защиту своей чести и доброго имени.
K>2. Каждый имеет право на тайну переписки, телефонных переговоров, почтовых, телеграфных и иных сообщений. Ограничение этого права допускается только на основании судебного решения.
Здравствуйте, hi_octane, Вы писали:
SK>>Речь о мессенджерах в которых сидит по 1.5 унылых анонима торгующих друг с другом наркотой и обменивающихся детским порном.
_>Увы, на сейчас наверное да. Но как-то от всего этого цифрового концлагеря пора дистанцироваться.
Я не знаю что должно произойти, чтобы (альтернативные мессенджеры) "взлетели", или хотя бы получили более-менее заметное распространение.
Вот никаких идей нет по этому поводу, абсолютно.
_>Сегодняшняя новость: "Таможенная и пограничная служба США теперь требует от путешественников из 42 стран с безвизовым режимом раскрывать историю соцсетей в промежутке до пяти лет при запросе разрешения на въезд в Соединенные Штаты" — это тупо
"да и черт с ним!"
_>Похоже, уже пора почту и всякие "Валера, СТО" держать в мессенджерах и соцсетях "для предъявления", а для всего личного подбирать какое-то безопасное решение.
В смысле "пора"? это нужно было делать сразу. и разумные люди так и делают с 1994 года.
Здравствуйте, Khimik, Вы писали:
SK>>Речь о мессенджерах в которых сидит по 1.5 унылых анонима торгующих друг с другом наркотой и обменивающихся детским порном.
K>На всякий случай:
K>
Статья 23
Ты действительно искренне полагаешь что я (или кто либо дугой) не знаком с этим Документом?
Данная, приведенная тобой цитата совершенно не несет того иллюзорного "смысла" который ты пытаешься в неё вложить.
Я, в очередной раз, скажу тебе — перед тем как с "умным" видом цитировать что либо, следует ознакомится с тем, что цитируешь.
Повторю эту фразу в развернутом виде:
В очередной раз, рекомендую тебе одеться, сходить в оффлайновый книжный магазин, зайти в отдел детской литературы и купить книжку "Основы Конституционного Права для малышей". Для защиты от перегрузки неподготовленного ослабленного ума, книжка поделена на отдельные брошюры — по одной теме в каждой. Полный набор брошюр обойдется тебе во вполне посильные рублей 300 примерно, может быть 500 в варианте полноцветной печать на плотной бумаге. В них в доходчивой форме, с иллюстрациями, объясняется то, что должен знать каждый перед тем как начнет читать Конституцию.
Здравствуйте, wl., Вы писали:
SK>>>Речь о мессенджерах в которых сидит по 1.5 унылых анонима торгующих друг с другом наркотой и обменивающихся детским порном. K>>На всякий случай: K>>
Статья 23
K>>1. Каждый имеет право на неприкосновенность частной жизни, личную и семейную тайну, защиту своей чести и доброго имени.
K>>2. Каждый имеет право на тайну переписки, телефонных переговоров, почтовых, телеграфных и иных сообщений. Ограничение этого права допускается только на основании судебного решения.
Прикольная новость. Но если речь именно о шифрование в месседжере, то вроде как все без исключения месседжеры используют шифрование? Я надеюсь что с программой Vipole есть что-то ещё, за что уцепились судьи. А журналисты всё переврали ради хайп-эффекта.
"Ты должен сделать добро из зла, потому что его больше не из чего сделать." Р.П. Уоррен
SK>Я не знаю что должно произойти, чтобы (альтернативные мессенджеры) "взлетели", или хотя бы получили более-менее заметное распространение. SK>Вот никаких идей нет по этому поводу, абсолютно.
А потом, по неизвестной причине, откажут во въезде. А причиной будет наличие учётки соцсети, не указанной в анкете. А учётку найдут простейшим сравнением "отпечатка пользователя".
Здравствуйте, Khimik, Вы писали:
K>Но если речь именно о шифрование в месседжере, то вроде как все без исключения месседжеры используют шифрование? Я надеюсь что с программой Vipole есть что-то ещё, за что уцепились судьи. А журналисты всё переврали ради хайп-эффекта.
а фиг его знает, как это работает. В WhatsApp когда на новом устройсте логинишься, вся история скачивается.
Тут вообще какой-то дурдом случился — залогинился на новом телефоне в WhatsApp, на старом телефоне выкинуло из учетки, я зарегистрировался на другой номер, захожу, а у меня там всё чаты от старой учетки, правда новые сообщения на новый номер уже не приходят, только на старый на другом телефоне.
то есть учетки не связаны, но вся переписка от другого аккаунта у меня есть
Здравствуйте, tapatoon, Вы писали:
T>Здравствуйте, Khimik, Вы писали:
K>>не читает
T>Очевидно, в искомом мессенджере должна быть фича по использованию пользовательского ключа шифрования
не обязательно. можно сделать и в обычном — у тебя и у друга есть секретный ключ, даже просто программа с зашитым ключем. пишешь в прогу текст, жмешь "зашифровать" результат копируешь в чат. друг вставляет этот мусор в программу, жмет "Расшифровать", читает текст. не очень удобно правда
Здравствуйте, L.K., Вы писали:
LK>А потом, по неизвестной причине, откажут во въезде. А причиной будет наличие учётки соцсети, не указанной в анкете. А учётку найдут простейшим сравнением "отпечатка пользователя".
При определенном раскладе, откажут во въезде, если учётку не найдут. Решат, что ты неучтённый профессиональный шпион
Здравствуйте, wl., Вы писали:
wl.>Здравствуйте, Khimik, Вы писали:
wl.>а фиг его знает, как это работает. В WhatsApp когда на новом устройсте логинишься, вся история скачивается. wl.>Тут вообще какой-то дурдом случился — залогинился на новом телефоне в WhatsApp, на старом телефоне выкинуло из учетки, я зарегистрировался на другой номер, захожу, а у меня там всё чаты от старой учетки, правда новые сообщения на новый номер уже не приходят, только на старый на другом телефоне. wl.>то есть учетки не связаны, но вся переписка от другого аккаунта у меня есть
вранье
Здравствуйте, Khimik, Вы писали:
K>Подскажите, какие сейчас существуют месседжеры, с которыми разработчик гарантирует, что сообщения в принципе никто не перехватывает и не читает. Я краем уха слышал про три таких: Status, Session, Adamant. Про их преимущества автор, которого я читал, писал так:
обычная почта с s/mime шифрованием подойдет ?
... Хорошо уметь читать между строк. Это иногда
приносит большую пользу
Здравствуйте, AndyCyp, Вы писали: wl.>>а фиг его знает, как это работает. В WhatsApp когда на новом устройсте логинишься, вся история скачивается. wl.>>Тут вообще какой-то дурдом случился — залогинился на новом телефоне в WhatsApp, на старом телефоне выкинуло из учетки, я зарегистрировался на другой номер, захожу, а у меня там всё чаты от старой учетки, правда новые сообщения на новый номер уже не приходят, только на старый на другом телефоне. wl.>>то есть учетки не связаны, но вся переписка от другого аккаунта у меня есть AC>вранье
нафига мне врать? Слева новый аккаунт (у него даже почта не проставлена, связи со старым нет), новый номер покупал этим летом, если вдруг кто-то подумает, что 10 лет назад я задумывал этот прикол, и писал одновременно с двух аккаунтов в одни и те же чаты
Скрытый текст
Качество плохое, снимал на абсолютно ублюдочный телефон
Здравствуйте, wl., Вы писали: K>>>не читает T>>Очевидно, в искомом мессенджере должна быть фича по использованию пользовательского ключа шифрования wl.>не обязательно. можно сделать и в обычном — у тебя и у друга есть секретный ключ, даже просто программа с зашитым ключем. пишешь в прогу текст, жмешь "зашифровать" результат копируешь в чат. друг вставляет этот мусор в программу, жмет "Расшифровать", читает текст. не очень удобно правда
Ну да, я собственно сам написал на Delphi такую программу. Если кто-то захочет, могу выслать и исходники и екзешник. Пока не взлетело, интерес не увидел.
Скрытый текст
"Ты должен сделать добро из зла, потому что его больше не из чего сделать." Р.П. Уоррен
Здравствуйте, Khimik, Вы писали: wl.>>не обязательно. можно сделать и в обычном — у тебя и у друга есть секретный ключ, даже просто программа с зашитым ключем. пишешь в прогу текст, жмешь "зашифровать" результат копируешь в чат. друг вставляет этот мусор в программу, жмет "Расшифровать", читает текст. не очень удобно правда K>Ну да, я собственно сам написал на Delphi такую программу. Если кто-то захочет, могу выслать и исходники и екзешник. Пока не взлетело, интерес не увидел. K>
Здравствуйте, Stanislaw K, Вы писали:
SK> Я не знаю что должно произойти, чтобы (альтернативные мессенджеры) "взлетели", или хотя бы получили более-менее заметное распространение. SK> Вот никаких идей нет по этому поводу, абсолютно.
Успешный мессенджер — это на 80% (а то и больше) его UI и UX. У альтернативных решений просто нет ресурсов на это. А так-то хороших идей полно (вплоть до "можно грабить корованы").
AB>Успешный мессенджер — это на 80% (а то и больше) его UI и UX. У альтернативных решений просто нет ресурсов на это. А так-то хороших идей полно (вплоть до "можно грабить корованы").
ICQ первых версий была безо всяких этих ваших XUI, прямоугольно-лапидарная, и попадающая точно в пикселы без разблуривания текста. И ей это нисколько не мешало.
Данное сообщение является художественным произведением и освещает вымышленные события в вымышленном мире. Все совпадения с реальностью являются случайными. Не является инвестиционной рекомендацией.
Здравствуйте, Osaka, Вы писали:
AB>>Успешный мессенджер — это на 80% (а то и больше) его UI и UX. У альтернативных решений просто нет ресурсов на это. А так-то хороших идей полно (вплоть до "можно грабить корованы"). O>ICQ первых версий была безо всяких этих ваших XUI, прямоугольно-лапидарная, и попадающая точно в пикселы без разблуривания текста. И ей это нисколько не мешало.
ну и где сейчас эта Ася? вроде бы его mail.ru купила, и похоронила, "не шмогла"
O>>ICQ первых версий была безо всяких этих ваших XUI, прямоугольно-лапидарная, и попадающая точно в пикселы без разблуривания текста. И ей это нисколько не мешало. wl.>ну и где сейчас эта Ася? вроде бы его mail.ru купила, и похоронила, "не шмогла"
Сначала была постоянная смена протокола (и подыхание сторонних клиентов), потом mail.ru приделали электроконцлагерную регистрацию по телефону.
Но это не проблемы отсутствия модно-актуальных свистоперделок.
Данное сообщение является художественным произведением и освещает вымышленные события в вымышленном мире. Все совпадения с реальностью являются случайными. Не является инвестиционной рекомендацией.
SK>Речь о мессенджерах в которых сидит по 1.5 унылых анонима торгующих друг с другом наркотой и обменивающихся детским порном.
А ещё они возят этосамое на автомобилях, режут хлеб ножами и дышат воздухом.
Данное сообщение является художественным произведением и освещает вымышленные события в вымышленном мире. Все совпадения с реальностью являются случайными. Не является инвестиционной рекомендацией.
Здравствуйте, wl., Вы писали:
wl.>думаю, что за пользование такой программой могут прийти люди в штатском ещё быстрее, чем за пользование Vipole.
Думаю, что без веских причин или хотя бы оснований надеяться, что найдут материалы для правдоподобного дела, к тебе никто не потащится.
И так полно всяких параноиков, которые считают, что за ними следят все спецслужбы мира.
А когда возьмешь такого за жабры — будет вести себя непредсказуемо, на таких карьеру не построишь.
wl.>думаю, что за пользование такой программой могут прийти люди в штатском ещё быстрее, чем за пользование Vipole.
при таком уровне паранойи (или надежде на такой её уровень у какой-то доли платежеспособной клиентуры) пора начинать писать/искать/(найти исходники и поменять криптоалгоритмы) подобную программку, только уже для стеганографического запрятывания сообщений внутрь (отправляемых в чат) картинок/роликов и т.п. (случайно выбираемых из твоего/своего архива картинок/роликов, как вариант) и для обратного распрятывания/расшифровки.
wl.>>>то есть учетки не связаны, но вся переписка от другого аккаунта у меня есть AC>>вранье
wl.>нафига мне врать? Слева новый аккаунт (у него даже почта не проставлена, связи со старым нет), новый номер покупал этим летом, если вдруг кто-то подумает, что 10 лет назад я задумывал этот прикол, и писал одновременно с двух аккаунтов в одни и те же чаты
восстановленный бакап?
ватсапп не хранит чаты на сервере, сообщения только в базе на клиенте.
K>1. Каждый имеет право на неприкосновенность частной жизни, личную и семейную тайну, защиту своей чести и доброго имени.
K>2. Каждый имеет право на тайну переписки, телефонных переговоров, почтовых, телеграфных и иных сообщений. Ограничение этого права допускается только на основании судебного решения.
Здравствуйте, wl., Вы писали:
wl.>Здравствуйте, Osaka, Вы писали:
AB>>>Успешный мессенджер — это на 80% (а то и больше) его UI и UX. У альтернативных решений просто нет ресурсов на это. А так-то хороших идей полно (вплоть до "можно грабить корованы"). O>>ICQ первых версий была безо всяких этих ваших XUI, прямоугольно-лапидарная, и попадающая точно в пикселы без разблуривания текста. И ей это нисколько не мешало.
wl.>ну и где сейчас эта Ася? вроде бы его mail.ru купила, и похоронила, "не шмогла"
Когда хотят убить — то покупают, чтобы закопать окончательно.
Здравствуйте, AndyCyp, Вы писали:
wl.>>>>то есть учетки не связаны, но вся переписка от другого аккаунта у меня есть AC>>>вранье
wl.>>нафига мне врать? Слева новый аккаунт (у него даже почта не проставлена, связи со старым нет), новый номер покупал этим летом, если вдруг кто-то подумает, что 10 лет назад я задумывал этот прикол, и писал одновременно с двух аккаунтов в одни и те же чаты
AC>восстановленный бакап?
Он вроде делает его на гуглодиск, под актуальным гуглоаккаунтом.
ПС. Я всегда отказываюсь настраивать бэкап, а в настройках сейчас не нашёл.
Тем не менее, при отключеном бэкапе, у меня сообщения не переносятсятся при смене телефона.
А ещё, у Самсунга есть свой собственный перенос данных с любого другого телефона просто то воздуху между телефонами.
Здравствуйте, AndyCyp, Вы писали:
wl.>>>>то есть учетки не связаны, но вся переписка от другого аккаунта у меня есть AC>>>вранье wl.>>нафига мне врать? Слева новый аккаунт (у него даже почта не проставлена, связи со старым нет), новый номер покупал этим летом, если вдруг кто-то подумает, что 10 лет назад я задумывал этот прикол, и писал одновременно с двух аккаунтов в одни и те же чаты AC>восстановленный бакап? AC>ватсапп не хранит чаты на сервере, сообщения только в базе на клиенте.
что значит не хранит? whatsapp можно одновременно запустить на мобиле и компе (в windows appstore например есть клиент) — попробуй его скачать и зайти в свой аккаунт, вся история восстановится. Для кого эти сказки, что whatapp ничего не хранит?
никакого бэкапа я не восстанавливал, просто зарегистрировал новый аккаунт, и появились чаты от прошлого. Слишком уж шифрование сквозное
Здравствуйте, Osaka, Вы писали:
O> ICQ первых версий была безо всяких этих ваших XUI, прямоугольно-лапидарная, и попадающая точно в пикселы без разблуривания текста. И ей это нисколько не мешало.
Если ты сделал что-то действительно революционное, то "угловатости" на старте тебе простят. Сегодня же мессенджер — это обыденность и масс-маркет (т.е. UI и UX "не хуже" — это просто базовый минимум).
Здравствуйте, wl., Вы писали:
wl.>что значит не хранит? whatsapp можно одновременно запустить на мобиле и компе (в windows appstore например есть клиент) — попробуй его скачать и зайти в свой аккаунт, вся история восстановится. Для кого эти сказки, что whatapp ничего не хранит?
Официальная позиция что не хранит. Когда менял телефон, то с WhatsApp приходилось возиться и переносить переписку.
Telegram вот сам подтягивает чаты автоматически с серверов (я секретными чатами не пользуюсь) и никто этого вроде не скрывает.
Технически при входе в WhatsApp с компа тебя просят связать устройства через QR-код. Вот переписка и может вытягиваться с телефона, а не хранилищ WhatsApp.
Ну, и явно хранит какое-то время текущие сообщения на случай, что у получателя телефон выключен или нет интернета пока и т.д. и т.п.
wl.>никакого бэкапа я не восстанавливал, просто зарегистрировал новый аккаунт, и появились чаты от прошлого. Слишком уж шифрование сквозное
Точно не восстанавливал? Ну, может там WhatsApp сохранил резурвную копию в Google Drive, а на новом устройстве используется та же гугловская учётка и из неё вытянулась резервная копия переписок?
Здравствуйте, Khimik, Вы писали:
K>Ну да, я собственно сам написал на Delphi такую программу. Если кто-то захочет, могу выслать и исходники и екзешник. Пока не взлетело, интерес не увидел.
Здравствуйте, Anton Batenev, Вы писали:
SK>> Я не знаю что должно произойти, чтобы (альтернативные мессенджеры) "взлетели", или хотя бы получили более-менее заметное распространение. SK>> Вот никаких идей нет по этому поводу, абсолютно.
AB>Успешный мессенджер — это на 80% (а то и больше) его
Его "абонентская база" = простая понятная удобная система имен (никнеймов). чтоб любой установивший себе мессенджер легко и просто нашел собеседников из своих контактов.
традиционно это или емэйл или очень простой псевдоним (скайп) или номер (аська) или номер телефона (ватсап,вибер,телега,макс..)
вся "альтернатива" на этом и "спотыкается" — например токс не взлетел потому что там невозможно найти человека.
Второй по важности вопрос — интерконнект. Связь из мессенджера с другими (чужими мессенджерами) — гейты в (и главное ИЗ) PSTN, скайп, аська, телега, ватсап, джабер, тимс, мастодон и все все все..
У альтернативы всё ещё хуже — нет интерконекта между собственными серверами, хочешь пообщаться с абонентом другого сервера — заводи себе там (ещё один) аккаунт.
AB>UI и UX. У альтернативных решений просто нет ресурсов на это.
Это дело шестнадцатое. Как только будет решен первый вопрос с поиском/обменом контактами найдутся бесплатные энтузиасты моддеры/дизайнеры, которые на добровольных началах, для строчки в резюме или forfun нарисуют десятки божественных UI.
AB>А так-то хороших идей полно (вплоть до "можно грабить корованы").
Ты весьма ограниченно понимаешь термин "шифрование".
Шифрование бывает на разных уровнях.
1) "все без исключения" используют его для того, чтобы постороннее третье лицо не могло легко прочитать (и изменить!) переписку.
например когда ты в кафе подключился к публичному wifi, этого не делал владелец роутера.
такое шифрование не скрывает текст от левой программы в телефоне и владельца сервера мессенджера и спецслужб.
2) чаще всего делают "сквозное шифрование" — когда сообщение (дополнительно к 1) шифруется "индивидуальным ключом" и передается по шифрованному 1) каналу в зашифрованном виде, в зашифрованном виде обрабатывается сервером, в зашифрованном виде передается по шифрованному 1) каналу адресату и расшифровывается на его устройстве.
это дает дополнительную защиту, от прочтения техническим персоналом сервера (но владелец сервера (и спецслужбы) все равно имеют возможность читать).
3) иногда сообщение шифруется "персональным ключом" (ты сам его задаешь) далее как в 2). с тем отличием что ни владелец сервера ни спецслужбы не могут прочитать (и изменить) сообщение.
Но у этот 3) вариант нежизнеспособен, по очевидным причинам. Знаешь каким?
Здравствуйте, Stanislaw K, Вы писали:
SK> вся "альтернатива" на этом и "спотыкается" — например токс не взлетел потому что там невозможно найти человека.
Вот конкретно у tox:
0) Руление проектом захватили не совсем адекватные люди, которые нашли "фатальный недостаток" у всех имеющихся наработок на тот момент (это если коротко, на самом деле там много "грустного веселья" было).
1) Сервис каталогов, который позволял бы найти человека по простому ID и получить его ключ, был. Его идею можно было спокойно развить до уровня, что обычный пользователь вообще бы не знал, что у tox там под капотом какой-то ключ. Его можно было бы прозрачно интегрировать в имеющийся протокол. А что сделали новые рулевые? Объявили deprecated, insecure и сломали всю имеющуюся совместимость (фактически похоронив функциональность).
Вне всякого сомнения человеко-читаемый ID — это база, но простой базы для успеха абсолютно недостаточно. Для примера можно посмотреть на signal где id — номер телефона, но это не особо-то влияет на популярность.
SK> Второй по важности вопрос — интерконнект. Связь из мессенджера с другими (чужими мессенджерами) — гейты в (и главное ИЗ) PSTN, скайп, аська, телега, ватсап, джабер, тимс, мастодон и все все все..
Интерконнект штука конечно интересная, но у двух лидеров на сегодня в виде WhatsApp и Telegram никакого интерконнекта нет и не будет (и как-то ничего, пользуются с удовольствием).
SK> AB>UI и UX. У альтернативных решений просто нет ресурсов на это. SK> Это дело шестнадцатое. Как только будет решен первый вопрос с поиском/обменом контактами найдутся бесплатные энтузиасты моддеры/дизайнеры, которые на добровольных началах, для строчки в резюме или forfun нарисуют десятки божественных UI.
На практике не находятся. Потому что это достаточно тяжелый и кропотливый труд.
На примере того же tox развитие всех клиентов остановилось на уровне "не падает и хорошо". Мобильные клиенты под Android (Antox) / iOS (Antidote) успели "умереть" еще при старом ядре (а с т.з. маркетинга для массового продукта приоритет должен быть "mobile first").
На примере куда как более популярного телеграма при его вроде бы открытом протоколе альтернативных клиентов нет даже для десктопа (несмотря на то, что на его десктопную версию без слез смотреть невозможно).
Здравствуйте, jamesq, Вы писали:
J>Насколько PGP надёжна и безопасна?
Уверен, что по всем статьям лучше, чем поделка ТС
Но я ни разу не видел, чтобы этим кто-то пользовался, хотя есть соответствующие плагины для почтовых клиентов и не нужно вручную копипастить.
wl.>нафига мне врать? Слева новый аккаунт (у него даже почта не проставлена, связи со старым нет), новый номер покупал этим летом, если вдруг кто-то подумает, что 10 лет назад я задумывал этот прикол, и писал одновременно с двух аккаунтов в одни и те же чаты
Ха, это что, опять Хлаоми? Еще в 2018 им приходилось через Гугл рога отрывать — эти китайские красавцы и красавицы кладут в бэкап и восстанавливают из бэкапа локальное хранилище ключей. Которое по определению не должно иметь такой возможности — приватный ключ вообще не имеет права покидать границы защищенной зоны.
Китайцы, блин, такие китайцы. Какое, к черту, шифрование, если можно приватные ключи читать программой бэкапа.
SK>> вся "альтернатива" на этом и "спотыкается" — например токс не взлетел потому что там невозможно найти человека.
AB>Вот конкретно у tox:
AB>0) Руление проектом захватили не совсем адекватные люди, которые нашли "фатальный недостаток" у всех имеющихся наработок на тот момент (это если коротко, на самом деле там много "грустного веселья" было).
С учетом того, что проект изначально создавался людьми с явно выраженной шизофренией (судя по поставленным целям и расставленным приоритетам) это было ожидаемо. Даже если бы проект не "захватили" другие люди, он в любом случае был бы остановлен, и вероятнее всего даже раньше.
AB>1) Сервис каталогов, который позволял бы найти человека по простому ID и AB>А что сделали новые рулевые? Объявили deprecated, insecure и сломали всю имеющуюся совместимость (фактически похоронив функциональность).
Старые рулевые непременно пришли бы к этому самостоятельно, и так же "внезапно".
AB>Вне всякого сомнения человеко-читаемый ID — это база, но простой базы для успеха абсолютно недостаточно. Для примера можно посмотреть на signal где id — номер телефона, но это не особо-то влияет на популярность.
А разве "сигнал" не зашкварился на сливе в АНБ?
SK>> Второй по важности вопрос — интерконнект. Связь из мессенджера с другими (чужими мессенджерами) — гейты в (и главное ИЗ) PSTN, скайп, аська, телега, ватсап, джабер, тимс, мастодон и все все все..
AB>Интерконнект штука конечно интересная, но у двух лидеров на сегодня в виде WhatsApp и Telegram никакого интерконнекта нет и не будет (и как-то ничего, пользуются с удовольствием).
Есть ограниченный интерконнект, когда из приложения можно позвонить в PSTN. за деньги подставив Caller_ID подставного чужого номера.
SK>> AB>UI и UX. У альтернативных решений просто нет ресурсов на это. SK>> Это дело шестнадцатое. Как только будет решен первый вопрос с поиском/обменом контактами найдутся бесплатные энтузиасты моддеры/дизайнеры, которые на добровольных началах, для строчки в резюме или forfun нарисуют десятки божественных UI.
AB>На практике не находятся. Потому что это достаточно тяжелый и кропотливый труд.
Миранда, пиджин и (тот клиент, которым я не пользуюсь) — есть выбор скинов (модов).
AB>На примере того же tox развитие всех клиентов остановилось на уровне "не падает и хорошо".
Современный "дизайн" это плоский монохромный вырвиглазный ужас "Material Design". Ты видел законченный вариант.
Если API программы позволяет сделать (обычно нет) и кто-то "одаренный" берется делать "не как у всех" — получается аляповатая анимированая вырвиглазная цыганщина с бегущими строками и банерами
AB>На примере куда как более популярного телеграма при его вроде бы открытом протоколе альтернативных клиентов нет
За отсутствием вкуса у дизайнеров, и скорбно малыми возможностями предоставляемыми программами, весь "дизайн" можно описать "такой-же, но другой" = изменен цвет. (заменен один из шрифтов или фоновая картинка — уже высший пилотаж, такое доступно только мэтрам).
Здравствуйте, wl., Вы писали:
wl.>не обязательно. можно сделать и в обычном — у тебя и у друга есть секретный ключ, даже просто программа с зашитым ключем. пишешь в прогу текст, жмешь "зашифровать" результат копируешь в чат. друг вставляет этот мусор в программу, жмет "Расшифровать", читает текст. не очень удобно правда
Сути эти не меняет. Ключ должен быть сгенерён юзером и известен только ему и его пиру(ам). Если бы я был параноиком и/или имел необходимость передавать секретную информацию, то только так.
Специалисты в криптограции есть? Я прав? Если нет, аргументируйте пожалуйста
Здравствуйте, tapatoon, Вы писали:
wl.>>не обязательно. можно сделать и в обычном — у тебя и у друга есть секретный ключ, даже просто программа с зашитым ключем. пишешь в прогу текст, жмешь "зашифровать" результат копируешь в чат. друг вставляет этот мусор в программу, жмет "Расшифровать", читает текст. не очень удобно правда T>Сути эти не меняет. Ключ должен быть сгенерён юзером и известен только ему и его пиру(ам). Если бы я был параноиком и/или имел необходимость передавать секретную информацию, то только так.
Кто шифрует, тот знает ключ, очевидно. Поэтому для параноиков работает как раз вариант wl.
Здравствуйте, SkyDance, Вы писали:
wl.>>нафига мне врать? Слева новый аккаунт (у него даже почта не проставлена, связи со старым нет), новый номер покупал этим летом, если вдруг кто-то подумает, что 10 лет назад я задумывал этот прикол, и писал одновременно с двух аккаунтов в одни и те же чаты SD>Ха, это что, опять Хлаоми? Еще в 2018 им приходилось через Гугл рога отрывать — эти китайские красавцы и красавицы кладут в бэкап и восстанавливают из бэкапа локальное хранилище ключей. Которое по определению не должно иметь такой возможности — приватный ключ вообще не имеет права покидать границы защищенной зоны.
Здравствуйте, karbofos42, Вы писали:
wl.>>никакого бэкапа я не восстанавливал, просто зарегистрировал новый аккаунт, и появились чаты от прошлого. Слишком уж шифрование сквозное K>Точно не восстанавливал? Ну, может там WhatsApp сохранил резурвную копию в Google Drive, а на новом устройстве используется та же гугловская учётка и из неё вытянулась резервная копия переписок?
Да точно, никогда не делаю никакие бекапы на телефонах, и не переношу данные между телефонами, чтобы не засирать новый этими бекапами. Единственное, что у них общее — учетка google телефона.
за эти 9 лет телефонов у меня как минимум 9 было, всегда история подтягивалась сама
wl.>что значит не хранит? whatsapp можно одновременно запустить на мобиле и компе (в windows appstore например есть клиент) — попробуй его скачать и зайти в свой аккаунт, вся история восстановится. Для кого эти сказки, что whatapp ничего не хранит?
угу — загрузится с телефона при пайринге дополнительного клиента. попробуй во время синхронизации отключить телефон от интернета. если бы загружалось с сервера, то все продолжит работу, правда?
wl.>никакого бэкапа я не восстанавливал, просто зарегистрировал новый аккаунт, и появились чаты от прошлого. Слишком уж шифрование сквозное
ну расскажи мне про устройство ватсапа — ничего, что я там работаю?
Здравствуйте, Stanislaw K, Вы писали:
SK>Здравствуйте, Khimik, Вы писали:
SK>2) чаще всего делают "сквозное шифрование" — когда сообщение (дополнительно к 1) шифруется "индивидуальным ключом" и передается по шифрованному 1) каналу в зашифрованном виде, в зашифрованном виде обрабатывается сервером, в зашифрованном виде передается по шифрованному 1) каналу адресату и расшифровывается на его устройстве. SK>это дает дополнительную защиту, от прочтения техническим персоналом сервера (но владелец сервера (и спецслужбы) все равно имеют возможность читать).
SK>3) иногда сообщение шифруется "персональным ключом" (ты сам его задаешь) далее как в 2). с тем отличием что ни владелец сервера ни спецслужбы не могут прочитать (и изменить) сообщение.
SK>Но у этот 3) вариант нежизнеспособен, по очевидным причинам. Знаешь каким?
тл др, генерим пару паблик-прайвит ключей, паблик раздаем всем. при отправке тебе сообщения, отправитель берет твой паблик ключ и шифрует сообщение им.
для расшифровки требуется прайвит ключ который не покидает твоего клиента, так что МиМ слушающие твой траффик могут перехватить сообщение, но не могут расшифровать так как твоего приватного ключа у них нет.
Здравствуйте, AndyCyp, Вы писали:
wl.>>никакого бэкапа я не восстанавливал, просто зарегистрировал новый аккаунт, и появились чаты от прошлого. Слишком уж шифрование сквозное AC>ну расскажи мне про устройство ватсапа — ничего, что я там работаю?
Ну тогда, можешь объяснить, как это случилось:
1) Авторизация на пустой мобилке скачивает всю историю — откуда? Если и правда с google drive, то где там посмотреть бекапы, в какой папке, или каким способом?
2) Почему после авто-разлогинивания и последующей регистрации нового аккаунта, у обоих аккаунтов оказалась одна история?
телефоны:
по пункту 1: OnePlus 11, ColorOS 15.0
по пункту 2: OnePlus 13, OxygenOS 16.0.1
то есть оба Андроиды, но первый с китайским душком
wl.>Ну тогда, можешь объяснить, как это случилось: wl.>1) Авторизация на пустой мобилке скачивает всю историю — откуда? Если и правда с google drive, то где там посмотреть бекапы, в какой папке, или каким способом? wl.>2) Почему после авто-разлогинивания и последующей регистрации нового аккаунта, у обоих аккаунтов оказалась одна история?
скорее всего это восстановление бакапа на уровне самого телефона, как указал камрад Скайдэнс.
Здравствуйте, AndyCyp, Вы писали:
wl.>>Ну тогда, можешь объяснить, как это случилось: wl.>>1) Авторизация на пустой мобилке скачивает всю историю — откуда? Если и правда с google drive, то где там посмотреть бекапы, в какой папке, или каким способом? wl.>>2) Почему после авто-разлогинивания и последующей регистрации нового аккаунта, у обоих аккаунтов оказалась одна история?
AC>скорее всего это восстановление бакапа на уровне самого телефона, как указал камрад Скайдэнс.
эх, жаль, что из apple ничего нет, так бы и там проверил, без гуглосервисов
Oppo, Xiaomi, Redmi, это все один и тот же BBK. Не удивлюсь, если эта оппа тоже весьма вольно трактует понятие "локального защищенного хранилища".
С хлаоми тогда вообще умора была — оно при "переносе" бэкапа на другой телефон перенесло даже пин-код, и биометрию (отпечаток пальца). Вот это был номер, мы чуть в осадок не выпали от такой вольности. Ы — security.
SK>А разве "сигнал" не зашкварился на сливе в АНБ?
signal — опен-сорс, ты как себе представляешь "слив данных в АНБ"?
А главное — зачем? Если кому-то из трехбуквенных потребуется посмотреть, о чем ты там трещишь, они не будут шерстить десятки мессенджеров, а просто возьмут скрины твоего телефона.
T>Специалисты в криптограции есть? Я прав? Если нет, аргументируйте пожалуйста
Скромно назовусь специалистом в этой области. Я хотя бы понимаю устройство протокола OWS вплоть до той кишочки, где один и тот же key material используется для signing и key agreement (кто понимает, тот понимает, о чем я).
Вся эта криптография и e2ee имеет значение только в том случае, если у тебя есть полный контроль над устройством. Всем стеком, в первую очередь включая устройства ввода-вывода, память и шины. Чего у обычных юзеров попросту нет.
AC>тл др, генерим пару паблик-прайвит ключей, паблик раздаем всем. при отправке тебе сообщения, отправитель берет твой паблик ключ и шифрует сообщение им.
Все несколько сложнее. По сути, это point-to-point соединения между каждыми двумя участниками (поэтому группы в whatsapp ограничены в размере — когда отправляешь сообщение в группу, нужно у _каждого_ участника группы запросить "а дай мне еще публичных ключей").
Один публичный ключ используется только один раз, для единственного сообщения. Ключи не реюзаются. Общая схема такова — периодически, сервер говорит клиенту "сгенерируй мне еще ключей". Клиент получает этот запрос, генерирует пачку ключей, хранит приватную часть у себя, публичные загружает на сервер. Потом, когда кто-то хочет отправить тебе сообщение, он говорит серверу — а дай-ка мне ключик, я хочу сообщение отправить, и сервер выдает ему (один или несколько) одноразовых ключей.
Все это, разумеется, не относится к каналам. Которые в whatsapp как раз больше похожи на группы в телеге в плане реализации (е2ее там нет).
Здравствуйте, SkyDance, Вы писали:
AC>>тл др, генерим пару паблик-прайвит ключей, паблик раздаем всем. при отправке тебе сообщения, отправитель берет твой паблик ключ и шифрует сообщение им.
SD>Все несколько сложнее. По сути, это point-to-point соединения между каждыми двумя участниками (поэтому группы в whatsapp ограничены в размере — когда отправляешь сообщение в группу, нужно у _каждого_ участника группы запросить "а дай мне еще публичных ключей").
SD>Один публичный ключ используется только один раз, для единственного сообщения. Ключи не реюзаются. Общая схема такова — периодически, сервер говорит клиенту "сгенерируй мне еще ключей".
я знаю, я объяснял упрощенную модель. Суть моего поста в том, что "загрузки чатов с сервера" там нет
Здравствуйте, SkyDance, Вы писали:
SD>Вся эта криптография и e2ee имеет значение только в том случае, если у тебя есть полный контроль над устройством. Всем стеком, в первую очередь включая устройства ввода-вывода, память и шины. Чего у обычных юзеров попросту нет.
Под контролем над устройством ты понимаешь то, что никто не хучит передачу данных?
Хорошо, если мы представим что телефон на опенсорсной Ubuntu Touch, мессенджер тоже опенсорный (то есть ключи не ворует и никуда не передаёт) и сообщения шифрует ключом пользователя, левого ПО нет. Можем такую конфигурацию считать гарантировано безопасной? Если нет, какие тут уязвимости?
Здравствуйте, SkyDance, Вы писали:
SK>>А разве "сигнал" не зашкварился на сливе в АНБ? SD>signal — опен-сорс, ты как себе представляешь "слив данных в АНБ"?
опенсорс? значит любой может взять исходники и поднять у себя в изолированной сети всю его инфраструктуру?
не, не сможет? маленький пустячок помешает?. нет полных исходников сервера... какая жаль.
SD>А главное — зачем? Если кому-то из трехбуквенных потребуется посмотреть, о чем ты там трещишь, они не будут шерстить десятки мессенджеров, а просто возьмут скрины твоего телефона.
затем, что скриншотами занимается другое ведомство? затем, что не нужно класть все яйца в одну корзину?
Здравствуйте, AndyCyp, Вы писали:
SK>>Но у этот 3) вариант нежизнеспособен, по очевидным причинам. Знаешь каким?
AC>почитай что ли на досуге как работает е2ее шифрование? AC>хотя бы тут популярно объясняется AC>https://vas3k.blog/blog/end_to_end_encryption/
Это слишком популярно.
AC>тл др, генерим пару паблик-прайвит ключей, паблик раздаем всем. при отправке тебе сообщения, отправитель берет
ГДЕ берет?
Нет. не так — давай с самого начала:
— где генерим?
— чем генерим?
— как эти ключи попадут в мессенджер?
Здравствуйте, Khimik, Вы писали:
K>Подскажите, какие сейчас существуют месседжеры, с которыми разработчик гарантирует, что сообщения в принципе никто не перехватывает и не читает. Я краем уха слышал про три таких: Status, Session, Adamant. Про их преимущества автор, которого я читал, писал так:
K>Абсолютная анонимность, бескомпромиссное Р2Р-шифрование; использование техник обфускации геолокации и прогон трафика через Tor; удаление из передаваемых сообщений метаданных; никаких требований к регистрации и сборов пользовательских данных; никакой слежки, никаких номеров мобильных и адресов электронных почт. Вся коммуникация живет онлайн, бок о бок с остальными объектами, фиксируемыми в блокчейне: криптовалютами, децентрализованными приложениями, NFT.
K>Но далее автор писал, что все эти три месседжера пока очень неудобные. Кто-нибудь знает о чём речь?
Смотря что считать децентрализацией, если криптографию — всегда должна присутствовать третья сторона которой доверяют абоненты. Даже если мы пересылаем симметричные ключи друг другу на почту, то третья сторона — это почтовые сервисы. В общем виде нужен удостоверяющий центр, который будет подписывать пару "открытый ключ — индикатор(email,phone,host и т.д)" тем самый подтверждая что предъявитель пары является владельцем индификатора.
Здравствуйте, 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),
нужно постоянно держать приложение включённым, оно постоянно создаёт траффик и сажает батарейку
за четыре часа.
Здравствуйте, Stanislaw K, Вы писали:
SK>2) чаще всего делают "сквозное шифрование" — когда сообщение (дополнительно к 1) шифруется "индивидуальным ключом" и передается по шифрованному 1) каналу в зашифрованном виде, в зашифрованном виде обрабатывается сервером, в зашифрованном виде передается по шифрованному 1) каналу адресату и расшифровывается на его устройстве. SK>это дает дополнительную защиту, от прочтения техническим персоналом сервера (но владелец сервера (и спецслужбы) все равно имеют возможность читать).
1) не факт, что имеют. не должны так-то. Где-то должно быть что-то похожее на протокол диффи-хеллмана.
Проблема в том, то он позволяет MITM. И перед началом переписки необходимо через какой-то другой канал
связи вообще проверить, чтоб друг у друга ключики-то одинаковые. Или использовать что-то вроде PGP.
Собственно PGP можно использовать даже с мессенджером Max... Остаётся вопрос распространения ключей.
И этот вопрос обычно старательно обходят везде. "У нас всё насмерть зашифровано". Но изначально ключи
передаёт сервер. Со всеми вытекающими.
2) В нормальной системе электронной коммуникации не должно быть единого сервера и точка.
Вот например в электронной почте -- его нет (если почта не на mail.ru).
В Jabber и т.п. -- может не быть. Даже в Matrix.
В SimpleX выглядит сомнительно.
" сделано для чего?
SD>Это для того, чтобы *КАЖДОЕ* сообщение шифровалось *ОТДЕЛЬНЫМ* ключом. Так что если кто-то смог взломать одиночный ключ, это никак не повлияло на все остальные (non-repudiation guarantee).
Это чтоб легче сделать MiTM. Очевидно же. Потому, что как теперь этот отдельный ключ вообще проверить, что он такой какой надо.
SK>>Чтобы исключить попытки передачи открытого ключа другим каналом связи, абоненты максимально запутались и не думали пытаться проверить, действительно ли ключ принадлежит стороне Б? SD>Говорю же, изучи хотя бы whitepapers, если исходный код слишком сложен для чтения.
Ничего нового не изобретено. Нужна третья сторона обязательно. Или второй канал связи.
Что обменяться ключами, проверить достоверность ключей, чтоб третья сторона предоставила
ключи или подписалась в их достоверности.
Здравствуйте, Khimik, Вы писали:
K>У меня сугубо дилетантский взгляд на эти вещи; мне казалось что здесь главное — обеспечить хранение сообщения на временном сервере. Если A хочет передать B сообщение, то либо он может сделать, если они оба соединились онлайн; либо же надо, чтобы был третий участник C — вначале A передаст C сообщение, а потом C передаст сообщение B. Никто не пробовал в роли C использовать дополнительный дешёвый смартфон, который ловит в квартире вайфай и больше ни для чего не используется?
Зачем так сложно. Есть DHT-сети позволяющие хранить (очень короткие) сообщения. Достаточные, чтоб
получатель проснулся и получил сообщение напрямую. А видеофильмы хранить бесплатно всё равно не будет.
Здравствуйте, SkyDance, Вы писали:
K>>У меня сугубо дилетантский взгляд на эти вещи; мне казалось что здесь главное — обеспечить хранение сообщения на временном сервере. Если A хочет передать B сообщение, то либо он может сделать, если они оба соединились онлайн; либо же надо, чтобы был третий участник C — вначале A передаст C сообщение, а потом C передаст сообщение B. Никто не пробовал в роли C использовать дополнительный дешёвый смартфон, который ловит в квартире вайфай и больше ни для чего не используется?
SD>Вместо С проще использовать некий централизованный сервис. Тот самый "сервер Signal".
Проблема централизованного сервера в том, то он:
1) знает кто и кому что-то передавал;
2) заблокирован роскомнадзором;
3) зачем-то требует номер телефона, почту с гмейла, хорошо хоть не фотку с паспортом в руках.
Проблема телефона C -- NAT. Нужен кто-то с белым IP, не одним IP а тысячами, не должно
быть единого владельца-юрлица, не должно быть никакой аутентификации, и вообще не понимающия
смысла передаваемых сообщений (и тем более содержимого).
DHT смотрится хорошо. Но по-хорошему здесь нужен ещё какой-то blockchain, чтоб за хранение/передачу
чужих сообщений приходилось платить. Иначе сразу проблема спама и проблема, что узлы содержать
некому, т.к. дорого.
Здравствуйте, SkyDance, Вы писали:
SD>Ты тоже из тех, кто "не знаю, но верую"?
Я из тех, кто удивляется когда одни и те же люди говорят, что в реальности нельзя и своему компу доверять, т.к. мало ли чего там в BIOS может быть, а потом рассказывают, что нужно верить чьим-то серверам.
SD>Нет, сервер signal не знает, кто тебе присылает сообщение, благодаря технике sealed sender: https://signal.org/blog/sealed-sender/
А по получателю и хранению сообщений что?
SD>Объясняю последний раз: совершенно не важно, что там есть на сервере. Он используется именно как роутер. Важно лишь то, что у тебя на клиенте. В отличие от многих других мессенджеров, клиент signal'а ты действительно можешь собрать сам, используя те средства, которым ты доверяешь.
"Роутер", через который клиенты обмениваются сертификатами, а потом и сообщениями, зашифрованными с использованием этих сертификатов.
Вообще не знаю зачем отдельные серверы разрабатывали, если там нет никакой особой логики обработки пакетов.
Поставили бы несколько роутеров от cisco и пусть люди безопасно общаются.
Здравствуйте, karbofos42, Вы писали:
K>Я из тех, кто удивляется когда одни и те же люди говорят, что в реальности нельзя и своему компу доверять, т.к. мало ли чего там в BIOS может быть, а потом рассказывают, что нужно верить чьим-то серверам.
еще раз:
доверять надо клиенту, а не серверу.
сервер занимается раутингом сообщений, при этом не зная что внутри сообщения написано изза шифрования.
еще раз для тех кто писатель а не читатель: ассиметричное шифрование решает проблему передачи ключа по публичному незашищенному каналу. Перехватывай публичный ключ на здоровье.
K>"Роутер", через который клиенты обмениваются сертификатами, а потом и сообщениями, зашифрованными с использованием этих сертификатов. K>Вообще не знаю зачем отдельные серверы разрабатывали, если там нет никакой особой логики обработки пакетов. K>Поставили бы несколько роутеров от cisco и пусть люди безопасно общаются.
как то сообщение зашифрованное должно дойти до получателя, верно?
вобщем смысла дальше объяснять не вижу, тем более вся информация доступна — и whitepapers и код и статьи. Проще же сказать вы все пи"дите вместо того чтобы учить матчасть.
fk0> Это чтоб легче сделать MiTM. Очевидно же. Потому, что как теперь этот отдельный ключ вообще проверить, что он такой какой надо.
Нет, оно не так работает. Я не стал вдаваться в детали на тему ratchet (чтобы не перегружать мозги не привыкших к криптографии собеседников), но — он там есть.
fk0> Ничего нового не изобретено. Нужна третья сторона обязательно. Или второй канал связи. fk0>Что обменяться ключами, проверить достоверность ключей, чтоб третья сторона предоставила fk0>ключи или подписалась в их достоверности.
Именно этот канал я и описал. QR-коды или сравнение фингерпринтов. Фингерпринты были в WhatsApp с самого начала e2ee (кто не помнит — e2ee в WhatsApp появилось далеко не сразу, в 2016 году, когда наняли Moxie для реализации именно этой фичи).
QR-коды появились сильно позже, уже не помню, когда, но не раньше 2018.
Я ведь уже объяснил про sealed sender. Вот что за воинствующее дилетантство опять?
fk0> 2) заблокирован роскомнадзором;
В случае с signal — истинно так. И это осознанное решение. Signal мог бы заняться противодействием, но Brian Acton категорически против, ибо считает, что нужно устанавливать разумные законы, а не пытаться их обойти. Это принципиальная позиция.
fk0> 3) зачем-то требует номер телефона, почту с гмейла, хорошо хоть не фотку с паспортом в руках.
Аутентификацию требует для защиты от спама. Публично доступные мессенджеры, увы, вынуждены решать эту проблему. Если тебе это мешает — поднимай свой сервер, устанавливай свои правила аутентификации.
fk0> Проблема телефона C -- NAT. Нужен кто-то с белым IP, не одним IP а тысячами, не должно fk0>быть единого владельца-юрлица, не должно быть никакой аутентификации, и вообще не понимающия fk0>смысла передаваемых сообщений (и тем более содержимого).
Без аутентификации невозможно бороться со спамом.
Все остальное уже реализовано.
fk0> DHT смотрится хорошо. Но по-хорошему здесь нужен ещё какой-то blockchain, чтоб за хранение/передачу fk0>чужих сообщений приходилось платить. Иначе сразу проблема спама и проблема, что узлы содержать fk0>некому, т.к. дорого.
K>Я из тех, кто удивляется когда одни и те же люди говорят, что в реальности нельзя и своему компу доверять, т.к. мало ли чего там в BIOS может быть, а потом рассказывают, что нужно верить чьим-то серверам.
Удивительно, да? Вот такой он, ИТ-мир, с криптографией! Да, ты можешь верить чьим-то серверам, потому что совершенно не важно, что они там делают. У тебя клиент с end-to-end encryption. Ты ведь не веришь всем роутерам интернета? Но TLS веришь, и осуществляешь платежи через Интернет.
Это ровно та же ситуация. Ты должен доверять локальному оборудованию. Доверять посредникам (серверам и прочему) не обязательно.
K>А по получателю и хранению сообщений что?
Про получателя известно, что он получил сообщение. Также известно, как это сообщение выглядело в зашифрованном виде.
K>Поставили бы несколько роутеров от cisco и пусть люди безопасно общаются.
И так тоже можно! Пользуйся PGP и передачей сообщений напрямую через UDP-датаграммы. Что, неудобно? Вот для удобства и делают "серверы", которые упрощают процесс.
Здравствуйте, SkyDance, Вы писали:
fk0>> 1) знает кто и кому что-то передавал;
SD>Я ведь уже объяснил про sealed sender. Вот что за воинствующее дилетантство опять?
Для меня очевидно, что это полный bullshit: сервер знает с какого адреса
и от какого клиента принимал сообщение. Пусть на условном конверте и нет адреса.
Где-то в сетях наподобии SimpleX это работало бы, если бы все сервера не принадлежали
одной организации. То же самое касается Tor и любых систем луковичного шифрования.
fk0>> 2) заблокирован роскомнадзором;
SD>В случае с signal — истинно так. И это осознанное решение. Signal мог бы заняться противодействием, но Brian Acton категорически против, ибо считает, что нужно устанавливать разумные законы, а не пытаться их обойти. Это принципиальная позиция.
Ну т.е. телепортироваться на другую планету, я так и понял. Ибо в Европе у них там Chat Control, например.
fk0>> 3) зачем-то требует номер телефона, почту с гмейла, хорошо хоть не фотку с паспортом в руках.
SD>Аутентификацию требует для защиты от спама. Публично доступные мессенджеры, увы, вынуждены решать эту проблему. Если тебе это мешает — поднимай свой сервер, устанавливай свои правила аутентификации.
Да я так и понял, что bullshit. Проблема спама тривиально решается введением платы
за передачу сообщений. Но нам масса организаций предлагает _бесплатный_ сервис (за чей счёт?),
но все почему-то требуют телефон, паспорт и т.п.
fk0>> DHT смотрится хорошо. Но по-хорошему здесь нужен ещё какой-то blockchain, чтоб за хранение/передачу fk0>>чужих сообщений приходилось платить. Иначе сразу проблема спама и проблема, что узлы содержать fk0>>некому, т.к. дорого.
SD>Проблема спама не решается без аутентификации.
Опять двадцать пять. Вот была сеть FIDO там паспорт не спрашивали.
Денег тоже не брали, но спама не было. Как же так?
В usenet спам есть, но проблема мне прекрасно понятна. Брали бы
не 5 долларов за 100000 сообщений, а сколько-нибудь крупную сумму...
Спам стал бы моментально экономически нецелесообразным. А заплатить
несколько долларов в день для обычного пользователя не смертельно.
Здравствуйте, SkyDance, Вы писали:
fk0>> Это чтоб легче сделать MiTM. Очевидно же. Потому, что как теперь этот отдельный ключ вообще проверить, что он такой какой надо.
SD>Нет, оно не так работает. Я не стал вдаваться в детали на тему ratchet (чтобы не перегружать мозги не привыкших к криптографии собеседников), но — он там есть.
Он подвержен MITM без инфраструктуры обмена ключами "out of band". А её нет.
Все эти мессенджеры пускают пыль в глаза, а в реальности там дыра. И гораздо
надёжней размещать зашифрованные GPG объявления на каком-либо аналоге BBS
(веб-форум, usenet, IRC, чятик на вебкаме...) Куда куча народа ходит и всё видно всем.
Кому не предназначено не прочитают. Понять кто читает, а кто просто пришёл
порнушку посмотреть -- невозможно.
fk0>> Ничего нового не изобретено. Нужна третья сторона обязательно. Или второй канал связи. fk0>>Что обменяться ключами, проверить достоверность ключей, чтоб третья сторона предоставила fk0>>ключи или подписалась в их достоверности.
SD>Именно этот канал я и описал. QR-коды или сравнение фингерпринтов.
Это всё работало только через голос в Z-fone им. Циммермана но до широкого появления нейросетей.
Сейчас чё угодно подделать можно, а другого канала -- нет. В чятике тем более.
Вот например, можно было бы пересылать фингерпринт в MMS-сообщении или в SMS.
У кого-то есть? Нет. Потому и нет.
Здравствуйте, SkyDance, Вы писали:
SD>Удивительно, да? Вот такой он, ИТ-мир, с криптографией! Да, ты можешь верить чьим-то серверам, потому что совершенно не важно, что они там делают. У тебя клиент с end-to-end encryption. Ты ведь не веришь всем роутерам интернета? Но TLS веришь, и осуществляешь платежи через Интернет.
SD>Это ровно та же ситуация. Ты должен доверять локальному оборудованию. Доверять посредникам (серверам и прочему) не обязательно.
Ну, вот при платежах в интернете мне нужно смотреть куда я номер банковской карты ввожу, не фишинговая ли там какая страница.
И в итоге остаётся только доверять, что сервер моего банка или какого-то шлюза не взломали и ввожу цифры на безопасной страничке, которая никому ничего не сольёт.
В Signal собеседники же не общаются напрямую p2p, а прогоняют все сообщения через серверы Signal.
Значит всё же придётся им доверять и надеяться, что там не собирают кто с кем переписывается, откуда подключается и т.д.
SD>Про получателя известно, что он получил сообщение. Также известно, как это сообщение выглядело в зашифрованном виде.
Еще про получателя наверно известен номер телефона, IP-адрес? А зашифровано сообщение теми сертификатами, которыми ранее через этот же сервер обменялись.
SD>И так тоже можно! Пользуйся PGP и передачей сообщений напрямую через UDP-датаграммы. Что, неудобно? Вот для удобства и делают "серверы", которые упрощают процесс.
Я не упарываюсь по безопасности, ни с кем секретных бесед не веду и не понимаю этой паранойи.
Но варианты, когда сам сгенерировал ключи, по альтернативному каналу передал публичный ключ собеседнику, мне видится безопаснее, чем когда один сервис пускает тебя по номеру телефона и весь обмен происходит через него.
Естественно, большинству людей лень будет вручную всё делать, им приятнее взять готовое решение, которое всё само делает, пусть и с компромиссами, снижающими их анонимность, безопасность переписки и т.п.
Но эти люди в большинстве своём и сами не знают от кого что скрывают и зачем.
Здравствуйте, AndyCyp, Вы писали:
SK>>Скажи еще, что я не могу посмотреть, сохранить их plain text (а заодно передать стороне Б открытый ключ другим каналом)? AC>подсмотреть ключ, имея доступ к твоему клиенту, не так сложно
Любой пользователь может это сделать в два клика, без установки сторонних приложений?
SK>>Код сервера открыт? SK>>Как мне убедится что сторона Б получит именно мой ключ (а я получу ключ именно стороны Б), а не сгенерированную сервером пару подложных ключей?
AC>простая логика подсказывает что если публичный ключ заменен на сервере, то твой оригинальный приватный ключ не может быть использован для дешифровки приходящих тебе сообщений
С чего бы вдруг "нет"?
<- подложный ключ Б <- оригинальный ключ Б
Абонент А <---------------------------> сервер <----------------------------> Абонент Б
оригинальный ключ А -> подложный ключ А ->
избежать этого возможно только если
ключи независмы от сервера (генерятся проверенным алгоритмом, в другом приложении, на другом устройстве, переносятся через airgap)
абоненты знают оригинальные ключи друг-друга (обмениваются ими по независимым каналами)
SK>>Чтобы исключить попытки передачи открытого ключа другим каналом связи, абоненты максимально запутались и не думали пытаться проверить, действительно ли ключ принадлежит стороне Б?
AC>я тебе прислал популярную статью но ты даже не попытался прочитать. там как раз объясняется зачем — на случай утечки ключа.
не мне. но я почитаю.
SK>>Можно еще вспомнить фееричную закладку в openssl, когда при определенном векторе генерились слабые/предопределенные ключи. Сколько лет её не замечали? AC>ты еще heartbleed вспомни.
Буду считать этот уклончивый ответ от разработчика ватсапа признанием наличия таких закладок.
AC>а вообще как правильно пишут, если тобой интересуются 3х буквенные агенства, то никакое шифрование не поможет, будут снимать данные напрямую с телефона. AC>шифрование в мессенджерах предназначено против массовой слежки, чтобы тащмайор не мог залогать сообщения присосавшись к каналу твоего мобильного оператора.
"тащмйор" относится к категории "стихийное бедствие", так что, в общем случае, мы, законопослушные политически лояльные граждане, защищаемся от утечки третьим лицам — коммерческим компаниям.
Особенно от компаний, которые делом доказали свою нечистоплотность.
Здравствуйте, SkyDance, Вы писали:
SK>>1) хочу свой корпоративный сервер onsite. Не хочу зависеть от чужой инфраструктуры (отказы чужих серверов, оплаты чужих каналов связи, сбоев чужого энергопитания, вандализма, боевых действий, нападения марсиан).
SD>Погоди-погоди. Я отвечал на вот этот вот вброс:
SK>>А разве "сигнал" не зашкварился на сливе в АНБ
SD>И ответил вполне конкретно и по делу. Нет, "сигнал" никуда не шкварился, и ты можешь это проверить прямо в их репозитории. Не надо тут уводить дискуссию на тему "я хочу свой сервер поднять".
За короткое время было арестовано несколько групп террористов и несколько уничтожено, все они пользовались сигналом на чистых одноразовых аппаратах, регулярно их меняя и т.д. и т.п.
Плюс некоторые косвенные признаки.
Бритва Оккама из всех версий оставляет слив данных "сигналом" (или вовсе — изначальная разработка мессенджера и контроль серверов людьми в погонах).
SK>>Пока у меня нет Знания что нечто безопасно — я верю/считаю это ненадежным (доступным третьим лицам).
SD>Мы, конечно, можем обсудить твои знания, но тогда давай делать это цивилизованно — без поливания грязью по типу "зашкварился на сливе".
Просто лень писать "цивилизованно", ибо эти три слова заменяют пять абзацев цивилизованных слов. И в пяти абзацах обязательно найдется несколько, которые оппоненту покажутся неправильными и дискуссия уйдет далеко в сторону.
SK>>это дает дополнительную защиту, от прочтения техническим персоналом сервера (но владелец сервера (и спецслужбы) все равно имеют возможность читать).
fk0> 1) не факт, что имеют. не должны так-то.
Формально, конечно, не должны бы. В реальном мире многое делается на "неформальных связях" и устных "беседах о патриотизме" с "весьма убедительными доводами".
fk0> Проблема в том, то он позволяет MITM.
Судя по описанию "кухни" ватсапа они этим целенаправленно занимаются.
И перед началом переписки необходимо через какой-то другой канал связи вообще проверить, чтоб друг у друга ключики-то одинаковые. Или использовать что-то вроде PGP.
А этому активно препятствуют.
fk0> Собственно PGP можно использовать даже с мессенджером Max... Остаётся вопрос распространения ключей. fk0> И этот вопрос обычно старательно обходят везде. "У нас всё насмерть зашифровано". Но изначально ключи
генерирует и
fk0> передаёт сервер. Со всеми вытекающими.
Здравствуйте, SkyDance, Вы писали:
SD>Проблема спама не решается без аутентификации.
Что касается спама, можно же в мессенджерах просто юзерам не принимать сообщения от чужих людей вне своего списка контактов. И тогда аутентификация не потребуется.
А можно её ещё сделать опциональной, и тогда вне списка контактов можно принимать ещё только сообщения от аутентифицированных пользователей.
fk0> Для меня очевидно, что это полный bullshit: сервер знает с какого адреса fk0>и от какого клиента принимал сообщение. Пусть на условном конверте и нет адреса.
Может, все-таки прочитаешь whitepaper?
Сервер может знать IP-адрес, с которого было осуществлено соединение. С этим ты поделать ничего не можешь. Но можешь применить три магические буквы, или Tor, или еще какой вариант сокрытия IP.
Сервер НЕ ЗНАЕТ от какого клиента было получено сообщение. Потому что при отправке сообщения с sealed sender клиент не аутентифицирован:
Without authenticating, hand the encrypted envelope to the service along with the recipient’s delivery token.
Отмечу, что в WhatsApp поддержка sealed sender отсутствовала (как минимум по состоянию на 2022 год), хотя один (ныне более не появляющийся) участник этого форума пытался уговорить начальство выдать инженеров для реализации. Видимо, безуспешно, и, скорее всего, под давлением "business need". Ибо фича сия все равно не изменит "народной молвы" и никак не повлияет на популярность. Иными словами, от гиков для гиков. В случае с signal ноги понятно откуда растут Но там весь продукт такой, по определению некоммерчесный и, само собой, убыточный.
fk0> Ну т.е. телепортироваться на другую планету, я так и понял. Ибо в Европе у них там Chat Control, например.
Как-то так, да. Нет в этом мире справедливости. Думаешь, Маск просто так на Марс хочет?
fk0> Да я так и понял, что bullshit. Проблема спама тривиально решается введением платы fk0>за передачу сообщений.
Нет, вот ты это серьезно? Платежи — это куда более сильный уровень идентификации и аутентификации. К тому же еще и очень много friction (как бы это по-русски объяснить). Сам факт требования какого угодно платежа увеличивает порог входа настолько, что количество пользователей падает на порядок-два (для массовых продуктов, у которых есть альтернативы). Можешь попросту забыть про подобные идеи.
fk0> Опять двадцать пять. Вот была сеть FIDO там паспорт не спрашивали. fk0>Денег тоже не брали, но спама не было. Как же так?
Давай не сравнивать "сеть из четырех калек" с продуктами на сотни миллионов юзеров. Это все равно что сравнивать надувной молоток с реальной ж/д кувалдой. Конечно, в FIDO спама не было — там НЕКОМУ было спамить. Когда появились пользователи, кому имело смысл спамить — тут же и спам появился.
Ты и сейчас можешь сделать "мессенджер" для себя и твоей семьи (собственно, я уже рассматриваю этот вариант чисто для семейного общения, с теми кто в России остался — потому что позвонить стало ну совсем сложно). Там спама не будет. Наверное, тебе там даже аутентификацию не потребуется приделывать, достаточно комбинации IP-адрес-порт. Неуловимый Джо.
Здравствуйте, SkyDance, Вы писали:
SK>>То есть, я не могу сгенерить ключи на доверенном устройстве и перенести их? SD>Ключи чего? Шифрования каждого отдельного сообщения? А в чем смысл этого мероприятия?
В чем смысл шифровать каждое отдельное сообщение другим ключом?
SD>Если ты не доверяешь клиенту whatsapp, какая разница, где ты генерируешь ключи, ведь клиент может их переслать тов. майору. А если доверяешь, то зачем отдельное устройство?
Не спешите! к этим вопросам мы обратимся позже.
SK>>Скажи еще, что я не могу посмотреть, сохранить их plain text (а заодно передать стороне Б открытый ключ другим каналом)? SD>Про какие именно ключи сейчас речь? Про ключи, идентифирующие конкретного клиента?
Зачем у вас много ключей, для большей путаницы?
SD>Передать открытый ключ — это пожалуйста, для того QR код и придуман. Берешь "сторону Б", сканируешь, и тем самым идентифицируешь "это сторона А".
Стоп, но ведь несколько выше ты утверждал что каждое сообщение идентифицируется другим, новым ключем. генерируемым на лету пачками.
Выходит, этот QR ничего не идентифицирует, иначе он должен постоянно меняться.
" сделано для чего? SD>Это для того, чтобы *КАЖДОЕ* сообщение шифровалось *ОТДЕЛЬНЫМ* ключом. Так что если кто-то смог взломать одиночный ключ, это никак не повлияло на все остальные (non-repudiation guarantee).
ну да, ну да.
SK>>Можно еще вспомнить фееричную закладку в openssl, когда при определенном векторе генерились слабые/предопределенные ключи. Сколько лет её не замечали?
SD>Сколько? И откуда такие точные знания, что вот там прямо-таки "закладка", а не банальное "не предусмотрели"?
Потому что изначально её не было, и она была внесена целенаправленно.
SK>>Вероятно у ватспа такого нет, ибо владея сервером это не требуется, но окончательно не исключаю. SD> SD>Плохо, когда отсутствие знаний заменяется "ибо верую!"
Не аргумент.
В данном случае знание можно получить только изучив исходники сервера, самостоятельно подняв его полнофункциональную копию локально.
Здравствуйте, jamesq, Вы писали:
J>Что касается спама, можно же в мессенджерах просто юзерам не принимать сообщения от чужих людей вне своего списка контактов. И тогда аутентификация не потребуется. J>А можно её ещё сделать опциональной, и тогда вне списка контактов можно принимать ещё только сообщения от аутентифицированных пользователей.
Включишь телефон, а тебя серверы мессенджера дудосить будут, т.к. клиенту сначала нужно получить сообщение, расшифровать его, и только после этого можно будет понять, что это спам и нужно выкинуть, а не пользователю показывать.
fk0> Он подвержен MITM без инфраструктуры обмена ключами "out of band". А её нет.
Точно нет? Зуб дашь?
Скрытый текст
Как думаешь, что там такое в URL'е?
fk0>Все эти мессенджеры пускают пыль в глаза, а в реальности там дыра. И гораздо fk0>надёжней размещать зашифрованные GPG объявления на каком-либо аналоге BBS fk0>(веб-форум, usenet, IRC, чятик на вебкаме...) Куда куча народа ходит и всё видно всем. fk0>Кому не предназначено не прочитают. Понять кто читает, а кто просто пришёл fk0>порнушку посмотреть -- невозможно.
РКН и не будет пытаться что-то понимать, заблокирует, и все тут. И порнушку, и вообще все подряд.
PGP — не мессенджер, а всего лишь шифрование. Это вообще не проблема, а фигня на постном масле. fk0> Это всё работало только через голос в Z-fone им. Циммермана но до широкого появления нейросетей. fk0>Сейчас чё угодно подделать можно, а другого канала -- нет. В чятике тем более.
"А если найду?" (С) fk0>Вот например, можно было бы пересылать фингерпринт в MMS-сообщении или в SMS. fk0>У кого-то есть? Нет. Потому и нет.
Ну а если все-таки НАЙДУ?!! Все это есть в signal. Если чего-то не хватает, ну сделай Pull Request.
Здравствуйте, karbofos42, Вы писали:
K>Включишь телефон, а тебя серверы мессенджера дудосить будут, т.к. клиенту сначала нужно получить сообщение, расшифровать его, и только после этого можно будет понять, что это спам и нужно выкинуть, а не пользователю показывать.
Не смертельное препятствие. Можно как-нибудь и его обойти. Хотя бы, например, позволить опционально фильтровать сообщения на сервере по списку контактов. Допустить послабления в шифровании, передавать открыто ID отправителя. И вообще — до DDoS ещё надо дожить, чтобы ты кому-то был бы нужен. По дефолту, можно и оставить возможность дудоса.
UPD. Только сейчас придумал. Можно сразу условиться, что из всего сообщения, первые N байт — зашифрованный заголовок с ID отправителя. От сервера в первую очередь передаётся только он. Всё сообщение не передаётся. Ну и клиент говорит серверу, какие сообщения нужны целиком, а какие можно отбросить.
Я вообще считаю, что миру нужен мессенджер, децентрализованный, без регистрации, полностью зашифрованный. Чтобы юзвери идентифицировали себя с помощью пары открытый/закрытый ключ. А в плане архитектуры, надо чтобы отдельно были бы клиенты, и отдельно т.н. базовые станции — суть сервера. И вот у каждого клиента была бы своя домашняя базовая станция, которая возможно бы крутилась на домашнем сервере юзверя. Или скажем, базовая станция, расположенная в интернете, и принадлежащая какому-то сообществу пользователей. Прям как почтовый сервер и почтовые клиенты.
Клиент общается исключительно со своей базовой станцией, а уже эти станции взаимодействуют между собой, роутя траффик, сохраняя всякие там сообщения, организуя синхронизацию между несколькими клиентами юзверя, организуя сетевые туннели, если нужно. Прям как почтовые сервера. Можно даже сделать так, чтобы до некоторых базовых станций можно было бы добраться через некоторые станции-посредники. Можно туннели через TOR делать. Можно делать endpoint-ы, точки контакта с некоторым базовыми станциями. Причём у станции может быть несколько endpoint-ов. В общем, нафантазировать можно много чего.
K>И в итоге остаётся только доверять, что сервер моего банка или какого-то шлюза не взломали и ввожу цифры на безопасной страничке, которая никому ничего не сольёт.
Именно так. На той стороне может быть и не банк вовсе, а тов. майор. Или шарлатаны.
K>В Signal собеседники же не общаются напрямую p2p, а прогоняют все сообщения через серверы Signal.
Суть "сквозного шифрования" (e2ee) как раз в том, чтобы установить ПРЯМОЙ канал взаимодействия между двумя peers. Для этого и осуществляется обмен публичными ключами. Это можно сделать разными способами. Например, при личной встрече сосканировать QR-код, в котором указан публичный ключ. Или поделиться этим ключом через e-mail, SMS, голубиную почту и прочие средства. Но для большинства обычных пользователей, не замороченных на таких деталях, куда проще воспользоваться каталогом на сервере, который по какому-либо другому признаку (например, телефонному номеру) выдаст тебе публичный ключ. Этот вариант тоже поддерживается signal/whatsapp.
K>Значит всё же придётся им доверять и надеяться, что там не собирают кто с кем переписывается, откуда подключается и т.д.
Я же давал ссылку на sealed sender. Эта техника позволяет избежать отслеживания "кто с кем переписывается" — есть только знание "кто-то отправил сообщение на такой-то адрес". Подключение, естественно, в любом случае будет отслеживаться. Но это уже забота клиента, использовать VPN, Tor или что там еще получится.
K>Еще про получателя наверно известен номер телефона, IP-адрес? А зашифровано сообщение теми сертификатами, которыми ранее через этот же сервер обменялись.
Какой-то идентификатор (номер телефона ли, или e-mail, зависит от мессенджера) получателя должен быть известен. IP-адрес получателя заранее известен быть не может, получатель может придти откуда угодно. Или вовсе никогда не появиться.
Каждое сообщение зашифровано отдельным ключом по схеме double ratcher. Читать whitepaper до просветления! Без понимания, как это работает, исходный код будет темным лесом. В дебри (SCKA, Triple Ratchet) лучше не лезть, это даже мне трудновато понимать и обсуждать, но signal вроде как уже поддерживает.
Читать до просветления. За пару дней можно вникнуть, и понять, что заниматься взломом нет смысла. Проще применить терморектальный криптоанализ, или установить жучок ниже уровнем (я ведь уже писал про скриншоты, да?)
K>Но варианты, когда сам сгенерировал ключи, по альтернативному каналу передал публичный ключ собеседнику, мне видится безопаснее, чем когда один сервис пускает тебя по номеру телефона и весь обмен происходит через него.
Именно это signal и делает. И whatsapp тоже (как минимум делал раньше, сейчас я не смотрю за происходящим). Ну неужели так сложно заглянуть, а? Даже апп можно не ставить. Если нет веры, то можно в исходники заглянуть и даже самостоятельно собрать.
K>Естественно, большинству людей лень будет вручную всё делать, им приятнее взять готовое решение, которое всё само делает, пусть и с компромиссами, снижающими их анонимность, безопасность переписки и т.п. K>Но эти люди в большинстве своём и сами не знают от кого что скрывают и зачем.
Все правильно — вот для них и сделан тот самый каталог, который по номеру телефона даст публичный ключ.
SK>За короткое время было арестовано несколько групп террористов и несколько уничтожено, все они пользовались сигналом на чистых одноразовых аппаратах, регулярно их меняя и т.д. и т.п. SK>Плюс некоторые косвенные признаки.
На этом месте стоит воскликнуть "ИБО ВЕРУЮ!!!111"
И сразу отметить, что в ящике пива 24 банки. И в сутках 24 часа — вот это уж никак не может быть совпадением!
SK>Бритва Оккама из всех версий оставляет слив данных "сигналом" (или вовсе — изначальная разработка мессенджера и контроль серверов людьми в погонах).
Ничего, что я лично знаю "изначальных разработчиков мессенджера"? Разве что Moxie тайный агент, и погоны у него тайные. Но вот как он смог на github все это провернуть, так чтоб вот прямо у всех под носом, и никто ничего не заметил.
Короче. Спорить с аргументами типа "я так вижу" при отсутствии знаний и желания оные получить, как я понимаю, бессмысленно. Все равно ж не убедить. Каким бы предметным ни был спор. Думаю, продолжать имеет смысл только после ознакомления с базовыми основами криптографии, а также протоколом. В конце концов, не так это и сложно, собрать клиента signal'а, и потыкать туда-сюда, по-отправлять сообщения.
SK>Судя по описанию "кухни" ватсапа они этим целенаправленно занимаются.
Что в лоб, что по лбу...
SK>И перед началом переписки необходимо через какой-то другой канал связи вообще проверить, чтоб друг у друга ключики-то одинаковые. Или использовать что-то вроде PGP. SK>А этому активно препятствуют.
О ДАААА! Настолько активно препятствуют, что даже прямо предлагают это делать. И оповещают при изменении ключей. Чтобы полностью воспрепятствовать оффлайновой проверке идентичности ключей.
Жаль, нет иконки "квадрупл фейспалм".
Но на будущее, прежде чем писать глупость, хотя бы попробуй в гугле поискать. Там есть ответы.
J>Что касается спама, можно же в мессенджерах просто юзерам не принимать сообщения от чужих людей вне своего списка контактов. И тогда аутентификация не потребуется.
Как это "не потребуется"? А как ты будешь ПОЛУЧАТЬ сообщения? Чтобы получить "сообщения получателю А", как минимум нужно аутентифицироваться как "А".
Если же речь только про ОТПРАВКУ сообщений, то, да, там можно без аутентификации — именно так и устроен sealed sender.
J>А можно её ещё сделать опциональной, и тогда вне списка контактов можно принимать ещё только сообщения от аутентифицированных пользователей.
И так тоже можно, соответствующая настройка имеется.
SK>В чем смысл шифровать каждое отдельное сообщение другим ключом?
Чтобы при взломе одного ключа шифрования все другие сообщения остались зашифрованными.
SK>Зачем у вас много ключей, для большей путаницы?
Потому что это РАЗНЫЕ ключи. Один ключ удостоверяет пользователя. Другой — сообщение.
SK>Стоп, но ведь несколько выше ты утверждал что каждое сообщение идентифицируется другим, новым ключем. генерируемым на лету пачками.
Правильно. Одно сообщение — один ключ.
SK>Выходит, этот QR ничего не идентифицирует, иначе он должен постоянно меняться.
Ключ ПОЛЬЗОВАТЕЛЯ — это НЕ ключ сообщения. Это ключ пользователя. Между ними есть связь — всегда можно проверить, был ли ключ сообщения сгенерирован вот этим пользователем. Более подробно см. https://signal.org/docs/specifications/doubleratchet/double ratchet
SK>ну да, ну да.
ИБО ВЕРУЮ!!! (С)
SD>>Сколько? И откуда такие точные знания, что вот там прямо-таки "закладка", а не банальное "не предусмотрели"? SK>Потому что изначально её не было, и она была внесена целенаправленно.
Да что за закладка-то хоть? Объясни, не томи. Что-то из очень свежего? Я только про xz знаю, что там кто-то пытался протащить уязвимость, и ему это (почти) удалось.
Кто, почему, и как (целенаправленно) внес? Хотя бы CVE номер приведи. А то я помню баг про IV, но там ни о каком "сознании" и речи не шло.
SK>В данном случае знание можно получить только изучив исходники сервера, самостоятельно подняв его полнофункциональную копию локально.
В самый последний раз спрашиваю. Если тебя end-to-end (клиент-клиент) шифрование, какая разница, что там делает сервер? Ну возьми и подними, даже можешь свой сервер написать. Это ничего не даст — ведь весь смысл е2ее как раз в том, чтобы верить серверу не требовалось. Все на клиенте.
J>Клиент общается исключительно со своей базовой станцией, а уже эти станции взаимодействуют между собой, роутя траффик, сохраняя всякие там сообщения, организуя синхронизацию между несколькими клиентами юзверя, организуя сетевые туннели, если нужно. Прям как почтовые сервера.
Вот на этом этапе все и ломается. Потому что chain of trust как-то нужно организовать. Где-то должен быть какой-то anchor, которому все доверяют. На настоящий момент таковыми является "список корневых сертификатов". Но как же ему верить, если нет возможности проверить, что там с ними творится.
Здравствуйте, SkyDance, Вы писали:
J>>Что касается спама, можно же в мессенджерах просто юзерам не принимать сообщения от чужих людей вне своего списка контактов. И тогда аутентификация не потребуется.
SD>Как это "не потребуется"? А как ты будешь ПОЛУЧАТЬ сообщения? Чтобы получить "сообщения получателю А", как минимум нужно аутентифицироваться как "А". SD>Если же речь только про ОТПРАВКУ сообщений, то, да, там можно без аутентификации — именно так и устроен sealed sender.
Ну ё-маё. Если мы говорим о мессенджерах типа Telegram, с неким центром, у которого работают сервера. Он может не требовать номера телефонов, а как по-старинке всё работало — username/password.
И вот каждый юзверь имеет некий никнейм с мессенджере, к которому шлют сообщения. С никнеймом связана пара username/password, и клиент мессенджера аутентифицируется на серверах по этой паре.
У тебя легко может быть несколько аккаунтов, несколько никнеймов, прям как раньше было.
Это чтобы принять сообщения. Чтобы отправлять — даже и никакого username/password не требуется.
Всё это было с электронной почтой годы назад. Всё работало.
J>>А можно её ещё сделать опциональной, и тогда вне списка контактов можно принимать ещё только сообщения от аутентифицированных пользователей.
Здравствуйте, SkyDance, Вы писали:
SD>Вот на этом этапе все и ломается. Потому что chain of trust как-то нужно организовать. Где-то должен быть какой-то anchor, которому все доверяют. На настоящий момент таковыми является "список корневых сертификатов". Но как же ему верить, если нет возможности проверить, что там с ними творится.
Ты очень туманно выражаешься. Совершенно понятно, что каждый клиент у себя имеет список контактов, к которым прилагаются их открытые ключи и реквизиты базовых станций, к которым эти контакты приписаны.
Очень легко проверяется, что твой контрагент действительно приписан к некоторой базовой станции БС. Ты отправляешь на БС сообщение для контрагента, в котором просишь подтвердить что он действительно приписан к БС. Контрагент должен ответить утвердительно, снабдив ответ цифровой подписью, публичный ключ которой тебе известен. Все базовые станции также идентифицируются своими парами открытых/закрытых ключей.
Клиент у себя отмечает, какой публичный ключ у базовой станции, к которой приписан контрагент.
Вот тебе и chain of trust. Опять же, все эти базовые станции могут просто передавать зашифрованные сообщения, не разбираясь в их содержимом. Им полагается знать только адреса получателя и их БС. Действует end-to-end шифрование.
Я исхожу из того, что каждый юзер доверяет своей базовой станции. В конце-концов, он может поднять её у себя дома. Может держать БС для друзей, человек на 100. Может работать БС одна на фирму. Идея в том, что клиент может включаться/выключаться, связь пропадать. А БС работает непрерывно.
Как юзвери изначально установят отношения — здесь не рассматривается. Они могут обменяться своими публичными ключами, а потом ещё сверить их хэши по стороннему каналу, чтобы избежать подмены через MITM-атаку.
А друг друга юзеры могут находить по DHT, которую поддерживают базовые станции.
В DHT в качестве key публикуется никнейм юзера или хэш никнейма, а в качестве value хранится открытый
криптоключ, которым идентифицируется юзер и ещё реквизиты его домашней базовой станции.
Ещё можно поддерживать дополнительную DHT, по которой можно искать сами базовые станции.
Хочу сказать, что выделенные базовые станции могут куда эффективнее обходить всяческие интернет-блокировки, чем клиенты. Особенно на смартфонах. Например, БС можно запустить на домашнем сервере, где ещё поднять VPN, подключить сервер к нескольким провайдерам сразу, сделать возможным доступ к БС с нескольких IP адресов. Имеются большие вычислительные мощности.
J>Вот тебе и chain of trust. Опять же, все эти базовые станции могут
Ты сейчас описал e-mail, не упомянув разве что поведение relay. У e-mail есть куча проблем, включая необходимость строить chain of trust через сторонние механизмы — в частности, DNS. Не знаю, доводилось ли тебе устанавливать, настраивать и админить почтовые серверы (мне — более чем, от сравнительно простого mailcow до полного зубодробильного MS Exchange). Вот когда там дойдешь до DKIM, станет понятно, откуда берется trust.
J>просто передавать зашифрованные сообщения, не разбираясь в их содержимом. Им полагается знать только адреса получателя и их БС. Действует end-to-end шифрование.
Если есть e2ee, то зачем все эти сложности? Какую проблему решаем? Судя по всему, проблему "сервер знает IP-адрес клиента". В таком варианте "БС" является ни чем иным как VPN сервером. Ты можешь добиться ровно такого же эффекта и с signal/whatsapp, — ходи на них через VPN, и будет у тебя всегда один и тот же IP.
J>Как юзвери изначально установят отношения — здесь не рассматривается.
Так и в чем смысл всего описанного зоопарка, если основная проблема не решена? Проблема распространения ключей и является, пардон май френч, ключевой. Именно там больше всего претензий — если ключи раздает какой-то "сервер" или "каталог", веры таким ключам нет. А если есть "сторонний канал", то есть и e2ee, и что уж там посередине — серверы, роутеры или что угодно еще — значения не имеет.
