Вы скорее всего не понимаете разницы между ГПСЧ и ГСЧ как таковыми - в одном случае есть точно заданный алгоритм генерации, в другом - алгоритма никакого нет. Если применяется ГПСЧ и таковой уязвим к атакам анализа, тарабарщину можно восстановить крайне просто (на примере ЛКГ):
Дано: "р щвао ку гевре в 8:88"
Предполагаем, что начало = "я буду"
Выполняем XOR операцию: "р щвао" XOR "я буду"
Получаем часть предполагаемого ключа в ГПСЧ = X
Подставляем данный X в формулу: (aX + b) (mod N) = Xi
Если Xi со следующими байтами шифртекста (по типу "ку гевре") даёт что-то осознанное - мы взломали шифр
Если нет - делаем другое предположение (возвращаемся к шагу 2)
Если бы вы сменили ГПСЧ / КСГПСЧ на ГСЧ - всё вами описанное действительно бы работало правильно. Но если вы используете ГПСЧ - это априори вред для конечных пользователей, даже обычные граждане смогут технически взломать данную систему шифрования, не говоря уже о спецслужбах. Если вы используете КСГПСЧ - ок, но смысла теперь от ключа размером в сообщение никакого нет, потому что генерируемая гамма держится на ключе, размер которого ограничен. Легче уж в таком случае просто отдавать пользователю ключ от КСГПСЧ, а не гамму, которая была им сгенерирована. Именно что только при наличии истинного ГСЧ может быть реализован поистине шифр Вернама.
Рекомендую более подробно углубить знания в криптографии. Меня пугает, что этим продуктом мог бы кто-то в действительности воспользоваться, надеясь на мнимую безопасность.
Самый простой и элементарный вектор атаки - это обычный брутфорс 2^53 элементов (https://developer.mozilla.org/ru/docs/Web/JavaScript/Reference/Global_Objects/Math/random#примеры), что под силу почти любому государству или большой корпорации. Как только найдётся часть последовательности, которая при xor операции с шифртекстом будет выводить что-то осмысленное, это уже будет считаться взломом. С шифром Вернама, где взлом исчисляется бесконечностью, этот кандидат уж точно не вяжется.
Что касается более простых атак, то математический рандом является в основе своей линейным конгруэнтным генератором. И вот его линейность - это самый значимый недостаток.
Из этой формулы мы видим, что обладая числами a, b (которые зачастую являются константами) - мы можем двигаться в любом направлении - хоть назад, хоть вперёд. И так как выходной результат - это вход следующей итерации, то зная хотя бы часть ключа, мы сможем восстановить весь ключ. Что собственно также не вяжется с шифром Вернама, где ключ полностью является случайным и все его элементы равномерно и равноверятно распределены на всей последовательности. Существуют алгоритмы, которые могут восстановить последовательность и без знания (a, b).
Если вы будете считать, что "ключ же никому не будет отправляться, а если он как-то попал в руки третьей стороны, то это проблема пользователя" - то вы скорее наивны. Криптоаналитик вполне может делать предположения о шифртексте - он знает его размер, он может предположить, что в начале текста могут быть слова "Добрый день", "Привет", "Как дела?" и прочее. Из этого он уже будет получать перевес в вероятностях, которые смогут и будут помогать в раскрытии ключа этого ГПСЧ.
UPD. К тому же, по вашему скрину, - вы даже пробелы и спецсимволы не шифруете. Это рай для криптоаналитика, потому что видеть где конкретно располагаются слова и какой они длины - это уже >90% решённой задачи.
let key = '';
for (let i = 0; i < keySize; i++) {
const randomChar = String.fromCharCode(
printableStart + Math.floor(Math.random() * printableRange)
);
key += randomChar;
}
Здесь как минимум вместо математического генератора нужно использовать криптографический. Как максимум - настоящий ГСЧ, если предполагается, что это шифр Вернама
окей, что то похожее на битмесседж... но добавлена отправка раз в N секунд, что еще сильнее создает флуд в сети
Факт, из-за этого существуют хаки в виде подсетей, которые разграничивают разные сети между собой не позволяя им сливаться в одну. Технически можно построить соединения в HL и без проблемы масштабируемости, сведя саму генерацию лишь и только между непосредственными сетевыми узлами, но в таком случае становится необходимым не только логическое доверие (на уровне друзей), но и сетевое - к кому подключаешься.
не совсем понятно, как устроена доставка если пользователь которому адресовано сообщение был оффлайн ...
Раньше эту роль выполнял HLT, который сохранял N-ое количество сгенерированных сообщений, а узлы их подгружали в момент подключения к сети. В текущей реализации этот механизм был убран - возврат этой логики под вопросом. Легче создать логику на уровне прикладных сервисов, когда обмен сообщениями происходит при помощи "запрос-ответ", а процедура отправления сообщений - это их локальное сохранение в хранилище + отправка по сети.
... есть какое то подтверждение доставки или иной механизм?
Есть, существует два типа запросов - Send и Fetch. Первый отправляет сообщение без подтверждения, второй - с подтверждение (получением ответа). Если ответ при Fetch не был получен - выполняются ретраи. Логика при которой запрос был получен (обработан), а ответ - нет (из-за чего возникает ретрай), должна регулироваться уже прикладными сервисами.
не понятно что делать если ключ скомпроментирован, обычно делается основной ключ и ключ представляющий тебя в сети, <...>, а в этом проекте как?
В этом проекте существует долговременный ключ, который идентифицирует пользователя. Им шифруют сообщения, им подписываются сообщения (фактически это два ключа - ML-KEM + ML-DSA, интерпретируемые как один). Каждое сообщение шифруется одноразовым симметричным ключом, который инкапсулируется при помощи ML-KEM.
Если ключ скомпрометирован, то остаётся лишь менять старый ключ на новый и далее оповещать всех друзей о смене ключа (также по сторонним каналам связи). Сам факт компрометации - это, в массе своей, есть ошибка пользователя.
и смена ключа происходит безболезненно
Смена ключа при компрометации безболезненно нигде не проходит, особенно если это долговременные ключи.
Понятно. Более реалистично тогда это через личные сообщения провернуть, группы будут отлетать по бану очень быстро такие.
Недостаток в том, что будет существовать точно известная связь 1к1. Конечно можно объединить множество личных чатов в одну общую сеть, тем самым сделав 1кN сеть, но это будет отправление одинаковых сообщений по множеству чатов, что будет детектироваться как спам куда быстрее, чем писать по одному сообщению в групповой чат.
Энивэй, скорость такого взаимодействия, получается смехотворна...
Да, это факт, адаптация будет съедать и без того не быструю передачу данных.
Да и клиента, реализующего эту возможность, как я понимаю, пока не предвидится, хоть для того же ВК?
Пока есть возможность использовать другие виды связи, то не предвидится. На поддержку таких адаптеров будет уходить много времени, т.к. подобные централизованные сервисы достаточно часто могут менять алгоритмы вставки палок в колёса.
Технически это можно осуществить при помощи групповых чатов или комментариев под постами. Суть такая, что адаптерам HL необходимо реализовать две интерфейсные функции: Produce и Consume на группу пользователей. Если предположить, что это комментарии под постом, то Produce - это создание нового комментария, а Consume - это чтение недавно созданных комментариев.
Конечно будет опрометчиво говорить, что такая реализация адаптера будет простой. Баны и каптчи - никто не отменял. Из-за этого адаптер должен уметь не только продьюсить/консьюмить сообщения, но и должен уметь делать трафик более невидимым и по возможности решать проблемы с банами / каптчами.
По простому - скачать бинарники из релизных версий (тут - hlc и тут - hl-client) и просто их запустить. Этого будет достаточно, HLC запустит ноду, HL-Client подключится к ней. Чтобы HLC подключился к какому-либо внешнему ретранслятору / глобальной сети - нужно запустить узел с опцией `--network oi4r9NW9Le7fKF9d`. Через графический интерфейс HL-Client'а уже можно работать со всем добром - добавлять друзей, редактировать соединения и просто общаться.
В результате, действий получается не сильно много. Безусловно больше на один-два шага, чем в любой централизованной связи, но на деле не критично. Возможно подробности работы самой сети и её изменений, описанные в статье, придали вид сложности. На деле же, на более прикладном уровне, это работает плюс-минус просто.
Но скажите - вот есть такая модель OSI. Какие уровни покрывает ваша сеть?
Если натянуть сову на глобус, то думаю можно покрыть все уровни. Вопрос только зачем и для чего. OSI - это всё же модель, более подробная, чем TCP/IP, GP/12, но если последних хватает для описания задачи, то OSI становится просто-навсего оверинжинирингом.
Дело в том, что децентрализованных сетей (разной степени анонимности) много. Разных. Но на мой взгляд, ни одна из них полноценно не достигла самого верхнего уровня - назовем его условно "пользовательским"
Так проблема и не только в децентрализованных сетях. Нет такового приложения и в централизованных аналогах, которое покрывает весь пользовательский опыт. Мы пользуемся браузером, как хорошей абстракцией связывания множества услуг в одну. Проблема существования большого количества протоколов нацеленных на децентрализацию и плохая их применимость в реальной жизни связана в большей мере из-за того, что сама сеть Интернет поощрает централизацию в степени большей, чем децентрализацию. Из-за этого вытекает и куда бОльшая стандартизация централизованных решений.
Задумка прямого P2P-соединения хороша, но в реальном мире почти неосуществима. Вы убрали из модели угроз сервера, которые могли бы хранить метаданные о вас, вашем онлайн/оффлайн статусе, переписках и прочей активности - это хорошо. Тем не менее P2P-соединение - оно не является прямым, оно проходит сквозь множество маршрутизаторов провайдеров связи, фактически тех же серверов, всё также собирающих множество метаданных. Чтобы скрыть от них активность уже недостаточно обычной установки P2P-соединения в сети Интернет. В результате, мы получаем слегка пониженный риск сбора метаданных, но основной риск в лице майора - он остаётся.
Важно, чтобы DES не был замкнутой криптосистемой. Напомню, что криптосистема называется замкнутой, если для любых трёх ключей существуют ключи , такие что , для любого сообщения .
Что даёт условие ? Кажется, что достаточным будет только условие .
Команда мессенджера <...> заявила, что доступ к содержимому серверов невозможен чисто технически даже для инженеров (секретные чаты хранятся в зашифрованном виде, а ключи — на устройствах пользователей).
Вот это они конечно здорово соломенное чучело подложили под требование, которое к секретным чатам имеет лишь только косвенную связь. Все остальные то переписки, в отрыве от секретных чатов, хранятся на серверах телеграма ничуть не надёжнее какого-нибудь ВК.
В административной команде мессенджера подчеркнули, что коммуникационный сервис Telegram всегда активно модерировал вредоносный контент на своей платформе, соответствуя или превосходя все отраслевые стандарты.
И противоречий в их суждениях конечно же никаких не видно... Цирк какой-то.
Скорее всего предполагали в OpenAI использовать гомоморфное шифрование, а из-за некомпетентности то ли журналюк, то ли самих разработчиков - написали о сквозном шифровании.
Если использовать M3-систему вместо классического DH, то, как понимаю, логика с простыми числами будет отсутствовать? Но при таком сценарии разве не будет возникать малых подгрупп, количество элементов в которых будет меньше заданного N? Протокол DH использует для предотвращения этому надёжные простые числа вида p=2q+1.
Также, есть ли какие-нибудь бенчмарки M3-системы в сравнении с DH? Могу ошибаться, но кажется, что классический DH с переумножением чисел будет быстрее при условии, что модуль N в M3-системе сопоставим с модулем p в DH-протоколе.
Это интересно. Если всё так, то это действительно здорово. Есть ли статьи, где об этом можно почитать более подробно? Вроде и читал статьи / работы с сайта I2P, но конкретики по тому как ложный трафик генерируется, в какой пропорции и насколько он завязан на открытых текстах не нашёл - вполне возможно, что мог это и пропустить.
Он не "взламывает" AES так, как алгоритм Шора взламывает RSA, но он эффективно уменьшает стойкость ключа вдвое.
Если мы говорим про стойкость ключа (т.е. его сопротивляемость к полному перебору), то алгоритм Гровера уменьшает его не вдвое, а в раз. Вдвое он уменьшает именно что количество бит.
Если часто менять идентификаторы - возможно и будет сложно раскрыть связь клиентов, но здесь надо учитывать несколько моментов: доступ к сигналу придётся осуществлять всегда через анонимную сеть по типу Tor (чтобы сервер не мог идентифицировать клиентов по их IP-адресам), идентификаторы должны меняться постоянно (а это проблемное занятие, т.к. необходимо разграничивать собеседников от всех остальных, следовательно должна существовать и процедура какой да никакой аутентификации). При этом идентификаторы полностью исключить также невозможно, в том числе и SimpleX доказывает это своей концепцией очередей. Плюс к этому и поведение пользователей должно меняться - время отклика, частота общения, период начала и окончания разговора и т.д. Очень велика вероятность, что если сервер захочет - он сможет связать участников. Для осуществления такой анонимности требуется закрыть очень много переменных. Плюс к этому, всё вышеперечисленное также и не учитывает атаки в кооперации с другими наблюдателями, по типу локального или глобального, а это открывает ещё нехилый такой пласт векторов нападения.
Не путайте транспортную сеть с внутренней. IP-адреса есть у маршрутизаторов, но у узлов (публичные точки входного и выходного маршрутов) сети внутри I2P их нет.
Вот тут и был подвох в моём вопросе ) Централизация обеспечивает схожим образом и определённую долю анонимности при скрытии IP-адресов клиентов за счёт своей же маршрутизирующей функции от клиента к клиенту. Для сервера IP-адреса известны - это бесспорно, но вот для клиентов - они скрыты, мы обращаемся по идентификаторам. Сервер анонимизирует одного клиента от другого, а также от третьих сторон их общую связь. В такой концепции мы ровно также можем считать сервер маршрутизатором, а клиентов - узлами. Иными словами, в такой концепции особых отличий и нет между транспортной сетью и внутренней.
А какая разница, в одной или нет, если пакеты роутятся через случайные маршрутизаторы сети, вроде бы, даже специально подбирая проход через юрисдикции
Разница начинает себя проявлять при активных атаках, когда существует кооперация глобального наблюдателя и атакующего в роли клиента. Клиент может посылать запросы и получать ответы, сверяя результирующее время запрос-ответ. Глобальный наблюдатель может блокировать или замедлять часть сети для определения в каком подмножестве может находиться сервер. Клиент также может начать генерировать аномально большое количество трафика, а глобальный наблюдатель будет сверять точки принятия наибольшего количества пакетов.
Я не слышал о действенных. Для всех известных в сети встроены меры противодействия, в т.ч. постоянный «мусорный» трафик, имитирующий транзитный.
Мусорный / транзитный трафик не панацея, он не способен стереть разницу между истинным и мусорным трафиком, т.к. вместо замены одного другим - происходит наложение одного на другое. В результате, если количество истинного трафика будет увеличено многократно (аномально), а мусорного - нет, разницу будет видно.
Убрать телефон - это не полноценное решение проблемы анонимности. Сигнал сможет и без номера телефона, и даже без какого-либо явного идентификатора, успешно понимать кто и кому отправляет сообщения будучи централизованным сервисом. Сигнал пошёл по наиболее простому пути, не заморачиваясь с децентрализованной моделью, но сохраняя при этом более-менее корректную модель угроз, где предполагается конфиденциальность на базе E2E, но не предполагается анонимность. Но справедливости ради, наличие номера телефона действительно играет негативную роль, но лишь при комбинировании сетей, как например Signal+Tor. Явный идентификатор в таком случае начинает портить анонимность Tor'a, т.к. номера в основном привязываются к личности / паспортным данным.
Вы скорее всего не понимаете разницы между ГПСЧ и ГСЧ как таковыми - в одном случае есть точно заданный алгоритм генерации, в другом - алгоритма никакого нет. Если применяется ГПСЧ и таковой уязвим к атакам анализа, тарабарщину можно восстановить крайне просто (на примере ЛКГ):
Дано: "р щвао ку гевре в 8:88"
Предполагаем, что начало = "я буду"
Выполняем XOR операцию: "р щвао" XOR "я буду"
Получаем часть предполагаемого ключа в ГПСЧ = X
Подставляем данный X в формулу: (aX + b) (mod N) = Xi
Если Xi со следующими байтами шифртекста (по типу "ку гевре") даёт что-то осознанное - мы взломали шифр
Если нет - делаем другое предположение (возвращаемся к шагу 2)
Если бы вы сменили ГПСЧ / КСГПСЧ на ГСЧ - всё вами описанное действительно бы работало правильно. Но если вы используете ГПСЧ - это априори вред для конечных пользователей, даже обычные граждане смогут технически взломать данную систему шифрования, не говоря уже о спецслужбах. Если вы используете КСГПСЧ - ок, но смысла теперь от ключа размером в сообщение никакого нет, потому что генерируемая гамма держится на ключе, размер которого ограничен. Легче уж в таком случае просто отдавать пользователю ключ от КСГПСЧ, а не гамму, которая была им сгенерирована. Именно что только при наличии истинного ГСЧ может быть реализован поистине шифр Вернама.
Рекомендую более подробно углубить знания в криптографии. Меня пугает, что этим продуктом мог бы кто-то в действительности воспользоваться, надеясь на мнимую безопасность.
Самый простой и элементарный вектор атаки - это обычный брутфорс 2^53 элементов (https://developer.mozilla.org/ru/docs/Web/JavaScript/Reference/Global_Objects/Math/random#примеры), что под силу почти любому государству или большой корпорации. Как только найдётся часть последовательности, которая при xor операции с шифртекстом будет выводить что-то осмысленное, это уже будет считаться взломом. С шифром Вернама, где взлом исчисляется бесконечностью, этот кандидат уж точно не вяжется.
Что касается более простых атак, то математический рандом является в основе своей линейным конгруэнтным генератором. И вот его линейность - это самый значимый недостаток.
Из этой формулы мы видим, что обладая числами a, b (которые зачастую являются константами) - мы можем двигаться в любом направлении - хоть назад, хоть вперёд. И так как выходной результат - это вход следующей итерации, то зная хотя бы часть ключа, мы сможем восстановить весь ключ. Что собственно также не вяжется с шифром Вернама, где ключ полностью является случайным и все его элементы равномерно и равноверятно распределены на всей последовательности. Существуют алгоритмы, которые могут восстановить последовательность и без знания (a, b).
Если вы будете считать, что "ключ же никому не будет отправляться, а если он как-то попал в руки третьей стороны, то это проблема пользователя" - то вы скорее наивны. Криптоаналитик вполне может делать предположения о шифртексте - он знает его размер, он может предположить, что в начале текста могут быть слова "Добрый день", "Привет", "Как дела?" и прочее. Из этого он уже будет получать перевес в вероятностях, которые смогут и будут помогать в раскрытии ключа этого ГПСЧ.
UPD. К тому же, по вашему скрину, - вы даже пробелы и спецсимволы не шифруете. Это рай для криптоаналитика, потому что видеть где конкретно располагаются слова и какой они длины - это уже >90% решённой задачи.
Небезопасный какой-то шифратор получился...
Здесь как минимум вместо математического генератора нужно использовать криптографический. Как максимум - настоящий ГСЧ, если предполагается, что это шифр Вернама
Посвящается РКН
Скрытый текст
https://www.youtube.com/watch?v=bjXVfFfVtI4
Сори, не туда ответил: https://habr.com/ru/articles/996434/comments/#comment_29548278
Факт, из-за этого существуют хаки в виде подсетей, которые разграничивают разные сети между собой не позволяя им сливаться в одну. Технически можно построить соединения в HL и без проблемы масштабируемости, сведя саму генерацию лишь и только между непосредственными сетевыми узлами, но в таком случае становится необходимым не только логическое доверие (на уровне друзей), но и сетевое - к кому подключаешься.
Раньше эту роль выполнял HLT, который сохранял N-ое количество сгенерированных сообщений, а узлы их подгружали в момент подключения к сети. В текущей реализации этот механизм был убран - возврат этой логики под вопросом. Легче создать логику на уровне прикладных сервисов, когда обмен сообщениями происходит при помощи "запрос-ответ", а процедура отправления сообщений - это их локальное сохранение в хранилище + отправка по сети.
Есть, существует два типа запросов - Send и Fetch. Первый отправляет сообщение без подтверждения, второй - с подтверждение (получением ответа). Если ответ при Fetch не был получен - выполняются ретраи. Логика при которой запрос был получен (обработан), а ответ - нет (из-за чего возникает ретрай), должна регулироваться уже прикладными сервисами.
В этом проекте существует долговременный ключ, который идентифицирует пользователя. Им шифруют сообщения, им подписываются сообщения (фактически это два ключа - ML-KEM + ML-DSA, интерпретируемые как один). Каждое сообщение шифруется одноразовым симметричным ключом, который инкапсулируется при помощи ML-KEM.
Если ключ скомпрометирован, то остаётся лишь менять старый ключ на новый и далее оповещать всех друзей о смене ключа (также по сторонним каналам связи). Сам факт компрометации - это, в массе своей, есть ошибка пользователя.
Смена ключа при компрометации безболезненно нигде не проходит, особенно если это долговременные ключи.
Недостаток в том, что будет существовать точно известная связь 1к1. Конечно можно объединить множество личных чатов в одну общую сеть, тем самым сделав 1кN сеть, но это будет отправление одинаковых сообщений по множеству чатов, что будет детектироваться как спам куда быстрее, чем писать по одному сообщению в групповой чат.
Да, это факт, адаптация будет съедать и без того не быструю передачу данных.
Пока есть возможность использовать другие виды связи, то не предвидится. На поддержку таких адаптеров будет уходить много времени, т.к. подобные централизованные сервисы достаточно часто могут менять алгоритмы вставки палок в колёса.
Технически это можно осуществить при помощи групповых чатов или комментариев под постами. Суть такая, что адаптерам HL необходимо реализовать две интерфейсные функции: Produce и Consume на группу пользователей. Если предположить, что это комментарии под постом, то Produce - это создание нового комментария, а Consume - это чтение недавно созданных комментариев.
Конечно будет опрометчиво говорить, что такая реализация адаптера будет простой. Баны и каптчи - никто не отменял. Из-за этого адаптер должен уметь не только продьюсить/консьюмить сообщения, но и должен уметь делать трафик более невидимым и по возможности решать проблемы с банами / каптчами.
По простому - скачать бинарники из релизных версий (тут - hlc и тут - hl-client) и просто их запустить. Этого будет достаточно, HLC запустит ноду, HL-Client подключится к ней. Чтобы HLC подключился к какому-либо внешнему ретранслятору / глобальной сети - нужно запустить узел с опцией `--network oi4r9NW9Le7fKF9d`. Через графический интерфейс HL-Client'а уже можно работать со всем добром - добавлять друзей, редактировать соединения и просто общаться.
В результате, действий получается не сильно много. Безусловно больше на один-два шага, чем в любой централизованной связи, но на деле не критично. Возможно подробности работы самой сети и её изменений, описанные в статье, придали вид сложности. На деле же, на более прикладном уровне, это работает плюс-минус просто.
Если натянуть сову на глобус, то думаю можно покрыть все уровни. Вопрос только зачем и для чего. OSI - это всё же модель, более подробная, чем TCP/IP, GP/12, но если последних хватает для описания задачи, то OSI становится просто-навсего оверинжинирингом.
Так проблема и не только в децентрализованных сетях. Нет такового приложения и в централизованных аналогах, которое покрывает весь пользовательский опыт. Мы пользуемся браузером, как хорошей абстракцией связывания множества услуг в одну. Проблема существования большого количества протоколов нацеленных на децентрализацию и плохая их применимость в реальной жизни связана в большей мере из-за того, что сама сеть Интернет поощрает централизацию в степени большей, чем децентрализацию. Из-за этого вытекает и куда бОльшая стандартизация централизованных решений.
Задумка прямого P2P-соединения хороша, но в реальном мире почти неосуществима. Вы убрали из модели угроз сервера, которые могли бы хранить метаданные о вас, вашем онлайн/оффлайн статусе, переписках и прочей активности - это хорошо. Тем не менее P2P-соединение - оно не является прямым, оно проходит сквозь множество маршрутизаторов провайдеров связи, фактически тех же серверов, всё также собирающих множество метаданных. Чтобы скрыть от них активность уже недостаточно обычной установки P2P-соединения в сети Интернет. В результате, мы получаем слегка пониженный риск сбора метаданных, но основной риск в лице майора - он остаётся.
Что даёт условие
? Кажется, что достаточным будет только условие 
.
Вот это они конечно здорово соломенное чучело подложили под требование, которое к секретным чатам имеет лишь только косвенную связь. Все остальные то переписки, в отрыве от секретных чатов, хранятся на серверах телеграма ничуть не надёжнее какого-нибудь ВК.
И противоречий в их суждениях конечно же никаких не видно... Цирк какой-то.
Скорее всего предполагали в OpenAI использовать гомоморфное шифрование, а из-за некомпетентности то ли журналюк, то ли самих разработчиков - написали о сквозном шифровании.
Если использовать M3-систему вместо классического DH, то, как понимаю, логика с простыми числами будет отсутствовать? Но при таком сценарии разве не будет возникать малых подгрупп, количество элементов в которых будет меньше заданного N? Протокол DH использует для предотвращения этому надёжные простые числа вида p=2q+1.
Также, есть ли какие-нибудь бенчмарки M3-системы в сравнении с DH? Могу ошибаться, но кажется, что классический DH с переумножением чисел будет быстрее при условии, что модуль N в M3-системе сопоставим с модулем p в DH-протоколе.
Это интересно. Если всё так, то это действительно здорово. Есть ли статьи, где об этом можно почитать более подробно? Вроде и читал статьи / работы с сайта I2P, но конкретики по тому как ложный трафик генерируется, в какой пропорции и насколько он завязан на открытых текстах не нашёл - вполне возможно, что мог это и пропустить.
Если мы говорим про стойкость ключа (т.е. его сопротивляемость к полному перебору), то алгоритм Гровера уменьшает его не вдвое, а в
раз. Вдвое он уменьшает именно что количество бит.
Если часто менять идентификаторы - возможно и будет сложно раскрыть связь клиентов, но здесь надо учитывать несколько моментов: доступ к сигналу придётся осуществлять всегда через анонимную сеть по типу Tor (чтобы сервер не мог идентифицировать клиентов по их IP-адресам), идентификаторы должны меняться постоянно (а это проблемное занятие, т.к. необходимо разграничивать собеседников от всех остальных, следовательно должна существовать и процедура какой да никакой аутентификации). При этом идентификаторы полностью исключить также невозможно, в том числе и SimpleX доказывает это своей концепцией очередей. Плюс к этому и поведение пользователей должно меняться - время отклика, частота общения, период начала и окончания разговора и т.д. Очень велика вероятность, что если сервер захочет - он сможет связать участников. Для осуществления такой анонимности требуется закрыть очень много переменных. Плюс к этому, всё вышеперечисленное также и не учитывает атаки в кооперации с другими наблюдателями, по типу локального или глобального, а это открывает ещё нехилый такой пласт векторов нападения.
Вот тут и был подвох в моём вопросе ) Централизация обеспечивает схожим образом и определённую долю анонимности при скрытии IP-адресов клиентов за счёт своей же маршрутизирующей функции от клиента к клиенту. Для сервера IP-адреса известны - это бесспорно, но вот для клиентов - они скрыты, мы обращаемся по идентификаторам. Сервер анонимизирует одного клиента от другого, а также от третьих сторон их общую связь. В такой концепции мы ровно также можем считать сервер маршрутизатором, а клиентов - узлами. Иными словами, в такой концепции особых отличий и нет между транспортной сетью и внутренней.
Разница начинает себя проявлять при активных атаках, когда существует кооперация глобального наблюдателя и атакующего в роли клиента. Клиент может посылать запросы и получать ответы, сверяя результирующее время запрос-ответ. Глобальный наблюдатель может блокировать или замедлять часть сети для определения в каком подмножестве может находиться сервер. Клиент также может начать генерировать аномально большое количество трафика, а глобальный наблюдатель будет сверять точки принятия наибольшего количества пакетов.
Мусорный / транзитный трафик не панацея, он не способен стереть разницу между истинным и мусорным трафиком, т.к. вместо замены одного другим - происходит наложение одного на другое. В результате, если количество истинного трафика будет увеличено многократно (аномально), а мусорного - нет, разницу будет видно.
Убрать телефон - это не полноценное решение проблемы анонимности. Сигнал сможет и без номера телефона, и даже без какого-либо явного идентификатора, успешно понимать кто и кому отправляет сообщения будучи централизованным сервисом. Сигнал пошёл по наиболее простому пути, не заморачиваясь с децентрализованной моделью, но сохраняя при этом более-менее корректную модель угроз, где предполагается конфиденциальность на базе E2E, но не предполагается анонимность. Но справедливости ради, наличие номера телефона действительно играет негативную роль, но лишь при комбинировании сетей, как например Signal+Tor. Явный идентификатор в таком случае начинает портить анонимность Tor'a, т.к. номера в основном привязываются к личности / паспортным данным.