Есть где-либо доказательство подобного суждения? Практика показывает обратное в лице существования DC (проблема обедающих криптографов) и QB (проблема на базе очередей) сетей.
Или идите дальше — создайте или настройте свой мессенджер на базе I2P. Это сложно, но там нет IP-адресов, и всё по-настоящему анонимно. I2P проверен временем, он не прост в использовании, но если вы хотите настоящей безопасности — это путь.
Здесь уже активируется душнила мод. 1. Что значит нет IP-адресов? Для чего тогда на маршрутизаторе необходимо открывать порт во вне? Не для того ли, чтобы другие узлы могли к нам подсоединиться для возможности дальнейшей маршрутизации пакетов? 2. Что значит по-настоящему анонимно? Будет ли I2P хорошо анонимизировать трафик, если клиент и сервер находятся в одном государстве? Сможет ли при таком сценарии государство / объединение провайдеров связи построить модель противодействия анонимизации? 3. Это путь в никуда, если нет понимания чёткой модели угроз и того, что вы хотите в итоге получить. I2P - инструмент, в массе своей хороший, но и также имеющий ряд ограничений.
Может показаться, что я защищаю сигнал, но все предоставленные аргументы / причины слабы, их можно легко противопоставить следующим суждениям:
Причина №1: Централизованные серверы
Централизованность != уязвимость. В концепте сигнала сервер выполняет роль хранилища шифртекстов, что 1) удобно, т.к. данные всегда сохраняются и это не зависит от других участников и их онлайн/оффлайн состояния, 2) Интернет построен так, что достаточно сложно построить по нормальному децентрализованную сеть не прибегая при этом к хакам по типу проброса портов через NAT или к TURN-серверам, 3) вполне безопасно, если мы говорим об использовании E2E-шифрования, т.к. безопасность коммуникации можно проверить исключительно клиентской составляющей.
Причина №2: Прецедент ANØM
У ANØM происходила маркетинговая "акция", у Signal'а такого особо не наблюдалось. Также у Signal'a есть какая да никакая формальная доказуемость его логики работы в лице независимых аудитов из-за наличия исходного кода. ANØM же обладал закрытым кодом как клиентской, так и серверной части.
Причина №3: Требование номера телефона
Причина №4: Метаданные и сохранение мелочей
Если мы говорим о безопасности, как о конфиденциальности передаваемых данных, то это частично и с оговорками может считаться нормой. Если же мы говорим о безопасности, как со стороны анонимности пользователей, то это конечно не очень (мягко говоря). Но здесь стоит сказать, что сигнал не претендовал себя на роль анонимного мессенджера. В его модели угроз нет такого, что он должен как-либо доказуемо скрывать идентификаторы или не логгировать активность пользователей.
Просто вопрос: зачем сервер вообще хоть что-то хранит?
Как минимум для того, чтобы синхронизировать состояния клиентов (таймстемпы отправленных сообщений, показывать состояние онлайн, показывать что пользователь печатает сообщение и т.п.) и смотреть какие-нибудь аномальные поведения: активность ботов, перегрузка сети и т.д. (логгирование).
Как видно, многие криптографические разработки эпохи Ренессанса не превратились в «пыльные артефакты» и остаются рабочими инструментами даже в цифровую эпоху. Что уж говорить, классика не стареет.
Вывод какой-то туманный, скорее он даже полностью оторван от содержания самой статьи. Все описанные шифры в статье уже давно не применяются в современной криптографии. Если бы приводились примеры композиции этих классических шифров и того, как они смогли "переродиться" в современные, то это было бы конечно другое дело. Но в самой статье об этом никак не говорится и никакие примеры не приводятся.
Проблема в том, что сам вопрос некорректен в корне. Сквозное шифрование здесь приплетено ради только красного словца. С таким же успехом мы могли бы вместо сквозного шифрования подставить "полёт на марс", "покер", "интим услуги" и смысл бы не поменялся. С учётом этого, я думаю автору следовало бы назвать статью иначе: станет ли ИИ катастрофой для интим услуг? Внимания он получил бы в разы больше, чем от сквозного шифрования, но смысл статьи вообще бы никак не изменился.
Когда мы рассматриваем сквозное шифрование, мы должны рассматривать его именно с той позиции - как шифртекст должен проходить свой путь от отправителя к истинному получателю / как он должен маршрутизироваться в условиях существования промежуточных сервисов, не способных читать его открытое содержимое. Когда же существует ИИ на стороне клиента, который считывает plaintext ещё до этапа шифрования, то о каком сквозном шифровании может вообще идти речь? Эта модель угроз равнозначна той же модели, когда в системе присутствуют сниферы, кейлоггеры и прочие вредоносные программы. Иными словами, клиентская среда уже априори уязвима перед любым криптографическим примитивом. Учитывая всё это и возвращаясь к первоначальной теме, мы же не ставим вопрос касаемо того, станет ли кейлоггер катастрофой для сквозного шифрования? Потому что сквозное шифрование (да и любое шифрование в такой модели угроз) не решает и не должно решать проблему наличия в системе вредоносного ПО. С этой моделью угроз должны справляться другие методы защиты. Поэтому и сам вопрос об ИИ в плоскости сквозного шифрования должен рассматриваться исключительно со стороны модели угроз, предоставляемой самим сквозным шифрованием.
Воды много, а информации мало. Можно было просто одним предложением ответить этот на этот вопрос: если сквозное шифрование не является фиктивным, то никакой катастрофы не будет. И чтобы ответить на этот вопрос даже не нужно знать как конкретно будет работать тот или иной ИИ, т.к. проблема лежит в плоскости сложности вычислений, а не "сознательности" используемого алгоритма.
Вопросы и идеи для развития вм'ки действительно хороши. При наличии свободного времени попытаюсь воплотить некоторые из них в реальность. Скорее всего это буду делать либо как форк cvm, либо как полностью отдельный проект. В cvm постараюсь сохранить первоначальную простоту и чистоту.
Думаю всё куда проще. Так как DNS не шифруется, сим-карты привязаны к паспортным данным, а сам пчелайн является оператором связи, то он вполне себе может видеть куда отправляются запросы и от какого лица они были отправлены. В итоге, оператор просто формирует базу данных по типу <пользователь:сайт:время>, а далее её продаёт в "обезличенной" форме.
Для защиты от новых форм диктатуры, предлагаю альтернативу - цифровую демократию, основой которой является децентрализация цифровых инструментов, когда вся информация о цифровых паспортах с биометрией (цифровые подписи), деньгах (криптовалюта с общим бюджетом) и выборах (с отзывом голосов) - хранится распределенно и не подконтрольна властям. В такой системе общество становится Большим братом, следящим за действиями избранных властей.
Предлагаемый вами выбор больше похож на аксиому Эскобара, где с одной стороны централизованный и закрытый ГУЛАГ, с другой стороны децентрализованный и открытый ГУЛАГ. Но в сумме, что то решение ***, что другое решение ***. Общество надо защищать не только от государства, которое действительно является по своей природе аппаратом насилия, но и от самого себя. Когда биометрия каждого человека гуляет децентрализованно, создаётся куда больше векторов нападения и куда больше возможностей у злоумышленников. Если общество взбудоражено, возбуждено и агресивно, в ходе на то внешних условий среды, вызванных не без участия того же государства, то и само же общество будет вести себя подобно государству, так же жестоко, меркантильно и отстранённо к каждому отдельному человеку или группе лиц. И в таком случае, каждая отдельная единица общества станет куда более уязвимой, нежели чем при централизованном ГУЛАГЕ.
Проблема, которую вы ставите, и способы решения, которые вы предлагаете - равносильно сравнению тёплого с мягким, когда следствием вы хотите побороть причину. Цифровизация, будь то централизованная или децентрализованная, - ни хорошо и ни плохо, у обоих векторов будут отвратительные антиутопичные сценарии. Основная загвостка в том, что проблема лежит в плоскости социального, а технологии лишь могут обострять прогресс социального, но не переделывать мир. Никакое внедрение децентрализации не приведёт государства и корпорации к обессиливанию и белому флагу, скорее напротив - они будут всеми правдами и неправдами ломать, сжигать, втаптывать в грязь все зачатки и все достижения безопасных и анонимных технологий, потому как всё это для них инородно "физиологически". Государства и корпорации борются не технологически, а вполне материально и физически со всеми своими текущими и будущими, предполагаемыми и реальными врагами. Общество сможет сформировать безопасные технологии и начать базироваться на них лишь тогда, когда само сможет применять ровно такие же действия к тем, кто его угнетал.
Нет, они сами являются «конечной точкой» в е2е и имеют доступ к этой информации легитимно
Легитимно - (в юридическом смысле этого слова) может быть (и то случаются натяжки), сквозное ли это шифрование - точно нет. Суть E2E шифрования в том, что оно должно протягиваться до конечных точек, в мессенджерах конечные точки - это друзья, с которыми ты общаешься, это группы, ленту которых ты просматриваешь и т.д., но точно не сам сервис. Такой же принцип с маркетплейсами, конечная точка - это продавец, а не сам сервис. Такой же принцип с электронной почтой, конечная точка - это получатель письма, а не сервис электронной почты. И т.д., и т.п. ...
Между тобой и сервером ВК, а также между сервером ВК и твоим другом есть две, вполне себе e2e зашифрованные линии
Это не E2E шифрование, а обычное, что ни на есть, клиент-серверное шифрование, где безопасная коммуникация строится только от клиентов к серверу, а не от клиентов к клиентам.
Сквозное шифрование гарантирует, что данные остаются конфиденциальными не только для внешних злоумышленников, но и для самих компаний, предоставляющих услуги
...
Яркий пример — https-протокол
То-есть, ВКонтакте, Одноклассники, Ozon, WB, Mail.ru и прочие - это всё примеры сервисов со сквозным шифрованием, где даже сам сервис не знает что вы отправляете, что вы покупаете, что вы просматриваете?
Скорее всего вы просто не разобрались в теме, либо ещё проще - воспользовались нейросетью, чтобы она сказала, что есть такое сквозное (E2E) шифрование.
При этом, я не говорю, что централизованные сервисы вовсе бесполезны в концепте E2E шифрования. Так например, я могу обменяться лично публичным ключом со своим другом, а далее использовать ВКонтакте, как платформу, для обмена шифртекстами. В этом случае у нас создаётся действительно сквозное шифрование - шифрование, при котором только истинный собеседник получает открытый текст. Все промежуточные узлы, начиная от провайдеров связи и заканчивая централизованными сервисами - получают лишь шифртекст. И как видно, HTTPS здесь вообще никакой роли не играет, даже если бы использовался голый HTTP, сквозное шифрование оставалось бы нетронутым.
Все чаты защищены с помощью симметричного шифрования, при этом используется принцип одноразового блокнота, то есть каждое сообщение шифруется новым ключом.
Ничего общего с одноразовым блокнотом это не имеет. В ссылке, в которой вы же указываете, есть точные критерии, как минимум - условие истинной случайности. Если таковой нет, то ни о каком одноразовом блокноте уже и не стоит говорить. В ином случае, мы так и поточные шифры легко сможем сравнять с одноразовыми блокнотами.
Постоянный идентификатор позволяет соотнести личность анонимного пользователя с профилями в социальных сетях и определить его настоящее имя.
Идентификатор позволяет определить личность ровно настолько же насколько позволяет в SimpleX определить эту же самую личность "временные анонимные парные идентификаторы очередей сообщений", которыми клиенты обмениваются. Иными словами, как бы мессенджер не говорил об отсутствии идентификации, но сделать его безопасным, без какой бы то ни было идентификации, - невозможно. Либо мы шифруем сообщения и априори добавляем в схему методы аутентификации (и как следовательно идентификации), либо мы вообще не шифруем сообщения.
На счёт не шифрования сообщений - не всё так безрассудно, как может показаться на первый взгляд, потому как анонимность != безопасность. Так например, DC-сети (сети на базе проблемы обедающих криптографов) вообще не шифруют сообщение как таковое, а просто отправляют его всем узлам в сети, но при этом, анонимность близка к идеальной (в плане сетевого распространения сообщений), т.к. скрывает источника (отправителя) информации с хорошими гарантиями.
подключение к удалённым серверам через Tor;
Вот это вообще бомба. В двух из трёх вами описанных мессенджерах фактически реальная анонимность формируется не за счёт архитектурных решений, принятых разработчиками, а за счёт использования уже готового решения в лице Tor'а. А в третьем мессенджере так вообще не понятно за счёт чего формируется хоть какая-то анонимность. SimpleX и Technitium Mesh без Tor'a нельзя было бы назвать анонимными мессенджерами, их можно было бы просто относить к мессенджерам по типу Signal или Telegram (с секретными чатами). Т.е. вся их фича анонимности в большей мере лежит на сторонней технологии, а не на их изобретённых новшествах. Они архитектурно безопасны, но их анонимность достигается не за счёт них самих.
Основная суть анонимности - это скрывать связь между множеством отправителей и получателей от множества наблюдателей. Отсутствие идентификаторов - решающей роли в этом не играет, Непонятно как все эти описанные мессенджеры скрывают связь между реальным отправителем и реальным получателем, если вдруг каким-то образом их сервера или узлы захватит наблюдатель, или если таковой наблюдатель вообще будет глобальным. Tor - даёт определённый спектр решений и некоторые гарантии, а также ограничения. SimpleX, Technitium Mesh и BeProg (в чистом виде) - не дают гарантий вовсе.
Я отрицательную оценку не ставил, но пробелы в повествовании всё же есть:
1.
Если мы шифруем, например JSON документ, отправляем на обработку, где вносятся минимальные изменения где-нибудь в конце или середине — мы это узнаем.
Чтобы этого не было, используется как раз вектор инициализации. В статье про его предназначение особо ничего не сказано, кроме того, что он опционален, хотя на деле - скорее обязателен, потому как, действительно, его отсутствие приводит к описанной вами проблеме.
Из этого также вытекает теперь и то, что одинаковый минус, приписанный к CBC, CFB, OFB, по поводу малого изменения данных в середине или конце открытого текста, просто исчезает.
2.
В определении "шифратора", алгоритм дополнения кажется излишним. И действительно, в поточных режимах по типу OFB, CTR, а также "полу-поточном" CFB - алгоритма дополнения нет вовсе.
Плюс к этому, режимы шифрования, базируемые на дополнении (как пример, CBC), могут обладать также интересным вектором атак с оракулом. Было бы неплохо этот пункт внести как минус или предупреждение.
3.
Следуя спецификациям режима CTR мы XOR'им значение счетчика с блоком открытого текста, а затем шифруем. Алгоритм похож на CBC, по крайней мере визуально, но лишен его недостатков.
Ничего также не сказано о минусах поточных режимов шифрования по типу CTR, OFB, а именно - что если мы будем использовать один и тот же ключ шифрования с идентичным вектором инициализации / счётчиком? В таком случае, мы сможем вообще удалить ключ шифрования: (m1 xor k) xor (m2 xor k) = m1 xor m2, что является серьёзной уязвимостью, если не противодействовать повторениям.
UPD. Визуально всё же OFB больше похож на CBC, чем CTR.
UPD. Также почему-то в CTR счётчик стал просто вектором инициализации, хотя это уже не инициализация, раз таковая применяется в каждом блоке шифрования. Плюс к этому у счётчика в CTR - два параметра: константное (сеанс связи) и переменное (сам счётчик) значения. В статье об этом также ничего не сказано.
Вопрос действительно интересный, т.к. основная проблема перехода - это потеря идентификации узлов. Если это система по типу криптовалют, где всё держится на подобного рода идентификации - необходимым условием становится связывание ключей, где ключ RSA подписывает ключ ML-DSA, а ML-DSA - ключ RSA. Соответственно в логике криптовалют / блокчейна должны будут храниться два ключа с последующей возможностью их валидации. Если RSA ещё не взломан, он вполне себе может подтверждать идентификацию участника через ML-DSA какое-то время. Этого времени должно быть достаточно ровно настолько, чтобы оставшиеся узлы смогли перейти на подтверждённый ML-DSA ключ, а RSA ключ воспринять как Deprecated. Таким образом, предполагается, что до создания мощного квантового компьютера состояние Deprecated сможет перейти в состояние Forbidden, а все действия, что происходили с RSA ключом в виде хеша будут сохранены в состоянии под ML-DSA подписью.
С анонимными сетями ситуация немного упрощённее, т.к. не требуется хранить состояние, плюс к этому не все анонимные сети в равной степени будут сложнопереносимы. Как пример, для сети Tor переход на постквантовые алгоритмы будет более простым, чем для I2P, т.к. бОльшая часть коммуникаций связана у него всё же с открытым Интернетом, а не внутренними Hidden Services. Что касается Hidden Lake, то тут ситуация ещё проще, потому как: 1) у HL нет какой-то одной глобальной сети, в отличие от Tor или I2P, вследствие чего одна сеть может работать на RSA, другая - на ML-DSA, 2) HL работает с малыми группами узлов, а потому обновить их будет чисто количественно проще, 3) HL не настолько популярна как Tor, I2P, поэтому радикальные обновления можно делать более смело.
Что касается Hidden Lake, как концепта - год назад сеть таковой действительно являлась, сейчас уже скорее нет, чем да, т.к.: 1) сеть вполне успешно функционирует, ретрансляторы запущены и распределяют / сохраняют шифртексты, 2) исследовательские работы написаны, рассмотрены пределы сети, её достоинства и уязвимости, 3) основная часть кода, связанная с анонимностью и безопасностью, покрыта тестами более чем на 98% (пакет go-peer).
Есть где-либо доказательство подобного суждения? Практика показывает обратное в лице существования DC (проблема обедающих криптографов) и QB (проблема на базе очередей) сетей.
Здесь уже активируется душнила мод.
1. Что значит нет IP-адресов? Для чего тогда на маршрутизаторе необходимо открывать порт во вне? Не для того ли, чтобы другие узлы могли к нам подсоединиться для возможности дальнейшей маршрутизации пакетов?
2. Что значит по-настоящему анонимно? Будет ли I2P хорошо анонимизировать трафик, если клиент и сервер находятся в одном государстве? Сможет ли при таком сценарии государство / объединение провайдеров связи построить модель противодействия анонимизации?
3. Это путь в никуда, если нет понимания чёткой модели угроз и того, что вы хотите в итоге получить. I2P - инструмент, в массе своей хороший, но и также имеющий ряд ограничений.
Может показаться, что я защищаю сигнал, но все предоставленные аргументы / причины слабы, их можно легко противопоставить следующим суждениям:
Централизованность != уязвимость. В концепте сигнала сервер выполняет роль хранилища шифртекстов, что 1) удобно, т.к. данные всегда сохраняются и это не зависит от других участников и их онлайн/оффлайн состояния, 2) Интернет построен так, что достаточно сложно построить по нормальному децентрализованную сеть не прибегая при этом к хакам по типу проброса портов через NAT или к TURN-серверам, 3) вполне безопасно, если мы говорим об использовании E2E-шифрования, т.к. безопасность коммуникации можно проверить исключительно клиентской составляющей.
У ANØM происходила маркетинговая "акция", у Signal'а такого особо не наблюдалось. Также у Signal'a есть какая да никакая формальная доказуемость его логики работы в лице независимых аудитов из-за наличия исходного кода. ANØM же обладал закрытым кодом как клиентской, так и серверной части.
Если мы говорим о безопасности, как о конфиденциальности передаваемых данных, то это частично и с оговорками может считаться нормой. Если же мы говорим о безопасности, как со стороны анонимности пользователей, то это конечно не очень (мягко говоря). Но здесь стоит сказать, что сигнал не претендовал себя на роль анонимного мессенджера. В его модели угроз нет такого, что он должен как-либо доказуемо скрывать идентификаторы или не логгировать активность пользователей.
Как минимум для того, чтобы синхронизировать состояния клиентов (таймстемпы отправленных сообщений, показывать состояние онлайн, показывать что пользователь печатает сообщение и т.п.) и смотреть какие-нибудь аномальные поведения: активность ботов, перегрузка сети и т.д. (логгирование).
Вывод какой-то туманный, скорее он даже полностью оторван от содержания самой статьи. Все описанные шифры в статье уже давно не применяются в современной криптографии. Если бы приводились примеры композиции этих классических шифров и того, как они смогли "переродиться" в современные, то это было бы конечно другое дело. Но в самой статье об этом никак не говорится и никакие примеры не приводятся.
Проблема в том, что сам вопрос некорректен в корне. Сквозное шифрование здесь приплетено ради только красного словца. С таким же успехом мы могли бы вместо сквозного шифрования подставить "полёт на марс", "покер", "интим услуги" и смысл бы не поменялся. С учётом этого, я думаю автору следовало бы назвать статью иначе: станет ли ИИ катастрофой для интим услуг? Внимания он получил бы в разы больше, чем от сквозного шифрования, но смысл статьи вообще бы никак не изменился.
Когда мы рассматриваем сквозное шифрование, мы должны рассматривать его именно с той позиции - как шифртекст должен проходить свой путь от отправителя к истинному получателю / как он должен маршрутизироваться в условиях существования промежуточных сервисов, не способных читать его открытое содержимое.
Когда же существует ИИ на стороне клиента, который считывает plaintext ещё до этапа шифрования, то о каком сквозном шифровании может вообще идти речь? Эта модель угроз равнозначна той же модели, когда в системе присутствуют сниферы, кейлоггеры и прочие вредоносные программы. Иными словами, клиентская среда уже априори уязвима перед любым криптографическим примитивом.
Учитывая всё это и возвращаясь к первоначальной теме, мы же не ставим вопрос касаемо того, станет ли кейлоггер катастрофой для сквозного шифрования? Потому что сквозное шифрование (да и любое шифрование в такой модели угроз) не решает и не должно решать проблему наличия в системе вредоносного ПО. С этой моделью угроз должны справляться другие методы защиты. Поэтому и сам вопрос об ИИ в плоскости сквозного шифрования должен рассматриваться исключительно со стороны модели угроз, предоставляемой самим сквозным шифрованием.
Воды много, а информации мало. Можно было просто одним предложением ответить этот на этот вопрос: если сквозное шифрование не является фиктивным, то никакой катастрофы не будет. И чтобы ответить на этот вопрос даже не нужно знать как конкретно будет работать тот или иной ИИ, т.к. проблема лежит в плоскости сложности вычислений, а не "сознательности" используемого алгоритма.
Со всеми пунктами полностью согласен. На рефакторинг завёл задачу: https://github.com/number571/cvm/issues/1
_ (удалено)
Так и вижу каптчу куратора на гугле
Вопросы и идеи для развития вм'ки действительно хороши. При наличии свободного времени попытаюсь воплотить некоторые из них в реальность. Скорее всего это буду делать либо как форк cvm, либо как полностью отдельный проект. В cvm постараюсь сохранить первоначальную простоту и чистоту.
Думаю всё куда проще. Так как DNS не шифруется, сим-карты привязаны к паспортным данным, а сам пчелайн является оператором связи, то он вполне себе может видеть куда отправляются запросы и от какого лица они были отправлены. В итоге, оператор просто формирует базу данных по типу <пользователь:сайт:время>, а далее её продаёт в "обезличенной" форме.
UPD. https://habr.com/ru/companies/timeweb/articles/861510/
Предлагаемый вами выбор больше похож на аксиому Эскобара, где с одной стороны централизованный и закрытый ГУЛАГ, с другой стороны децентрализованный и открытый ГУЛАГ. Но в сумме, что то решение ***, что другое решение ***. Общество надо защищать не только от государства, которое действительно является по своей природе аппаратом насилия, но и от самого себя. Когда биометрия каждого человека гуляет децентрализованно, создаётся куда больше векторов нападения и куда больше возможностей у злоумышленников. Если общество взбудоражено, возбуждено и агресивно, в ходе на то внешних условий среды, вызванных не без участия того же государства, то и само же общество будет вести себя подобно государству, так же жестоко, меркантильно и отстранённо к каждому отдельному человеку или группе лиц. И в таком случае, каждая отдельная единица общества станет куда более уязвимой, нежели чем при централизованном ГУЛАГЕ.
Проблема, которую вы ставите, и способы решения, которые вы предлагаете - равносильно сравнению тёплого с мягким, когда следствием вы хотите побороть причину. Цифровизация, будь то централизованная или децентрализованная, - ни хорошо и ни плохо, у обоих векторов будут отвратительные антиутопичные сценарии. Основная загвостка в том, что проблема лежит в плоскости социального, а технологии лишь могут обострять прогресс социального, но не переделывать мир. Никакое внедрение децентрализации не приведёт государства и корпорации к обессиливанию и белому флагу, скорее напротив - они будут всеми правдами и неправдами ломать, сжигать, втаптывать в грязь все зачатки и все достижения безопасных и анонимных технологий, потому как всё это для них инородно "физиологически". Государства и корпорации борются не технологически, а вполне материально и физически со всеми своими текущими и будущими, предполагаемыми и реальными врагами. Общество сможет сформировать безопасные технологии и начать базироваться на них лишь тогда, когда само сможет применять ровно такие же действия к тем, кто его угнетал.
Новый законопроект на 1 января 2025 года
Что понимается под реальным сетевым взаимодействием? В примере узлы подключаются к внешнему ретранслятору и через него начинают своё общение.
Легитимно - (в юридическом смысле этого слова) может быть (и то случаются натяжки), сквозное ли это шифрование - точно нет. Суть E2E шифрования в том, что оно должно протягиваться до конечных точек, в мессенджерах конечные точки - это друзья, с которыми ты общаешься, это группы, ленту которых ты просматриваешь и т.д., но точно не сам сервис. Такой же принцип с маркетплейсами, конечная точка - это продавец, а не сам сервис. Такой же принцип с электронной почтой, конечная точка - это получатель письма, а не сервис электронной почты. И т.д., и т.п. ...
Это не E2E шифрование, а обычное, что ни на есть, клиент-серверное шифрование, где безопасная коммуникация строится только от клиентов к серверу, а не от клиентов к клиентам.
...
То-есть, ВКонтакте, Одноклассники, Ozon, WB, Mail.ru и прочие - это всё примеры сервисов со сквозным шифрованием, где даже сам сервис не знает что вы отправляете, что вы покупаете, что вы просматриваете?
Скорее всего вы просто не разобрались в теме, либо ещё проще - воспользовались нейросетью, чтобы она сказала, что есть такое сквозное (E2E) шифрование.
При этом, я не говорю, что централизованные сервисы вовсе бесполезны в концепте E2E шифрования. Так например, я могу обменяться лично публичным ключом со своим другом, а далее использовать ВКонтакте, как платформу, для обмена шифртекстами. В этом случае у нас создаётся действительно сквозное шифрование - шифрование, при котором только истинный собеседник получает открытый текст. Все промежуточные узлы, начиная от провайдеров связи и заканчивая централизованными сервисами - получают лишь шифртекст. И как видно, HTTPS здесь вообще никакой роли не играет, даже если бы использовался голый HTTP, сквозное шифрование оставалось бы нетронутым.
Ничего общего с одноразовым блокнотом это не имеет. В ссылке, в которой вы же указываете, есть точные критерии, как минимум - условие истинной случайности. Если таковой нет, то ни о каком одноразовом блокноте уже и не стоит говорить. В ином случае, мы так и поточные шифры легко сможем сравнять с одноразовыми блокнотами.
Идентификатор позволяет определить личность ровно настолько же насколько позволяет в SimpleX определить эту же самую личность "временные анонимные парные идентификаторы очередей сообщений", которыми клиенты обмениваются. Иными словами, как бы мессенджер не говорил об отсутствии идентификации, но сделать его безопасным, без какой бы то ни было идентификации, - невозможно. Либо мы шифруем сообщения и априори добавляем в схему методы аутентификации (и как следовательно идентификации), либо мы вообще не шифруем сообщения.
На счёт не шифрования сообщений - не всё так безрассудно, как может показаться на первый взгляд, потому как анонимность != безопасность. Так например, DC-сети (сети на базе проблемы обедающих криптографов) вообще не шифруют сообщение как таковое, а просто отправляют его всем узлам в сети, но при этом, анонимность близка к идеальной (в плане сетевого распространения сообщений), т.к. скрывает источника (отправителя) информации с хорошими гарантиями.
Вот это вообще бомба. В двух из трёх вами описанных мессенджерах фактически реальная анонимность формируется не за счёт архитектурных решений, принятых разработчиками, а за счёт использования уже готового решения в лице Tor'а. А в третьем мессенджере так вообще не понятно за счёт чего формируется хоть какая-то анонимность. SimpleX и Technitium Mesh без Tor'a нельзя было бы назвать анонимными мессенджерами, их можно было бы просто относить к мессенджерам по типу Signal или Telegram (с секретными чатами). Т.е. вся их фича анонимности в большей мере лежит на сторонней технологии, а не на их изобретённых новшествах. Они архитектурно безопасны, но их анонимность достигается не за счёт них самих.
Основная суть анонимности - это скрывать связь между множеством отправителей и получателей от множества наблюдателей. Отсутствие идентификаторов - решающей роли в этом не играет, Непонятно как все эти описанные мессенджеры скрывают связь между реальным отправителем и реальным получателем, если вдруг каким-то образом их сервера или узлы захватит наблюдатель, или если таковой наблюдатель вообще будет глобальным. Tor - даёт определённый спектр решений и некоторые гарантии, а также ограничения. SimpleX, Technitium Mesh и BeProg (в чистом виде) - не дают гарантий вовсе.
Я отрицательную оценку не ставил, но пробелы в повествовании всё же есть:
1.
Чтобы этого не было, используется как раз вектор инициализации. В статье про его предназначение особо ничего не сказано, кроме того, что он опционален, хотя на деле - скорее обязателен, потому как, действительно, его отсутствие приводит к описанной вами проблеме.
Из этого также вытекает теперь и то, что одинаковый минус, приписанный к CBC, CFB, OFB, по поводу малого изменения данных в середине или конце открытого текста, просто исчезает.
2.
В определении "шифратора", алгоритм дополнения кажется излишним. И действительно, в поточных режимах по типу OFB, CTR, а также "полу-поточном" CFB - алгоритма дополнения нет вовсе.
Плюс к этому, режимы шифрования, базируемые на дополнении (как пример, CBC), могут обладать также интересным вектором атак с оракулом. Было бы неплохо этот пункт внести как минус или предупреждение.
3.
Ничего также не сказано о минусах поточных режимов шифрования по типу CTR, OFB, а именно - что если мы будем использовать один и тот же ключ шифрования с идентичным вектором инициализации / счётчиком? В таком случае, мы сможем вообще удалить ключ шифрования: (m1 xor k) xor (m2 xor k) = m1 xor m2, что является серьёзной уязвимостью, если не противодействовать повторениям.
UPD. Визуально всё же OFB больше похож на CBC, чем CTR.
UPD. Также почему-то в CTR счётчик стал просто вектором инициализации, хотя это уже не инициализация, раз таковая применяется в каждом блоке шифрования. Плюс к этому у счётчика в CTR - два параметра: константное (сеанс связи) и переменное (сам счётчик) значения. В статье об этом также ничего не сказано.
Вопрос действительно интересный, т.к. основная проблема перехода - это потеря идентификации узлов. Если это система по типу криптовалют, где всё держится на подобного рода идентификации - необходимым условием становится связывание ключей, где ключ RSA подписывает ключ ML-DSA, а ML-DSA - ключ RSA. Соответственно в логике криптовалют / блокчейна должны будут храниться два ключа с последующей возможностью их валидации. Если RSA ещё не взломан, он вполне себе может подтверждать идентификацию участника через ML-DSA какое-то время. Этого времени должно быть достаточно ровно настолько, чтобы оставшиеся узлы смогли перейти на подтверждённый ML-DSA ключ, а RSA ключ воспринять как Deprecated. Таким образом, предполагается, что до создания мощного квантового компьютера состояние Deprecated сможет перейти в состояние Forbidden, а все действия, что происходили с RSA ключом в виде хеша будут сохранены в состоянии под ML-DSA подписью.
С анонимными сетями ситуация немного упрощённее, т.к. не требуется хранить состояние, плюс к этому не все анонимные сети в равной степени будут сложнопереносимы. Как пример, для сети Tor переход на постквантовые алгоритмы будет более простым, чем для I2P, т.к. бОльшая часть коммуникаций связана у него всё же с открытым Интернетом, а не внутренними Hidden Services. Что касается Hidden Lake, то тут ситуация ещё проще, потому как: 1) у HL нет какой-то одной глобальной сети, в отличие от Tor или I2P, вследствие чего одна сеть может работать на RSA, другая - на ML-DSA, 2) HL работает с малыми группами узлов, а потому обновить их будет чисто количественно проще, 3) HL не настолько популярна как Tor, I2P, поэтому радикальные обновления можно делать более смело.
Что касается Hidden Lake, как концепта - год назад сеть таковой действительно являлась, сейчас уже скорее нет, чем да, т.к.: 1) сеть вполне успешно функционирует, ретрансляторы запущены и распределяют / сохраняют шифртексты, 2) исследовательские работы написаны, рассмотрены пределы сети, её достоинства и уязвимости, 3) основная часть кода, связанная с анонимностью и безопасностью, покрыта тестами более чем на 98% (пакет go-peer).