Здравствуйте, 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>А можно её ещё сделать опциональной, и тогда вне списка контактов можно принимать ещё только сообщения от аутентифицированных пользователей.
Включишь телефон, а тебя серверы мессенджера дудосить будут, т.к. клиенту сначала нужно получить сообщение, расшифровать его, и только после этого можно будет понять, что это спам и нужно выкинуть, а не пользователю показывать.
