- комментарий 0:
From: Dmitri Zubko
Date: 2025-01-06 16:28:13Z
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Не критично отсутствие поддержки омемо в мкабере, когда
поддерживается GnuPG.
Профанити не поддерживает иные кодировки, кроме утф-8.
- --
6321 504A 60B9 FABB 91E2 0CA8 BACA D4F5 D183 2840
-----BEGIN PGP SIGNATURE-----
iHUEARYKAB0WIQR5XhoxefQv98ZU9+FxhheketsToQUCZ3wAngAKCRBxhheketsT
oZCJAQDu/0Xyts4wDzYa7LQko8vNO8tn8l3ea6GmSZZbt0duzQEA/CSlN25vN+Lu
8kGU1opF5v0YdSeA27UUTZBxOsPB4AA=
=mccT
-----END PGP SIGNATURE-----
- комментарий 1:
From: Sergey Matveev
Date: 2025-01-07 11:31:54Z
*** Dmitri Zubko [2025-01-06 19:11]:
>Не критично отсутствие поддержки омемо в мкабере, когда
>поддерживается GnuPG.
PGP и OTR/OMEMO/Signal/whatever заточены под сильно разные задачи.
* в PGP нет защиты от replay attack. Можно спокойно просто повторить
PGP сообщение в канале связи
* в PGP нет perfect forward secrecy -- компрометация долгоживущего ключа
приводит к компрометации *всех* ранее переданных "на нём" сообщений
* в PGP отсутствует deniability -- нельзя отрицать факт авторства над
отсылаемыми сообщениями
* в OMEMO есть double ratchet механизм, который в целом сильно сокращает
кол-во фактов использования одного и того же ключа
Можно ли жить с отсутствием защиты от replay, deniability и PFS?
Зачастую можно, лучше чем ничего. Но лично я бы предпочёл уж всюду
реализованный и поддерживаемый OTRv3. PGP плохо подходит под задачу IM.
Для серьёзных требований по безопасности отсутствие защиты от replay не
приемлемо. При наличии требований по максимальной нагрузке на ключи, как
почти везде требуется для ФСБшной сертификации например -- PGP,
аналогично, вовсе не подходит.
>Профанити не поддерживает иные кодировки, кроме утф-8.
Лично я не вижу здесь проблемы. Вот отстутствие UTF-8 это проблема.
А уж для XML-based протокола (громоздкого), в котором, вроде бы, ещё и
сжатие трафика применяется, смысла в других кодировках не вижу.
- комментарий 2:
From: Dmitri Zubko
Date: 2025-01-07 14:04:54Z
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Сегодня посмотрел на profanity чуть более внимательно.
1) Объявленный в мануале официальный сайт http://www.profanity.im оказался фуфлом.
{body}
{div id="target" style="opacity: 0"}{/div}
{script}window.park = "eyJ1d....";{/SCRIPT}
{script src="/bIWGfvdJP.js"}{/SCRIPT}
{/body}
2) OTR оказался невозможен между mcabber и profanity, хотя поддержка заявлена и скомпилирован он мэйнтейнером с требуемой библиотекой.
<b>jid</b> has requested an <a
href="https://otr.cypherpunks.ca/">Off-the-Record private conversation</a>.
However, you do not have a plugin to support that. See <a
href="https://otr.cypherpunks.ca/">https://otr.cypherpunks.ca/</a> for more
information.
3) Упал три раза - ошибка сегментации. Один раз упал в моё отсутствие.
4) О пренебрежении локальной кодировкой уже высказался.
- --
6321 504A 60B9 FABB 91E2 0CA8 BACA D4F5 D183 2840
-----BEGIN PGP SIGNATURE-----
iHUEARYKAB0WIQR5XhoxefQv98ZU9+FxhheketsToQUCZ300PQAKCRBxhheketsT
oY2NAQDe6MgTCQ1tm/sogMQeFDKfXPxjhTAVmg4XcGsMmK1T8AEArWht8tCi+1P5
J0yx1fpEKJCz2FOot/iL8DboS62KkAQ=
=kn1r
-----END PGP SIGNATURE-----
- комментарий 3:
From: Sergey Matveev
Date: 2025-01-07 14:56:59Z
*** Dmitri Zubko [2025-01-07 17:03]:
>1) Объявленный в мануале официальный сайт http://www.profanity.im оказался фуфлом.
Протухший домен. Видимо, когда-то его использовали, а потом переехали на
бесплатный github.io для хостинга статического сайта. А доменные
регистраторы на оставшемся домене как-раз любят свои JS-driven заглушки
делать.
>2) OTR оказался невозможен между mcabber и profanity, хотя поддержка заявлена и скомпилирован он мэйнтейнером с требуемой библиотекой.
Я не проверял, но точно ли явное форсированное включение OTR в обоих
клиентах не сработает? То сообщение, которое вы написали -- это штатное
сообщение сопровождающее запрос на инициализацию OTR сессии. Насколько
помню, оно сопровождается whitespace-ами особыми вроде бы, сигнализируя
противоположному клиенту о том, что это OTR. Не все клиенты поддерживают
whitespace намёки такие. Если клиент поддерживает, то вместо этого
сообщения он автоматом запускает OTR рукопожатие. Если же нет, то
предполагается, что человек самостоятельно запустит OTR.
У меня OTR работал и из irssi (который, в том числе, и через bitlbee с
XMPP соединялся) и из mcabber, и с Go реализацией в
github.com/agl/xmpp-client клиенте, а напротив были с дюжину разных
других клиентов (других людей). Вот реально ни разу не вспомню, чтобы,
если клиенты поддерживают OTRv3, то он бы не заработал. OTRv3 же даже и
на транспорт не полагается никак -- это прозрачно пересылаемые base64
закодированные сообщения. Не исключаю что profanity коряво сделан,
запросто. Но автоматический запуск сессии OTR точно не все поддерживают
и много где надо было явно руками этот процесс инициировать.
>3) Упал три раза - ошибка сегментации. Один раз упал в моё отсутствие.
Печально если он такой некачественный. Мой знакомый не один месяц им
пользуется с OMEMO и не писал что у него возникали проблемы. Впрочем, не
исключаю, что редкие падения он и не посчитал проблемой. А то консольных
XMPP клиентов по пальцам пересчитать можно, а чтобы ещё и с поддержкой
OMEMO...
Я же не долго смотрел на этот клиент, так как на практике я всё равно
XMPP не использую. Знакомых его использующих не осталось -- все
переехали в централизованные решения (Signal, Telegram, ...). А на
работе нам проще поднимать IRC, так как его возможностей хватает, а
поднять сервер можно даже без конфига, менее чем за минуту.
Вне работы поднимать XMPP сервер (089bf4d15b98749dc24ee1bb149c53e080e86837)
снова я пробовал, но оказалось, что многие сторонние серверы форсируют
применение TLS. И я не особо то против этого. Но при этом многие и
требуют чтобы сертификат прошёл валидацию через их цепочку доверия. Что
полностью ломает возможность общения федеративных серверов между собой.
Поднять свой сервер, который бы общался только (например) с jabber.ru --
можно. Но со многими зарубежными он уже не будет стыковаться, федерация
на глобальном уровне невозможна.
- комментарий 4:
From: Dmitri Zubko
Date: 2025-01-08 07:16:25Z
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
> * в PGP нет защиты от replay attack. Можно спокойно просто повторить PGP сообщение в канале связи
Данная атака требует благоприятные условия для своей реализации и упреждается дополнительным слоем шифрования, если атакующий - не админ XMPP сервера.
> * в PGP нет perfect forward secrecy -- компрометация долгоживущего ключа приводит к компрометации *всех* ранее переданных "на нём" сообщений
Скомпрометировать PGP ключ трудно, если его обладатель технически подкован. Одновременно с этим, PGP предлагает на выбор более одного алгоритма шифрования, а OTR ограничивается лишь надёжным пока AES.
> * в PGP отсутствует deniability -- нельзя отрицать факт авторства над отсылаемыми сообщениями
Отрицать нельзя, если ключ соотносится с конкретной личностью. А он может не соотноситься.
> Можно ли жить с отсутствием защиты от replay, deniability и PFS? Зачастую можно, лучше чем ничего. Но лично я бы предпочёл уж всюду реализованный и поддерживаемый OTRv3. PGP плохо подходит под задачу IM. Для серьёзных требований по безопасности отсутствие защиты от replay не приемлемо. При наличии требований по максимальной нагрузке на ключи, как почти везде требуется для ФСБшной сертификации например -- PGP, аналогично, вовсе не подходит.
Предпочтительно иметь в своём распоряжении несколько взаимно дополняемых инструментов для обеспечения безопасности электронных коммуникаций. На деле же, чаще всего, не представляет возможным воспользоваться хоты бы одним из них ввиду отсутствия такого у удалённого стороны. Поэтому в данном контексте стремление к высоким стандартами безопасности равносильно стремлению к недосягаемому возвышенному. Похвально, но мало продуктивно.
> >Профанити не поддерживает иные кодировки, кроме утф-8.
> Лично я не вижу здесь проблемы. Вот отстутствие UTF-8 это проблема.
UTF-8 и есть проблема, наличие которой предполагает profanity в качестве локали без альтернатив.
> >2) OTR оказался невозможен между mcabber и profanity, хотя поддержка заявлена и скомпили рован он мэйнтейнером с требуемой библиотекой.
>
> Я не проверял, но точно ли явное форсированное включение OTR в обоих клиентах не сработает? То сообщение, которое вы написали -- это штатное сообщение сопровождающее запрос на инициализацию OTR сессии. Насколько помню, оно сопровождается whitespace-ами особыми вроде бы, сигнализируя противоположному клиенту о том, что это OTR. Не все клиенты поддерживают whitespace намёки такие. Если клиент поддерживает, то вместо этого сообщения он автоматом запускает OTR рукопожатие. Если же нет, то предполагается, что человек самостоятельно запустит OTR.
Инициировал OTR вручную поочерёдно с обоих клиентов. Не происходит рукопожатие. Mcabber посылает "?OTRv23?" (это видно в окне profanity с комплейном на отсутствие плагина) или отвечает на инициативу строкой "?OTR:AAICAA"..., пишет "awaiting D-H key", но не получает желаемое.
Тестировал OTR между mcabber и mcabber, между mcabber и psi. В обоих случаях работало. Была мысль о кривой сборке. Собрал самостоятельно, но результат прежний.
>
> У меня OTR работал и из irssi (который, в том числе, и через bitlbee с XMPP соединялся) и из mcabber, и с Go реализацией в github.com/agl/xmpp-client клиенте, а напротив были с дюжину разных других клиентов (других людей). Вот реально ни разу не вспомню, чтобы, если клиенты поддерживают OTRv3, то он бы не заработал. OTRv3 же даже и на транспорт не полагается никак -- это прозрачно пересылаемые base64 закодированные сообщения. Не исключаю что profanity коряво сделан, запросто. Но автоматический запуск сессии OTR точно не все поддерживают и много где надо было явно руками этот процесс инициировать.
А вот с автоматическим включением PGP нет проблем.
>
> >3) Упал три раза - ошибка сегментации. Один раз упал в моё отсутствие.
>
> Печально если он такой некачественный. Мой знакомый не один месяц им пользуется с OMEMO и не писал что у него возникали проблемы. Впрочем, не исключаю, что редкие падения он и не посчитал проблемой. А то консольных XMPP клиентов по пальцам пересчитать можно, а чтобы ещё и с поддержкой OMEMO...
Я не разделяю восторг от OMEMO. Он же привносит собой поверхность для атаки своей привязкой к устройству. Этим может воспользоваться злоумышленник, выдавая себя за старого знакомого, который якобы обновил устройство или купил новое взамен вышедшего из строя. Ну, а если устройство оказалось в распоряжении злоумышленника, тогда ему не придётся выдумывать легенду.
> Вне работы поднимать XMPP сервер (089bf4d15b98749dc24ee1bb149c53e080e86837) снова я пробовал, но оказалось, что многие сторонние серверы форсируют применение TLS. И я не особо то против этого. Но при этом многие и требуют чтобы сертификат прошёл валидацию через их цепочку доверия. Что полностью ломает возможность общения федеративных серверов между собой. Поднять свой сервер, который бы общался только (например) с jabber.ru -- можно. Но со многими зарубежными он уже не будет стыковаться, федерация на глобальном уровне невозможна.
Федеративный потенциал XMPP мог бы раскрыться в полной мере, если админы исключи посредников в лице УЦ. Здесь организационное препятствие, а не техническое. Для его преодоления имеются все возможности.
- --
6321 504A 60B9 FABB 91E2 0CA8 BACA D4F5 D183 2840
-----BEGIN PGP SIGNATURE-----
iHUEARYKAB0WIQR5XhoxefQv98ZU9+FxhheketsToQUCZ34hxAAKCRBxhheketsT
oWr2AP4/19TDDIVXCTROyMj8A0cU5XMlaVcX6D/vGLbO187F4wEA9CgmC7LON69q
oXVRJt9eIPqBDJgxv1E3zhRrxTd2agc=
=GDMu
-----END PGP SIGNATURE-----
- комментарий 5:
From: Sergey Matveev
Date: 2025-01-08 09:31:30Z
*** Dmitri Zubko [2025-01-08 09:57]:
>> * в PGP нет защиты от replay attack. Можно спокойно просто повторить PGP сообщение в канале связи
>Данная атака требует благоприятные условия для своей реализации и упреждается дополнительным слоем шифрования, если атакующий - не админ XMPP сервера.
Да, я и говорю, что для защиты от replay нужно что-то дополнительное.
>Скомпрометировать PGP ключ трудно, если его обладатель технически подкован.
Трудно -- не означает "невозможно". А последствия будут фатальными.
Причём зачастую *обе* стороны переписки должны должным образом
заботиться о безопасности ключей.
>Одновременно с этим, PGP предлагает на выбор более одного алгоритма шифрования, а OTR ограничивается лишь надёжным пока AES.
Эта означает, что PGP гораздо более сложный протокол/формат и
предоставляет гораздо большую поверхность для атаки. В большинстве
случаев, возможность согласования/выбора алгоритма не является плюсом.
Мне тоже не нравится AES, ибо он медленный и хорошо "течёт" по побочным
каналам (требуется не мало технических усилий чтобы его безопасно
применять). Но одновременно с этим, AES наиболее криптографически
проанализированный алгоритм, не имеющий практических серьёзных атак
(если не смотреть на побочные каналы). Я бы выбирал ChaCha20, но и
серьёзных нареканий к AES по вопросам безопасности нет.
В OTRv3 то мне куда больше не нравится громоздкий медленный
трудно-реализуемый (безопасно) RSA. Когда-то моим аргументом против PGP
для IM-а тоже был факт использования RSA ключей, но, благо, сейчас можно
*25519 компактные использовать.
PS: дописываю "v3" потому что есть и OTRv4 протокол, пускай только на
бумаге, в котором существенные отличия.
>> * в PGP отсутствует deniability -- нельзя отрицать факт авторства над отсылаемыми сообщениями
>Отрицать нельзя, если ключ соотносится с конкретной личностью. А он может не соотноситься.
Но это не отменяет факта отсутствия deniability.
Связан ли ключ с личностью или нет -- это уже второй вопрос.
>Предпочтительно иметь в своём распоряжении несколько взаимно дополняемых инструментов для обеспечения безопасности электронных коммуникаций.
Зачем? Если есть грамотный инструмент, то зачем ещё что-то
дополнительное? Если инструмент требует дополнительных подпорок и
костылей, то значит он не очень хорошо выполняет поставленную перед ним
задачу. Не спорю -- иногда бывает проще сделать эти костыли, чем
полностью перерабатывать и изобретать новый инструмент, но костыль
останется костылём.
Если кто-то перепослал (replay) сообщение, то можно прямо в канале связи
попросить прислать например текущую дату-время, чтобы вынудить
противоположную сторону "сгенерировать" сообщение с ранее не виданным
содержимым. Is good enough решение, но костыль. Можно и руками PGP ключи
хоть после каждого сообщения менять, а потом ещё и MAC ключи (не помню
как точно устроен PGP, MDC и MAC в нём и возможно ли это) раскрывать:
вот и нечто похожее на PFS, deniability, key ratcheting и прочее.
А несколько "взаимно дополняемых инструментов" это звучит как "давайте
использовать два разных шифра: AES и Кузнечик" подход. Когда-то он
применялся. Но в мире криптографии давно поняли, что толку от него
никакого и на практике даже никакие трёхбуквенные организации его не
применяют (как минимум, наши и из США, насколько нам известно).
>На деле же, чаще всего, не представляет возможным воспользоваться хоты бы одним из них ввиду отсутствия такого у удалённого стороны. Поэтому в данном контексте стремление к высоким стандартами безопасности равносильно стремлению к недосягаемому возвышенному. Похвально, но мало продуктивно.
Как-раз таки OTR/OMEMO являются более простым и *доступным* шагом для
обеспечения безопасности. Пользователю не нужно иметь целую экосистему
ведения и учёта своих ключей. Программе не нужно иметь поддержку PGP,
который в разы более сложный по формату чем mono-cypher решения типа
OTR/OMEMO. Написать OTR/OMEMO реализацию с нуля (имя под рукой только
криптографические примитивы написанные) -- на порядок проще чем PGP.
Применение PGP требует очень хорошо подготовленной среды исполнения
из-за side channel атак, тогда как OTR/OMEMO/Signal/etc менее
чувствительны к этому (менее "текут", мало используют одни и те же ключи
для работы, даже симметричные). Иметь грамотного пользователя PGP -- вот
это почти недосягаемая вершина. А вот пользователь OTR/OMEMO/Signal/etc,
куда в больше безопасности из коробки, даже просто банально по размеру
кодовой базы необходимой для работы и необходимых от пользователя
телодвижений. В OTR* есть и SMP zero-knowledge аутентификация сторон,
где при грамотном несложном использовании, можно даже и не париться о
запоминании/ведении базы данных доверенных отпечатков ключей.
Аргумент с более простым порогом входа, а значит меньшей вероятностью
допустить ошибки, некоторые "развивают" и дальше и предлагают вообще
централизованное решение типа Signal, где при обнаружении проблем с
протоколом/софтом, централизованно могут заставить всех обновить свои
приложения, где не будет ситуации, когда у десятков процентов людей до
сих пор остаётся только SSLv3 и только 1Kbit RSA ключи. Но я, конечно
же, не считаю допустимым глобальную централизацию, но доля истины в этом
тоже есть и, скорее всего, пользователи Signal в основной массе своей из
коробки более защищены от всевозможных атак чем другие.
Не нужно пытаться доказать, что PGP лучше/хуже или считать что его
достаточно. Любую яму можно выкопать лопатой. Но не любую яму можно
выкопать экскаватором (маленькую например). PGP на практике и без всяких
PFS, key ratcheting и прочего, с одним единственным ключом на все случаи
жизни -- сойдёт для преобладающего большинства пользователей. Но это не
означает, что он не является объективно плохим (не очень подходящим)
инструментом для задачи интерактивного (online) протокола общения. Это
если рассматривать с криптографической точки зрения. Если посмотреть на
сложность софта необходимого для OTR или PGP, то последний почти всюду и
везде будет наихудшим вариантом из-за сложности самого формата и в целом
экосистемы. Если посмотреть на необходимую подготовку пользователя для
использования PGP, то, к сожалению, большинство с ним тоже не смогут
справиться, тогда как для OTR/OMEMO/etc порог вхождения небольшой.
Многие упрощения для пользователя возможны только из-за того, что
OTR/OMEMO/whatever выполняют очень узкоспециализированную задачу, вообще
требующую online канала связи (как минимум OTR). И я ещё даже не
вспоминаю тот факт, что сейчас по сути развитие PGP пошло по двум
несовместимым между собой путям: OpenPGP и LibrePGP.
Если у кого-то есть уже полностью работающая экосистема PGP совместно с
IM-ами, то возможно не стоит рваться менять это всё на более совершенное
(с криптографической и технической точек зрения) решение. Например TLS
1.3 всем хорош, грамотно спроектирован, более минималистичен, даже
сертификат при handshake шифрует, но это не означает что нужно
форсированно выкидывать TLS 1.2, если он уже работает и выполняет свои
задачи (новые задачи решать с его помощью точно не стоит). Но когда речь
про запуск всего этого с нуля, тем более когда есть выбор в виде
специализированных под эту задачу инструментов, то PGP был бы крайне
неразумным выбором. Для какого-нибудь ФСБ решение с PGP для IM-а бы было
неприемлемым вовсе, как минимум из-за нагрузок на ключи и отсутствия
защиты от replay -- в любом случае пришлось бы переделывать/костылить.
>UTF-8 и есть проблема, наличие которой предполагает profanity в качестве локали без альтернатив.
Я так и не понял в чём же с UTF-8 проблема.
>Тестировал OTR между mcabber и mcabber, между mcabber и psi. В обоих случаях работало. Была мысль о кривой сборке. Собрал самостоятельно, но результат прежний.
Я вот только что не поленился и решил тоже проверить из любопытства.
Проверял profanity:
https://profanity-im.github.io/tarballs/profanity-0.14.0.tar.gz
https://github.com/strophe/libstrophe.git e3d734c5ff84821da2f0632f733cad4d2a73d3f4
https://github.com/signalapp/libsignal-protocol-c.git 3a83a4f4ed2302ff6e68ab569c88793b50c22d28
libotr-4.1.1 собранный из моего BASS
и https://github.com/agl/xmpp-client.git 3030ad42ee2df255ffc108dc6d04893d9501c863
(это вообще реализация не использующая libotr, а написанном на чистом Go OTRv3).
Один подключился к @member.fsf.org, другой к @jabber.ru. В xmpp-client
сделал:
/otr-start ???@jabber.ru
* (12:00PM) New OTR session with ???@jabber.ru established
* (12:00PM) Fingerprint for ???@jabber.ru: 4c74ab1a9e3195cdb0233f2d773ca32cb79e8520
* (12:00PM) Session ID for ???@jabber.ru: 9f518664f82d6f85
* (12:00PM) Identity key for ???@jabber.ru is not verified. You should use /otr-auth or /otr-authqa or /otr-authoob to verify their identity
???@jabber.ru> прошло?
(Jan 8 12:04:39) ???@jabber.ru: всё тип топ
в profanity предварительно /otr gen, и тоже /otr start ???@member.fsf.org.
[главное окно]
12:00:25 - ???@member.fsf.org started an OTR session (2)
[второе окно]
11:58:05 - me: привет
11:58:19 - ???@member.fsf.org/f1qwxmqR: привет
11:58:40 - ???@member.fsf.org/f1qwxmqR: hello
11:59:33 - ???@member.fsf.org/f1qwxmqR: привет
12:00:00 - me: another
12:00:25 ! OTR session started (untrusted).
12:00:34 ~ ???@member.fsf.org/f1qwxmqR: прошло?
12:04:39 ~ me: всё тип топ
SMP и прочее не проверял. Всё заработало из коробки.
>А вот с автоматическим включением PGP нет проблем.
Как и с OTR на моей практике. А PGP, как минимум, реже поддерживается.
>Я не разделяю восторг от OMEMO. Он же привносит собой поверхность для атаки своей привязкой к устройству. Этим может воспользоваться злоумышленник, выдавая себя за старого знакомого, который якобы обновил устройство или купил новое взамен вышедшего из строя. Ну, а если устройство оказалось в распоряжении злоумышленника, тогда ему не придётся выдумывать легенду.
Привязка к "device" есть только из-за того, что, в отличии от OTR, OMEMO
может принимать сообщения и в offline. Он предварительно на сервер
отсылает набор заранее сгенерированных DH ключей. И device понятие
существует чтобы можно было идентифицировать получателя сообщений в
offline режиме. Никто не обязывает использовать этот функционал и никто
не мешает создавать множество ключей для одного устройства или вообще их
удалять после каждого общения.
Никто не отменяет необходимость защиты OMEMO ключей на устройстве. Если
злоумышленник может обойти защиту/пароль от OMEMO ключей, то что ему бы
помешало обойти защиту PGP ключей? Тут разницы нет никакой. Если
устройство с ключами скомпрометировано, то и PGP (если мы с ним
сравниваем?) ничем не поможет.
Во всех случаях, при любых подозрениях, человеку необходимо проводить
аутентификацию именно человека, а не противоположной ключевой пары.
Например задавать вопросы, который может знать только предполагаемый
собеседник. И только OTR имеет из коробки SMP протокол для безопасной
(с криптографической точки зрения) сверки строковых значений (ответов на
вопросы). В OMEMO это не завезли -- видимо, потому что посчитали слишком
параноидальным и сложным. В PGP это в принципе технически не реализуемо.
>Федеративный потенциал XMPP мог бы раскрыться в полной мере, если админы исключи посредников в лице УЦ. Здесь организационное препятствие, а не техническое. Для его преодоления имеются все возможности.
Мог бы. Технические возможности есть. И раньше федерация более чем
работала и я не видел проблем с соединением к другим серверам (конечно
же, кроме Google Talk-овских и закрытых экосистем VK.com, Facebook,
с которыми тоже любой XMPP клиент мог работать). Но организационно люди
вот сейчас на практике полностью похоронили возможность федерации.
- комментарий 6:
From: Sergey Matveev
Date: 2025-01-08 09:37:41Z
*** Sergey Matveev [2025-01-08 12:31]:
>Привязка к "device" есть только из-за того, что, в отличии от OTR, OMEMO
>может принимать сообщения и в offline.
Это, конечно же, уже tradeoff между удобством использования и
безопасностью. PFS от offline сообщений страдает. Но OMEMO не обязывает
отправлять заранее подготовленные DH ключи на сервер, тем самым форсируя
применение только online/интерактивного режима. Это с точки зрения
протокола. Как там клиенты позволяют этим управлять -- уже не знаю.
OTRv3 же вообще без компромиссов -- только online.
- комментарий 7:
From: Dmitri Zubko
Date: 2025-01-08 13:59:26Z
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
> >Скомпрометировать PGP ключ трудно, если его обладатель технически подкован.
>
> Трудно -- не означает "невозможно". А последствия будут фатальными. Причём зачастую *обе* стороны переписки должны должным образом заботиться о безопасности ключей.
Всё верно. Но посмотрим на это под другим углом зрения: цена атака обещает быть высокой, а цель должна представлять собой исключительный интерес. Я сомневаюсь в том, что пара шифропанков могут быть интересны кому-либо. Но если очень хочется почитать их переписку, то можно попробовать. Деньги на стол; результат не гарантирован.
> >Одновременно с этим, PGP предлагает на выбор более одного алгоритма шифрования, а OTR ограничивается лишь надёжным пока AES.
> Эта означает, что PGP гораздо более сложный протокол/формат и предоставляет гораздо большую поверхность для атаки. В большинстве случаев, возможность согласования/выбора алгоритма не является плюсом.
>
> Мне тоже не нравится AES, ибо он медленный и хорошо "течёт" по побочным каналам (требуется не мало технических усилий чтобы его безопасно применять). Но одновременно с этим, AES наиболее криптографически проанализированный алгоритм, не имеющий практических серьёзных атак (если не смотреть на побочные каналы). Я бы выбирал ChaCha20, но и серьёзных нареканий к AES по вопросам безопасности нет.
DES тоже казался стойким. Но нет ничего вечного.
Диверсификация алгоритмов шифрования является преимуществом, если верно утверждение Брюса Шнайера о преимуществе децентрализованных систем. Пусть в его примере с пачками денег и сейфами нформация будет деньгами, алгоритмы шифрования - сейфами. А далее всё по его тексту.
> >Предпочтительно иметь в своём распоряжении несколько взаимно дополняемых инструментов для обеспечения безопасности электронных коммуникаций.
>
> Зачем? Если есть грамотный инструмент, то зачем ещё что-то дополнительное? Если инструмент требует дополнительных подпорок и костылей, то значит он не очень хорошо выполняет поставленную перед ним задачу.
Потому, что не гарантировано наличие конкретного инструмента (PGP) у удалённой стороны, но может оказаться там другой (OTR). Как раз такая сторона присутствует в моём контакт-листе.
> Иметь грамотного пользователя PGP -- вот это почти недосягаемая вершина. А вот пользователь OTR/OMEMO/Signal/etc, куда в больше безопасности из коробки
Пользователь в безопасности, если соблюдают условие обеспечения безопасности - сверет отпечатки и/или выбрал надёжный секрет и хранят его в тайне. Низкий порог вхождения не располагает к этому, а значит таит в себе иллюзию безопасности. Какие у нас по статистике самые популярные секреты - "123456", "qwerty"?
> Если посмотреть на сложность софта необходимого для OTR или PGP, то последний почти всюду и везде будет наихудшим вариантом из-за сложности самого формата и в целом экосистемы. Если посмотреть на необходимую подготовку пользователя для использования PGP, то, к сожалению, большинство с ним тоже не смогут справиться, тогда как для OTR/OMEMO/etc порог вхождения небольшой. Многие упрощения для пользователя возможны только из-за того, что OTR/OMEMO/whatever выполняют очень узкоспециализированную задачу, вообще требующую online канала связи (как минимум OTR).
Вот поэтому у меня под рукой два инструмента - OTR и PGP.
> И я ещё даже не вспоминаю тот факт, что сейчас по сути развитие PGP пошло по двум несовместимым между собой путям: OpenPGP и LibrePGP.
Это очень плохо.
> >UTF-8 и есть проблема, наличие которой предполагает profanity в качестве локали без альтернатив.
>
> Я так и не понял в чём же с UTF-8 проблема.
profanity не поддерживает иные локали, кроме UTF-8. Нужен костыль для преобразования кодировки в окне profanity.
> Я вот только что не поленился и решил тоже проверить из любопытства.
> Проверял profanity:
> /otr-start ???@jabber.ru
> ???@jabber.ru> прошло?
> (Jan 8 12:04:39) ???@jabber.ru: всё тип топ
Между двумя profanity у меня тоже работает OTR.
> >Федеративный потенциал XMPP мог бы раскрыться в полной мере, если админы исключи посредников в лице УЦ. Здесь организационное препятствие, а не техническое. Для его преодоления имеются все возможности.
>
> Мог бы. Технические возможности есть. И раньше федерация более чем работала и я не видел проблем с соединением к другим серверам (конечно же, кроме Google Talk-овских и закрытых экосистем VK.com, Facebook, с которыми тоже любой XMPP клиент мог работать). Но организационно люди вот сейчас на практике полностью похоронили возможность федерации.
Стань авангардом федеративной революции. :-)
- --
6321 504A 60B9 FABB 91E2 0CA8 BACA D4F5 D183 2840
-----BEGIN PGP SIGNATURE-----
iHUEARYKAB0WIQR5XhoxefQv98ZU9+FxhheketsToQUCZ36EewAKCRBxhheketsT
oT9DAP90t25gJCSXx8QT+9RfymKG4h4PEcpzCZLKZtSOfqPXBQD8Cjtp9EgOTb3k
S2fhHR7KT6DV4ONXwbwma2P0156ErAM=
=RZ28
-----END PGP SIGNATURE-----
- комментарий 8:
From: Sergey Matveev
Date: 2025-01-08 14:32:24Z
*** Dmitri Zubko [2025-01-08 16:58]:
>Всё верно. Но посмотрим на это под другим углом зрения: цена атака обещает быть высокой [...]
Я не обсуждаю цену или возможность практической атаки. Не спорю что в
случае с IM-ом реализуемость replay атаки (чтобы человек "поверил" в
сообщение) имеет цену. Но в хорошем криптографическом протоколе просто
имеется эта базовая простая защита (например используя nonce-ы) от этой
атаки. PGP не создаёт протокол/сессию с подобной защитой. Это плохо, с
криптографической точки зрения? Плохо. Приемлемо ли может быть на
практике? Может быть да. В грамотно спроектированном протоколе была бы
возможна replay атака? Никогда. Не очень подходящие, неграмотные решения
тоже могут быть использованы на практике, особенно если нет возможности
легко и просто воспользоваться чем-то более адекватным.
>DES тоже казался стойким. Но нет ничего вечного.
А примеры кроме DES или RC4 можете ли привести? Уже прошло не одно
десятилетие и криптография существенно продвинулась вперёд. Многое
сейчас делается сильно иначе чем 20-30 лет назад (посмотреть на тот же
TLS 1.3).
Насколько известно, DES никогда не "казался" стойким. На тот момент были
запреты на использование сильных алгоритмов, которые бы не смогли (хотя
бы в теории) поломать. DES был is good enough на *тот* момент для
коммерческого использования, удовлетворительным для ограничений на длину
ключа. Очевидно, что 56-бит ключ более чем возможно перебрать brute
force-ом на компьютерах чуть отдалённого будущего. Нигде не говорилось,
что DES безопасен всерьёз.
А вот RC4 (с достаточной длиной ключа) уже имел серьёзные шансы на
серьёзное использование. Но да, оказался так себе.
Собственно, с того момента, мне не известно о проблемах в каких-либо
иных шифрах. DES быстро поменялся на 3DES, с которым нет практических
проблем, который, грубо говоря, просто увеличивает длину ключа в два
раза. Затем появился AES. Даже MD5 в составе HMAC-а безопасен для
применения. В теории, гибкость выбора алгоритмов это не плохо. На
практике же основная проблема и боль это корявые руки программистов и
сложности создания криптографических протоколов. Лишний код -- лишняя
поверхность для атак, которая постоянно и атакуется. Тогда как конечные
криптографические примитивы (будь это хоть Blowfish или MD5) -- нет.
>Диверсификация алгоритмов шифрования является преимуществом, если верно утверждение Брюса Шнайера о преимуществе децентрализованных систем.
Я много чего у него читал, но не помню о каких деньгах и сейфах идёт
речь. Да и какая взаимосвязь между децентрализованными системами и темой
гибкости выбора алгоритмов шифрования? И я не помню чтобы Шнайер явно
одобрял гибкость протоколов (как и не помню чтобы критиковал это).
Плюс некоторые вещи у него от редакции к редакции меняются: когда-то он
рекомендовал CTR режим шифрования для блочных шифров, так как он
объективно технически всем хорош. Затем он поменял своё мнение и начал
рекомендовать банальный CBC, ибо кривые руки программистов это самое
страшное что может быть. Цена ошибки при реализации CBC -- ниже чем у
фатальности CTR. Точно так же прежде вовсю использовали ASN.1 в мире
криптографии, а теперь мы видим, как за десятилетия продолжаются
находится ошибки связанные с сложным кодом кодека ASN.1. Так же как и
многие современные протоколы связи существенно меньше предоставляют
пространства для манёвров выбора/согласования алгоритмов. Есть теория, а
есть практика и опыт, которые в мире криптографии существенно
пополнились за последние десятилетия. Криптоанализ и верификация не
гибких протоколов существенно проще, и на практике уже давным давно
конечные криптографические примитивы ("проверенные" временем, не то что
ML-KEM/Kyber какой-нибудь новенький) не являются проблемой. В
преобладающем большинстве случаев проще и гораздо надёжнее полностью
поменять протокол связи и используемые в нём алгоритмы, без какой-либо
обратной совместимости -- это не порождает колоссальное поле для атак
из-за сложности протокола/софта.
>Потому, что не гарантировано наличие конкретного инструмента (PGP) у удалённой стороны, но может оказаться там другой (OTR). Как раз такая сторона присутствует в моём контакт-листе.
А если у удалённой стороны нет ни того, ни другого, но есть возможность
создания ZIP архивов запароленных? Я не понимаю зачем рассматривать
ситуацию когда у собеседников просто навсего нет нужного софта. И
запароленный ZIP гораздо лучше будет чем совсем ничего. Но смысл
рассматривать и оценивать подобное решение? Аналогично и с PGP.
>Пользователь в безопасности, если соблюдают условие обеспечения безопасности - сверет отпечатки и/или выбрал надёжный секрет и хранят его в тайне.
>Низкий порог вхождения не располагает к этому, а значит таит в себе иллюзию безопасности. Какие у нас по статистике самые популярные секреты - "123456", "qwerty"?
Я не понимаю какая взаимосвязь между низким порогом вхождения, силы
паролей (парольных фраз) и необходимостью их использования. Само собой
парольные фразы должны быть сильными, само собой тайными. Если PGP
ключница защищается слабыми фразами, то ключи легко компрометируются.
Тут невозможно сделать порог вхождения меньше, без вреда безопасности.
Но для использования PGP необходимо ещё и следить не только за
отпечатками, но и за web-of-trust-ом нередко, следить за подключами,
временем их протухания, способами обнаружения, обновлениями и прочему
прочему прочему. OTR ключи же -- просто ключи, с отпечатками, без
времени жизни, без подключей, без сложной системы передачи доверия и
тому подобному. Для целей IM-а простота OTR/OMEMO не несёт вреда. Ибо
это узкоспециализированная задача.
>Вот поэтому у меня под рукой два инструмента - OTR и PGP.
Ну... ok. Разные инструменты для разных задач.
>profanity не поддерживает иные локали, кроме UTF-8. Нужен костыль для преобразования кодировки в окне profanity.
А зачем поддерживать иные кодировки? Я понимаю что ответом может быть
"потому что у меня другая кодировка", но я не понимаю в чём проблема
использовать UTF-8? На одной чаше весов "UTF-8 everywhere", а на другой
-- существенно более сложный софт с функционалом перекодирования данных,
что ещё одна дополнительная поверхность для атак.
>Между двумя profanity у меня тоже работает OTR.
Между двумя profanity я не проверял. Я написал что проверял между Go
клиентом agl/xmpp-client и profanity. И тот и тот используют команды
начинающиеся с "/otr" (как и irssi, насколько помню).
>Стань авангардом федеративной революции. :-)
99.99% людям это нафиг не нужно. Когда-то я был увлечён всей этой
шифропанковской тематикой, децентрализованным и федеративным софтом,
overlay сетями, censorship-resistant решениями, анонимизацией и прочими
вещами. Наскучило и надоело.
- комментарий 9:
From: Dmitri Zubko
Date: 2025-01-09 09:09:55Z
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
> >Всё верно. Но посмотрим на это под другим углом зрения: цена атака обещает быть высокой
> [...]
>
> Я не обсуждаю цену или возможность практической атаки. Не спорю что в случае с IM-ом реализуемость replay атаки (чтобы человек "поверил" в сообщение) имеет цену. Но в хорошем криптографическом протоколе просто имеется эта базовая простая защита
Данному аргументу место в wish-листе программной реализации криптографического протокола.
Я считаю целесообразным учитывать фактор цены атаки при определении модели угроз. Предпосылка известна: нет желающих кипятить океан с риском остаться без штанов. Но именно это в миниатюре представляет собой мало опасная и трудно реализуемая атака replay.
> >DES тоже казался стойким. Но нет ничего вечного.
>
> А примеры кроме DES или RC4 можете ли привести? Уже прошло не одно десятилетие и криптография существенно продвинулась вперёд. Многое сейчас делается сильно иначе чем 20-30 лет назад (посмотреть на тот же TLS 1.3).
Пока я не могу привести примеры, но могу предположить, что они не заставят долго ждать себя в пост-квантовую эпоху.
> >Диверсификация алгоритмов шифрования является преимуществом, если верно утверждение Брюса Шнайера о преимуществе децентрализованных систем.
>
> Я много чего у него читал, но не помню о каких деньгах и сейфах идёт речь. Да и какая взаимосвязь между децентрализованными системами и темой гибкости выбора алгоритмов шифрования?
https://pgpru.com/biblioteka/osnovy/setjdoverija
Пусть в этом примере информация будет деньгами, а алгоритмы шифрования - сейфами.
> >Потому, что не гарантировано наличие конкретного инструмента (PGP) у удалённой стороны, но может оказаться там другой (OTR). Как раз такая сторона присутствует в моём контакт-ли сте.
>
> А если у удалённой стороны нет ни того, ни другого, но есть возможность создания ZIP архивов запароленных? Я не понимаю зачем рассматривать ситуацию когда у собеседников просто навсего нет нужного софта. И запароленный ZIP гораздо лучше будет чем совсем ничего. Но смысл рассматривать и оценивать подобное решение? Аналогично и с PGP.
Здесь я не "рассматривать ситуацию когда у собеседников просто навсего нет нужного софта". Вместо этого мной перечислен на выбор софт для установления защищённого канала связи. Как я уже дал понять выше, такая практика оправдала себя.
> >Пользователь в безопасности, если соблюдают условие обеспечения безопасности - сверет отпечатки и/или выбрал надёжный секрет и хранят его в тайне.
> >Низкий порог вхождения не располагает к этому, а значит таит в себе иллюзию безопасности. Какие у нас по статистике самые популярные секреты - "123456", "qwerty"?
>
> Я не понимаю какая взаимосвязь между низким порогом вхождения, силы паролей (парольных фраз) и необходимостью их использования. Само собой парольные фразы должны быть сильными, само собой тайными. Если PGP ключница защищается слабыми фразами, то ключи легко компрометируются. Тут невозможно сделать порог вхождения меньше, без вреда безопасности.
Чем ниже порог вхождения, тем хуже навыки среднестатистического входящего. Отсюда злостное пренебрежение мерами обеспечения безопасности и тот самый человеческий фактор - подарок случая злоумышленнику.
> >profanity не поддерживает иные локали, кроме UTF-8. Нужен костыль для преобразования кодировки в окне profanity.
>
> А зачем поддерживать иные кодировки? Я понимаю что ответом может быть "потому что у меня другая кодировка", но я не понимаю в чём проблема использовать UTF-8? На одной чаше весов "UTF-8 everywhere", а на другой -- существенно более сложный софт с функционалом перекодирования данных, что ещё одна дополнительная поверхность для атак.
Другая чаша весов пустая по причине отсутствия там profanity, если не брать во внимание кратковременный период знакомства с ним. Осталась чаша UTF-8 everywhere.
HTTPS тоже everywhere, но при этом blog.stargrave.org доступен только по HTTP. Я не подвергаю сомнению обоснованность отказа от HTTPS, но лишь констатирую факт противоречия в суждениях. Если everywhere является решающим аргументом, то нужно во всём руководствоваться таким аргументом. В противном случае получается двойной стандарт, а это не красиво.
- --
6321 504A 60B9 FABB 91E2 0CA8 BACA D4F5 D183 2840
-----BEGIN PGP SIGNATURE-----
iHUEARYKAB0WIQR5XhoxefQv98ZU9+FxhheketsToQUCZ3+SJwAKCRBxhheketsT
oUgiAQCqeDWFwk/KJ9lj60yl3+jXh3/LI4Vk7bvQT8J4VJRsKAEA5btU6njQLPIJ
ftgaFNcCqGmeVARv1233XSM6z2qmgwA=
=pJhT
-----END PGP SIGNATURE-----
- комментарий 10:
From: Sergey Matveev
Date: 2025-01-09 09:48:13Z
*** Dmitri Zubko [2025-01-09 12:08]:
>Данному аргументу место в wish-листе программной реализации криптографического протокола.
Уж извините, но нет. Защита от replay атак это одна из самых базовых
вещей которые обязан обеспечивать протокол. PGP почту спасает только и
только то, что предполагается обмен человеческими сообщениями,
человеческим общением, где на replayed сообщения могут возникнуть
сомнения и дополнительные уточняющие вопросы. Если же предполагается
использование PGP-secured канала связи для общения, грубо говоря,
программ/машин, то он абсолютно неприемлем с точки зрения любого кто
анализировал бы протокол. Поверх такого PGP-канала нужно городить ещё
один слой, где были бы nonce/challenge хотя бы какие-нибудь. Но в общем
случае отсутствие защиты от replay это абсолютно недопустимо (если речь
про хоть что-то серьёзное).
>Пока я не могу привести примеры, но могу предположить, что они не заставят долго ждать себя в пост-квантовую эпоху.
Все известные (а точнее один единственный) алгоритмы для взлома шифров
или хэшей запускаемых на квантовых компьютерах, просто навсего как-бы
сокращают длину ключа в два раза (у хэшей можно сказать что длина хэша в
три раза сокращается). Поэтому уязвимыми на практике могут оказаться
только лишь шифры с короткими (128-бит например) ключами.
Это не исключает что возможно ещё придумают атаку, пускай даже на
обычных компьютерах, на AES, но за десятилетия пока ничего не происходит
подобного. По моему не разумно безумно усложнять протоколы и форматы
ради гибкости выбора алгоритмов: на данный момент мы видим что это одно
из первых что создаёт реальные практические проблемы в безопасности
(сложность кода, сложность анализа). Проще полностью заменить весь
протокол связи. Если какая-нибудь ChaCha20 в WireGuard станет занозой,
то делаем WG2 протокол, вместо того, чтобы в разы увеличивать кодовую
базу протокола ради agility. Опыт человечества, опыт получаемый при
разработке софта, опыт криптографии меняет акценты и приоритеты о
которых нужно беспокоиться.
Не согласны? Ваше право. Но я полностью понимаю и поддерживаю тенденции
на mono-cypher реализации и выжигание сложного софта/форматов/протоколов,
которые на текущей практике только и только беды приносят.
>https://pgpru.com/biblioteka/osnovy/setjdoverija
>Пусть в этом примере информация будет деньгами, а алгоритмы шифрования - сейфами.
Но как это можно соотнести с алгоритмами шифрования? Какой-то из
адекватных на практике используемым алгоритмов можно поломать за
какую-то цену? Даже 3DES вы не "вскроете". Ломать вы будете или по
side-channel атакам или физически захватывая желаемую вами цель, или
применяя социальных инжиниринг (хоть и подкупы или угрозы жизни). Никто
на практике не ломает грамотно используемые шифры, потому что это
бесполезно и невозможно (нет цены у этого). AES хотят поломать как никто
и никогда, но даже в теории и близко к этому нет серьёзных опасений. Вот
как на самом деле: https://xkcd.com/538/
Времена DES, RC4 и другой плохой криптографии, слабых зачаточных
институтов связанных с криптографией уже давным давно в прошлом.
>Здесь я не "рассматривать ситуацию когда у собеседников просто навсего нет нужного софта". Вместо этого мной перечислен на выбор софт для установления защищённого канала связи. Как я уже дал понять выше, такая практика оправдала себя.
Ну... хорошо. PGP для одних задач. OTR для других. Приемлемо. Я бы
добавил: но если можно использовать OMEMO вместо OTR (так как
используется XMPP), то это было бы ещё лучше, как минимум за счёт лучшей
производительности, меньшего потребления ресурсов/трафика, меньшим
потенциальным утечкам по побочным каналам, меньшим нагрузкам на ГПСЧ, и т.д..
>Чем ниже порог вхождения, тем хуже навыки среднестатистического входящего. Отсюда злостное пренебрежение мерами обеспечения безопасности и тот самый человеческий фактор - подарок случая злоумышленнику.
Да, тут не поспорю. Это как FidoNet: сам геморрой с попаданием в него
(хоть какие-то технические навыки надо иметь) уже отсеивал многих. Но
мне также кажется (но нет уверенности), что уж лучше злостно
пренебрегаемые меры безопасности с использованием Signal/OMEMO/OTR
иметь, чем совсем ничего (к "ничему" конечно же можно и WhatsApp/Telegram
отнести). Ибо цена атаки неаккуратного но всё же пользователя Signal/OMEMO/OTR
должна быть существенно выше.
>Осталась чаша UTF-8 everywhere.
Что по моему должно быть default-ом уже давным давно и про возможность
использование других кодировок почти везде стоило бы забыть.
>HTTPS тоже everywhere, но при этом blog.stargrave.org доступен только по HTTP.
Никогда не понимал как люди умудряются подобное брякнуть? Ведь даже
написать это ваше предложение по времени займёт дольше чем проверить
"а не доступен ли blog.stargrave.org по HTTPS?". Наверное практически с
самого начала существования домена/блока/всего у меня *всегда* был HTTPS.
И нет: HTTPS отнюдь не everywhere. В локальных доверенных сетях, в сетях
защищённых IPsec-ом, в CDN-ах где раздаются PGP-signed пакеты
дистрибутивах -- HTTPS чаще всего не используется, ибо незачем, а
расходы на поддержание инфраструктуры добавляет. Хотя, если считать все
эти случаи узкоспециализированными крайностями, то тогда да, можно
сказать, что Web это HTTP everywhere.
>Я не подвергаю сомнению обоснованность отказа от HTTPS, но лишь констатирую факт противоречия в суждениях. Если everywhere является решающим аргументом, то нужно во всём руководствоваться таким аргументом. В противном случае получается двойной стандарт, а это не красиво.
Эти вопросы уже не ко мне. На моих ресурсах нет отказа от HTTPS, он
везде присутствует (даже rsync, в отличии от преобладающего большинства,
тоже на другом порту защищён TLS-ом).
- комментарий 11:
From: Sergey Matveev
Date: 2025-01-09 09:51:43Z
*** Sergey Matveev [2025-01-09 12:48]:
>мне также кажется (но нет уверенности), что уж лучше злостно
>пренебрегаемые меры безопасности с использованием Signal/OMEMO/OTR
>иметь, чем совсем ничего (к "ничему" конечно же можно и WhatsApp/Telegram
>отнести). Ибо цена атаки неаккуратного но всё же пользователя Signal/OMEMO/OTR
>должна быть существенно выше.
Впрочем нет, не соглашусь (с собой же :-)). Злостно неаккуратный
пользователь Signal/OMEMO/OTR/whatever будет иметь иллюзию безопасности:
на самом деле у него всё достаточно паршиво, но он будет думать что
безопасно как у грамотных пользователей, ведь инструмент то выбран
верный (Signal -- согласен, под вопросом). А иллюзия безопасности хуже
чем чёткое понимание её отсутствия.
- комментарий 12:
From: Dmitri Zubko
Date: 2025-01-10 16:56:36Z
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
> >Данному аргументу место в wish-листе программной реализации криптографического протокола.
>
> Уж извините, но нет. Защита от replay атак это одна из самых базовых вещей которые обязан обеспечивать протокол. PGP почту спасает только и только то, что предполагается обмен человеческими сообщениями, человеческим общением, где на replayed сообщения могут возникнуть сомнения и дополнительные уточняющие вопросы. Если же предполагается использование PGP-secured канала связи для общения, грубо говоря, программ/машин, то он абсолютно неприемлем с точки зрения любого кто анализировал бы протокол. Поверх такого PGP-канала нужно городить ещё один слой, где были бы nonce/challenge хотя бы какие-нибудь. Но в общем случае отсутствие защиты от replay это абсолютно недопустимо (если речь про хоть что-то серьёзное).
Озабоченность replayем оправдана при соответствующем уровня секретности. При уровнях меньше или равно коммерческий, данная атака мало чем грозит. Я не потеряю многое, если стану свидетелем того, как админ IRC сервера балуется replayем. А возможно получу положительные эмоции.
> >Пока я не могу привести примеры, но могу предположить, что они не заставят долго ждать себя в пост-квантовую эпоху.
>
> возможно ещё придумают атаку, пускай даже на обычных компьютерах, на AES, но за десятилетия пока ничего не происходит подобного.
Не исключено, продвижение будет в этом направлении. В противостоянии брони и снаряда сейчас наметилось преимущество последнего.
> Не согласны? Ваше право. Но я полностью понимаю и поддерживаю тенденции на mono-cypher реализации и выжигание сложного софта/форматов/протоколов, которые на текущей практике только и только беды приносят.
>
> >https://pgpru.com/biblioteka/osnovy/setjdoverija
> >Пусть в этом примере информация будет деньгами, а алгоритмы шифрования - сейфами.
>
> Но как это можно соотнести с алгоритмами шифрования? Какой-то из адекватных на практике используемым алгоритмов можно поломать за какую-то цену?
См. комментарий выше.
> >Чем ниже порог вхождения, тем хуже навыки среднестатистического входящего. Отсюда злостное пренебрежение мерами обеспечения безопасности и тот самый человеческий фактор - подаро к случая злоумышленнику.
>
> Да, тут не поспорю. Это как FidoNet: сам геморрой с попаданием в него (хоть какие-то технические навыки надо иметь) уже отсеивал многих. Но мне также кажется (но нет уверенности), что уж лучше злостно пренебрегаемые меры безопасности с использованием Signal/OMEMO/OTR иметь, чем совсем ничего (к "ничему" конечно же можно и WhatsApp/Telegram отнести). Ибо цена атаки неаккуратного но всё же пользователя Signal/OMEMO/OTR должна быть существенно выше.
Согласен. Уж лучше пренебрегать мерами безопасности, пользуясь интегрированными в XMPP клиент средствами защиты переписки, нежели полагаться на чьё-нибудь честное слово о приверженности принципу соблюдения тайны переписки. "Privacy through technology, not legislation".
> >Осталась чаша UTF-8 everywhere.
>
> Что по моему должно быть default-ом уже давным давно и про возможность использование других кодировок почти везде стоило бы забыть.
Бывают исключения. К этому надо отнестись как к данности.
>
> >HTTPS тоже everywhere, но при этом blog.stargrave.org доступен только по HTTP.
>
> Никогда не понимал как люди умудряются подобное брякнуть? Ведь даже написать это ваше предложение по времени займёт дольше чем проверить "а не доступен ли blog.stargrave.org по HTTPS?". Наверное практически с самого начала существования домена/блока/всего у меня *всегда* был HTTPS.
Публикации в блоге доступны только по HTTP, хотя порт 443 открыт. Это факт. Причина/объяснение/отсылка к CND не интересуют меня, тем более в свете выраженного неудовольства текущим положением дел вокруг УЦ, а также признания факта отказа от HTTPS на одной из страниц сайта шифропанки.ру
> Впрочем нет, не соглашусь (с собой же :-)). Злостно неаккуратный пользователь Signal/OMEMO/OTR/whatever будет иметь иллюзию безопасности: на самом деле у него всё достаточно паршиво, но он будет думать что безопасно как у грамотных пользователей, ведь инструмент то выбран верный (Signal -- согласен, под вопросом). А иллюзия безопасности хуже чем чёткое понимание её отсутствия.
Довод состоятельный, если пользователь вовлечён в криминал. Тогда, да, иллюзия безопасности окажется губительной дня него. В остальных случаях слабая защита будет лучше, чем ничего.
- --
6321 504A 60B9 FABB 91E2 0CA8 BACA D4F5 D183 2840
-----BEGIN PGP SIGNATURE-----
iHUEARYKAB0WIQR5XhoxefQv98ZU9+FxhheketsToQUCZ4FMfgAKCRBxhheketsT
oWLXAP9glBY1jvPXdzQgJIZh6xcCFE0K9CVVZY3V5h7tY6Hf5wD+ObUaKY4VhBc0
WZOpmuvLjYPzwIYx0cDQYkd1yjor5Q4=
=/NzP
-----END PGP SIGNATURE-----
- комментарий 13:
From: Sergey Matveev
Date: 2025-01-10 17:22:59Z
*** Dmitri Zubko [2025-01-10 19:36]:
>Озабоченность replayем оправдана при соответствующем уровня секретности. При уровнях меньше или равно коммерческий, данная атака мало чем грозит.
Не вижу смысла это более обсуждать, ибо сомнения в необходимости защиты
от replay в канале связи... это просто смешно. Возможно у меня
профдеформация, но серьёзно рассматривать канал связи без защиты от
replay как нечто допустимое -- это недопустимо, разве что это была бы
речь про "безопасные" IM-ы типа Telegram, WhatsApp и подобное.
>Я не потеряю многое, если стану свидетелем того, как админ IRC сервера балуется replayем. А возможно получу положительные эмоции.
Искренне даже становится страшно от этого, ибо, повторив важные сообщения
от важных людей, могут ужасного наворотить. У нас похоже совершенно
несовместимые понятия о том что можно считать безопасным каналом связи.
>Не исключено, продвижение будет в этом направлении. В противостоянии брони и снаряда сейчас наметилось преимущество последнего.
Но на практике, в который раз повторюсь, мы видим проблемы почти всегда
в сложности софта, а не с алгоритмами. Борьба с сильно теоретическими
вещами, усугубляя всё остальное на практике -- мы видим, что приносит
только вред.
>Бывают исключения. К этому надо отнестись как к данности.
Как и к тому, что абсолютно нормальным является то, что никто из
адекватных программистов не будет существенно усложнять свой код/софт,
ради редких особых случаев, которые мне никто ни разу так и не описал
для чего же нужны.
>Публикации в блоге доступны только по HTTP, хотя порт 443 открыт. Это факт.
Я даже прямо сейчас проверил на совершенно сторонних компьютерах, вне
домашней сети, по четырём IP адресам, с двух разных совершенно разных
сетей. Как и публикации, как и сама заглавная страница доступны. Если
ваш провайдер режет трафик до моего HTTPS или вы не знаете как
достучаться до https:// страниц, то не красиво делать вывод о том, что
это якобы я не предоставляю HTTPS версии.
>Причина/объяснение/отсылка к CND не интересуют меня, тем более в свете выраженного неудовольства текущим положением дел вокруг УЦ, а также признания факта отказа от HTTPS на одной из страниц сайта шифропанки.ру
Слушайте, это вы уже несёте откровенный бред. И я не знаю что такое CND
(если это опечатка "CDN", то тоже не понимаю каким боком его можно
притянуть ко всей этой теме).
Учитывая что у меня даже близко нет никаких "фактов", "отказов" от HTTPS
ни на одной странице сайта шифропанков, то единственным объяснением бреда
могло бы быть только то, что вы просто занимаетесь троллингом, а я ведусь.
Так что закончим.
PS: сайта "шифропанки.ру" уже больше полугода как нет, поэтому может
быть вы непойми что читаете?
- комментарий 14:
From: Dmitri Zubko
Date: 2025-01-11 17:21:28Z
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
> >Я не потеряю многое, если стану свидетелем того, как админ IRC сервера балуется replayем. А возможно получу положительные эмоции.
>
> Искренне даже становится страшно от этого, ибо, повторив важные сообщения от важных людей
Важные люди в IRC пишут важные сообщения... Это годная заявка на номинацию самый короткий анекдот.
> >Бывают исключения. К этому надо отнестись как к данности.
>
> не будет существенно усложнять свой код/софт
Тема кодировки не подлежит обсуждение. Ваша попытка углубляться в эту тему и развивать её - оффтоп, выражаясь жаргоном FidoNet. Закон не запрещает, религия не возбраняет выбирать любую кодировку. Вам следовало принять выбор как данность и воздержаться от высказывания невостребованных оценок.
> >Публикации в блоге доступны только по HTTP, хотя порт 443 открыт. Это факт.
>
> Я даже прямо сейчас проверил на совершенно сторонних компьютерах, вне домашней сети, по четырём IP адресам, с двух разных совершенно разных сетей. Как и публикации, как и сама заглавная страница доступны. Если ваш провайдер режет трафик до моего HTTPS или вы не знаете как достучаться до https:// страниц, то не красиво делать вывод о том, что это якобы я не предоставляю HTTPS версии.
Даже, если допустить версию кратковременного глюка при взаимодействии ПА с blog.stargrave.org, то это никоим образом не отменяет неприглядный факт демонстрации Вами двойного стандарта. Ведь, на страницах blog.stargrave.org Вы критиковали ранее УЦ (в этом я солидарен с Вами), чьи сертификаты everywhere; и на странице подконтрольного шифропанки.ру объяснили схожими аргументами отказ от HTTPS, который тоже everywhere.
> Слушайте, это вы уже несёте откровенный бред. И я не знаю что такое CND (если это опечатка "CDN", то тоже не понимаю каким боком его можно притянуть ко всей этой теме).
>
> Учитывая что у меня даже близко нет никаких "фактов", "отказов" от HTTPS ни на одной странице сайта шифропанков, то единственным объяснением бреда могло бы быть только то, что вы просто занимаетесь троллингом, а я ведусь. Так что закончим.
>
> PS: сайта "шифропанки.ру" уже больше полугода как нет, поэтому может быть вы непойми что читаете?
Судя по всему, Вы решительно отвергли допущение о чтении мной шифропанки.ру в бытность существования его. Предпосылка не ясна, однако же продолжайте оставаться в фарватере своей странной логики и отвергайте с той же решимостью допущение о чтении мной ваших сетевых ресурсов. Тем более, что это будет соответствовать действительности с указанного в сигнатуре момента времени.
- --
6321 504A 60B9 FABB 91E2 0CA8 BACA D4F5 D183 2840
-----BEGIN PGP SIGNATURE-----
iHUEARYKAB0WIQR5XhoxefQv98ZU9+FxhheketsToQUCZ4KoJQAKCRBxhheketsT
oZOwAP4vvVNr02DTKBneZPV8d6feIOO5+S9pstsvPB36Sap7HwD/WplSmBT6G+S9
g0KEX0oTnEBite4xdDlvCtQw24cbfAw=
=oBsk
-----END PGP SIGNATURE-----