Не знаю, может ли это помочь хоть как-то, но схожие задачи в своё время я пытался решать. Одной из таковых стало переписывание ядра Tendermint на ГОСТ криптографию. В конечном итоге, я написал пакет на go, который использовал криптопровайдер КриптоПРО и импортировал его в tendermint, заменив все криптографические пакеты.
Не совсем понимаю при чём тут DES и 3DES, когда статья об Энигме. В самой статье я указал DES исключительно при грубом сравнении количества ключей с Энигмой. Си выбран с условием того, что его код понятен многим программистам, т.к. таковой является стандартом де-факто современных императивных языков программирования, в то время как результирующий код на C++ может быть сильно переусложнён конструкциями. Написанная мной программа на Си также базируется на объектах типа enigma_t и encoder_t, обладающих конкретно заданными функциями. Не обязательно использовать ООП языки, чтобы работать на уровне объектов. Спецификаторы классов extern и static я писал с условием того, что эти функции могут быть перенесены в отдельный файл, на уровень библиотеки. Тут и становится логичным применение static. Спецификатор extern здесь служит исключительно для понимания того, что такая функция умышленно предназначена для вызова извне. Копирование элементов массива необходимо для того, чтобы полностью отделить объект и его внутреннее состояние от внешних факторов, которые могли бы неявно его изменять. Это также сделано с условием, если таковой код будет использоваться где-либо ещё. Так что вот, все ответы.
Краткий ответ — ничего, если брать за основу общий вид централизованного сервиса и не принимать в расчёт его специфику, а также масштабы потребляемой/анализируемой пользовательской информации. Так например, если вы будете постоянно посылать сырые данные выходимые из анонимной сети (на примере HLS), которые будут иметь всегда фиксированный размер и конкретный JSON-формат с ключевыми словами, то централизованные системы смогут эффективно адаптироваться к подобному роду паразиту и относительно быстро ликвидировать его. Тем не менее, если суметь адаптировать тайный канал связи к специфике работы централизованного сервиса, ровно как это делают биологические паразиты с целью лучшей приспосабливаемости к телу хозяина, то таковой сервис может даже ничего и не заметить. Так например, если централизованный сервис представляет собой достаточно большую высоконагруженную систему, то генерируемый трафик в 0.2 RPS (загрузка 1MiB в 5 секунд) и 1 RPS (проверка новых сообщений) от каждого участника сети может быть даже незаметен такому сервису. Далее, адаптер типа Sender на своей стороне может как-либо скрывать поток информации "зашумляя" его примитивными методами, подобия дополнительного шифрования сообщения согласованным общим ключом всех участников. Это может достаточно сильно усложнить анализ трафика со стороны централизованного сервиса, потому что таким способом будет скрываться структура сырого сообщения в лице JSON-формата. Также никто не запрещает настраивать генерацию трафика на меньший RPS, ровно как и размер генерируемой информации (в HLS, если не изменяет память это примерно 10KiB). Хоть в таком случае, производительность анонимизации трафика будет действительно ухудшена, тем не менее, это поспособствует более успешному и продолжительному выживанию тайных каналов связи в наиболее восприимчивых и чувствительных централизованных системах, в которых либо не существует таких больших нагрузок, как в примере выше, либо происходит постоянный и более детальный анализ активности пользователей. Поэтому функции F и F-¹ в адаптерах Sender и Receiver соответственно, могут проделывать дополнительные действия с целью адаптации генерируемого сырого трафика в менее подозрительный.
А извиняюсь, почему-то я подумал вообще про вопрос по поводу процессора. Тут уже я туплю. На счёт распада атомов урана я возможно также погорячился, потому как там также действительно присутствуют гамма-кванты при распаде. Тем не менее, вопрос скорее остаётся в том, что распад испускает гамма-кванты, но является ли сам распад квантовым явлением, полностью непредсказуемым, как это должно происходить со стороны квантовой механики (потому как существуют иные, неквантовые частицы)?
Есть какая-нибудь ссылка на квантовые вычисления в процессорах настоящего времени? Я не исключаю, что такого не может быть, но если таковые присутствуют, то скорее всего они генерируют гамму крайне медленно. Иначе это шло бы в противоречие с существованием специализированных QRNG, которые выходят в свет несмотря на новшества процессоров. Нашёл такую статью с Intel'ом https://en.wikipedia.org/wiki/RDRAND, но о каких-либо квантовых вычислениях речи не идёт (сам источник конечно тоже не ахти).
Алгоритм представляет собой выражение компьютера.; Выражение представляет собой алгоритм компьютера.; ...еще 3 варианта
Ну на самом деле хуже становится. Мысль заключается в том, что компьютер - это есть алгоритм в физическом своём представлении. Так что два и три последующих варианта будут являться бессмыслицей.
То есть выясняем статистические свойства гаммы, а перед этим проводим с ней манипуляции типа суммирования по модулю, чтобы эти стат. свойства нормализовать? Логичный вопрос тут - какого черта?
Да. В качестве примера те же датчики шума кулера, которые могут часто выдавать повторяющиеся блоки, что в чистом виде сводило бы на нет их практическое использование в качестве ГСЧ. Алгоритмы накладываемые на сырую гамму способны улучшить её посредством определённых этапов "сжатия". Также и в описываемом мной ГСЧ, происходит сжатие блоков посредством их суммирования.
И главное - зачем всё это? Есть потребность в могучем потоке случайных чисел - расскажите какая, интересно же. Производство случайных штука дорогостоящая? Так поясните насколько, вот только не приводите в пример цену атомной электростанции, нерелевантно.
Дорогостоящая. Чтобы получить хорошее качества гаммы, становится необходимым объединение сразу нескольких источников энтропии - нескольких ГСЧ. Так например, крайне рискованно использовать один генератор и надеяться на то, что он будет выполнять свою роль всегда и безотказно хорошо. Некоторые датчики могут со временем приходить в негодность, некоторые могут барахлить в зависимости от условий эксплуатации, среды выполнения, некоторые требуют активности самого человека и т.д.
Всё это становится следствием дороговизны качественных ГСЧ, подобия того же распада атомов урана, или квантовых вычислений, или анализа погодных явлений в реальном времени. Качественные ГСЧ чаще всего стабильны и автономны, а их композиция с другими ГСЧ чаще всего излишня.
Потребность в могучем потоке случайных чисел действительно имеется. Сейчас все компьютеры, а точнее операционные системы, имеют внутри себя реализацию/реализации КСГПСЧ, потому что ГСЧ работают крайне медленно для настоящего времени. Проблема необходимости в постоянной генерации случайных чисел заключается в большей мере криптографическими особенностями. Необходимость генерировать случайные Nonce, подписывать передаваемые сообщения, использовать случайные векторы инициализации, генерировать асимметричную пару ключей и т.д. Эти механизмы работают постоянно и автономно, но они требуют всегда хорошего качества случайности. Если бы существовали недорогие ГСЧ, которые генерировали бы гамму быстро и при этом она являлась ещё бы и качественной, то многие КСГПСЧ стали бы просто ненужны. А так, в конечном итоге, мы переводим проблему случайности на псевдослучайные генераторы. В некоторых случаях даже КСГПСЧ могут быть сомнительным решением, допустим при генерации тех же асимметричных ключей. Тем не менее, последнее работает почти везде.
Как там обстоит со встроенными в процессоры физическими ГСЧ?
Ровно также как с шумом кулеров или другими физическими "карманными" ГСЧ. Процессор не может взять вне рамок себя какие-то случайные явления кроме состояния регистров в определённый промежуток времени, уровень своей нагруженности и т.д. В этом и состоит сложность, что в конце концов любое случайное явление должно относиться к физическому представлению, а последнее в свою очередь должно пытаться генерировать качественную меру неопределённости. Не исключение и ГСЧ на базе состояния гонки, где таковой, исходя из алгоритма, всё равно перенаправляет основные свои действия на манипуляцию с аппаратурой, а именно с тем как поступит CPU или GPU при параллельной записи в одну область памяти.
Чем сложнее система, тем больше шанс допустить в её архитектуре уязвимость. Безопасные системы должны быть просты, понятны, примитивны, открыты. Сложность - это буквально враг безопасности и когда кто-то делает навороченные приложения, добавляя всё больше новых фич, прослоек и "улучшений", где-то в мире начинает плакать один Шнайер.
Блокчейн - это не панацея, ровно также если мессенджер использует протокол Диффи-Хеллмана, то это не значит, что мессенджер безопасный. Блокчейн - это инструмент, который следует применять лишь по назначению и не пытаться натягивать сову на глобус.
При этом я не говорю, что Web3 - это плохо. Скорее Web3 являет собой переходную стадию к действительно безопасным приложениям, а не является точкой финализации. Web3 содержит в себе огромное количество противоречий, но способна совмещать в себе вполне безопасные действия (большинство проектов, тем не менее, небезопасны в действительности) с централизованным механизмам, за счёт которых подобные системы и живут.
Лисп, но несовсем обычный. Он эзотерический (в то время как LISP вполне себе нормальный язык программирования, в практическом смысле этого слова) и примитивный (даже с точки зрения LISP языков).
Эзотеричность выражается в его применении, а скорее даже в невозможности его нормального применения. Всё выполняется через неоптимизированные рекурсии, не существует ни ввода, ни вывода, почти каждая операция - это большое количество операций инкремента и декремента, которые находятся в рекурсивных вызовах. Это всё есть его ужасная сторона.
Примитивность его в нескольких деталях. Первая - это количество инструкций языка, их всего три штуки include, define и if. Не существует ни операций сложения, вычитания, умножения, деления и т.д. Тем не менее, он способен в себя их вбирать, но "соединяясь" с низкоуровневой частью. Вторая - это примитивность исполнения, где по умолчанию я в него вгрузил лишь операции инкремента, декремента и выражения больше, равно. Все остальные действия язык проводит сквозь уже свои инструкции, создавая сложение, вычитание и т.п. операции. Это всё есть его красивая сторона.
применение ЭЦП разрушает анонимность, персональные данные раскрываются
Не разрушает. ЭЦП может фигугировать конкретно в сетевых передачах для подтверждения истинности отправления, в роли аутентификации по публичному ключу и не более. Аутентификация != деанонимизация. Анонимность в вашем понимании уже используется на прикладном уровне, когда сами же пользователи своими транзакциями могут нарушать анонимность друг друга посредством сертификатов, в которых могут (опять таки могут) существовать персональные данные. Публичные ключи в чистом виде не выдают никакой информации и также могут применяться. В своём первом комментарии я это описал.
При этом сетевое кодирование здесь не играет роли — может быть, может не быть. У него своя задача — скрыть сетевой адрес отправителя.
Почему именно отправителя? Получателю анонимность не нужна? Или может им нужна только анонимность друг для друга или вовсе друг от друга? А может анонимность связи между друг другом?
Но если просто применить сетевое кодирование и использовать ЭЦП, то сетевой адрес будет скрыт, но не персональные данные. Что тут непонятного?
То что ЭЦП не факт, что относится к вами любимым сертификатам, а потому из-за ЭЦП персональные данные могут и не раскрываться вовсе. К тому же, и сертификаты могут не выдавать конкретной информации о пользователе, если последний "профильтрует" таковой сертификат, избавившись от всей персональной информации его однозначно идентифицирующей.
Если Вы считаете, что можно отказаться от сертификатов общедоступных ключей, то значит просто не понимаете фундаментальных вещей.
Отказаться в глобальном смысле - нет. Как минимум из-за самой централизованности большинства сетевых коммуникаций, где буквально проще и выгоднее пользоваться центрами сертификации. Отказаться в конкретике анонимных сетей - частично. В анонимных коммуникациях можно использовать доверенные соединения, исключающие сертификаты как таковые, в привычном их представлении.
Или же надо запретить использовать асимметричную криптографию?
Асимметричная криптография != сертификаты. Это я также описывал в первом комментарии.
Про «истинного злодея» — это Вы зря. Лицо теряете.
С каждым вашим комментарием у меня всё больше начинает возникать вопросов по вашей работе, при этом чётких ответов на поставленные мной вопросы я особо и не вижу. Вы буквально игнорируете большинство моих суждений к вашей критике и отвечаете вскользь лишь по некоторым выборочным. Тут либо вы не можете ответить на поставленные вопросы и как-то корректно на них ответить, либо просто лень, что также может приводить к первому пункту, как несостоятельности самой критики. Иначе, если была бы структуризация - были бы и ответы, не виляющие, не приводящие к таким высказываниям как:
Вы странный. Цитируете Трушину, а ведь эта цитата не подтверждает ваше утверждение, а опровергает его.
1) Как опровергает? За счёт чего?
2) Я лишь привёл Трушину как пример того, что вы скидываете литературу, которую вскользь прочитывали, потому что в этой диссертации чёрно по белому написано суждение того, что "Анонимность отправителя/получателя влечет за собой анонимность сеанса связи", с чем автор и соглашается.
Собственно это то, что вы пытались опровергать из доказательства в моей работе.
Одно не включает другого, тем более априори. Это разные вещи. Одно может быть, а другого может не быть.
Одно включает в себя другое = "Компрометация анонимности сеанса связи автоматически приводит к компрометации анонимности отправителя/получателя. В тоже время компрометация анонимности отправителя/получателя не приводит к компрометации анонимности сеанса связи". Это я также из работы Оксаны Вячеславовны.
"Одно может быть, а другого может не быть" - верно, но исключительно для несвязываемости. Таковая может существовать без ненаблюдаемости, а наоборот - нет. Тем не менее, вы пытались создать именно "конструктивное опровержение утверждения о том, что неотслеживаемость включает в себя анонимность". Это вовсе не об "Одно может быть, а другого может не быть".
И не надо валить всё в одну кучу. Об этом ясно написано в заметке и следует из приведенной цитаты.
Выше описал. Похоже больше на соломенное чучело. Говорите об одном, а в комментарии уже пишете о другом.
И не надо всуе рассуждать про исследование — в работе Трушиной такое исследование есть и конкретный результат есть.
Вообще не спорю. Я не научный работник и близко, тем не менее тему я изучаю, а также интересуюсь работами косвенно или прямо связанными с анонимностью. Но так или иначе, это уже даёт плоды, где я могу видеть непонимание или попытку ошибочного понимания определений связанных с анонимностью.
Противоречий каких-либо связанных с моей работой вы не привели ни одно, хотя и был хороший настрой:
Однако, если речь идёт о теории в классической трактовке, то необходимо обеспечить полноту и непротиворечивость положений, составляющих смысловое содержании последней. К сожалению, здесь имеются некоторые упущения, которые мы постараемся продемонстрировать при помощи простого контрпримера.
Если бы такие противоречия даже нашлись, я бы вам поблагодарил и исправил таковые. Но вы либо их умышленно скрыли (как истинный злодей), чтобы моя работа была хуже по содержанию, либо просто не нашли, либо что более вероятностно - даже мою статью не читали и вовсе, а просто привели ради красного словца, ради критики.
Это ведь диссертация, которая защищалась на совете. А перед этим были публикации в рецензируемых изданиях. У вас этого нет, но есть претензия на «теорию». Это вызывает тревогу.
Не обязательно быть учёным, чтобы что-то новое изобретать или придумывать, или исследовать. Из "неучённости", становится лишь более низкой вероятность действительно правильного исследования. Именно поэтому свою работу я делаю наиболее открытой и всем её рекомендую прочитать. Это одна из единственных вещей, которая может оставаться объективной и независимой от автора исследования. Если тревога вызвана этим - так прочитайте статью, найдите противоречия и укажите их. А так, сама ваша критика получилась откровенно сказать поверхностной до первых ссылок в гугле про таковые термины как "несвязываемость" и "ненаблюдаемость".
Уже есть таковые аудиты и довольно регулярно их применяют. Когда компания привлекает множество смарт-контрактников также начинает привлекать и сервисы аудита написанных ими кодов.
Люблю статьи про анононимность, особенно если таковая направлена на мою, даже в целях критики )
Тем не менее, я всё же вижу в данном тексте некое непонимание анонимности в целом и моей работы в частности, поэтому буду по порядку отвечать на ту или иную критику.
В первой части предлагается конструктивное опровержение утверждения о том, что неотслеживаемость включает в себя анонимность.
Давайте начнём с этого утверждения. В комментарии под статьёй "Структурный анализ сетевой анонимности", я указал доказательство того, что ненаблюдаемость априори включает в себя несвязываемость (у вас под анонимностью понималась несвязываемость, а под неотслеживаемостью - ненаблюдаемость соответственно).
Теперь обратимся к нескольким источникам, один из которых вы сами же и указали в комментарии - "Трушина Оксана Вячеславовна «Разработка теоретико-информационных методов обеспечения анонимности в телекоммуникационных сетях» по специальности 05.13.17 (Теоретические основы информатики)". Кстати отличная диссертация, по ней нет возражений и даже более скажу, многие тезисы сходятся из теоретической части. Даже с учётом того, что тематики разные в плане дальнейшего исследования.
В работе [23] утверждается, что анонимность сеанса связи гарантирует более слабую защиту по сравнению с анонимностью отправителя/получателя. Анонимность отправителя/получателя влечет за собой анонимность сеанса связи. Компрометация анонимности сеанса связи автоматически приводит к компрометации анонимности отправителя/получателя. В тоже время компрометация анонимности отправителя/получателя не приводит к компрометации анонимности сеанса связи. Действительно, если злоумышленник может определить отправителя или получателя сообщения, то анонимность сеанса связи сохраняется пока злоумышленник не может определить второго корреспондента. С другой стороны, сравнивать эти два вида анонимности некорректно, так как они преследуют разные цели. Анонимность сеанса связи не ставит своей задачей защитить отправителя или получателя, но скрыть связь между отправителем и получателем, то есть кто кому передает сообщения.
Переходим на 23 источник "Pfitzmann A., Hansen M. A terminology for talking about privacy by data minimization: Anonymity, Unlinkability, Undetectability, Unobservability, Pseudonymity, and Identity Management // http://dud.inf.tudresden.de/literatur/Anon_terminology_v0.34.pdf – 2010.". Запоминаем,
До количественного определения анонимности, сначала требовалось множество рабочих определений анонимности и других связанных концепцмй, таких как несвязываемость (unlinkability) или ненаблюдаемость (unobservability).
В [157] Пфитцман и Хансен1 предложили множество рабочих определений анонимности, несвязываемости, ненаблюдаемости и псевдонимности. Эти определения впоследствии были адаптированы в большинстве литературы по анонимности.
Сама данная работа ссылается на Пфитцмана и Хансена, работа которых также была указана в источниках Оксаны Вячеславовны в своей работе. Поэтому по поводу терминологии и доказательства я думаю здесь особо вопросов более не должно возникать.
Это можно сказать я наткнулся сразу на такое повествование с первых предложений, даже не начиная с моей критики. Т.к. я пишу комментарий последовательно, поточно, то боюсь представить, что будет далее с моей критикой.
востребованной на практике услуги безопасности как анонимность
Я бы не сказал, что таковая анонимность как либо востребована. Есть одно из главных противоречий между безопасностью (сюда вношу пока и анонимность) и комфортабельностью обычных пользователей. И как указывал Шнайер, люди выберут скорее удобную систему, чем безопасную. А т.к. анонимность представляет собой более высшую стадию, чем просто безопасность передаваемых данных, потому как должна скрывать ещё и инициаторов этих данных, то таковая система становится более медлительной и некомфортабельной. Востребованность становится крайне узка.
Автор для обозначения анонимности использует термин «несвязываемость». Мы ничего не имеем против новых терминов при условии, что они не дублируют уже существующие и привносят дополнительные смыслы. В данном случае нам не удалось уловить фокус предлагаемой новации.
Данный момент непонимания я уже развеял выше.
Для обозначения неотслеживаемости Автор применяет термин «ненаблюдаемость», который также не привносит ничего нового в смысловом плане.
Это также.
Итак, Автор рассуждает о неотслеживаемости. Основные положения можно считать верными, если бы не одно «но». Автор утверждает, что неотслеживаемость включает в себя анонимность.
Именно так оно и есть, в том числе указывая ваш источник (в комментарии) я это дополнительно доказал.
Следует сразу оговориться, что наша трактовка анонимности как услуги безопасности соответствует нормативной модели, в которой персональные данные не раскрываются ни субъектам взаимодействия, ни стороннему наблюдателю
Это крайне поверхностный тезис. Если для двух человек не существует анонимности (в данном случае речь идёт о идентификации как данных), иными словами, они идентифицируют себя открыто, но при этом нельзя узнать их состояния (отправляют ли они что-то или получают), то анонимности здесь также нет? Если ещё идти далее и предположить, что под данными здесь понимаются вообще любые данные, то это уже безопасность данных и зачем их скрывать от отправителя-получателя? Или под субъектами также понимаются промежуточные субъекты? Я бы поправил (уточнил) немного данное суждение.
По причине деактуализации анонимности и замены её на конфиденциальность представляется несостоятельной упрощённая модель, в которой персональные данные всегда известны субъектам, но при этом не раскрываются стороннему наблюдателю.
Если это было направлено на мою статью, то вот опровержение из моей же статьи:
Вышепредставленные пункты становятся также проблематичными в плане более подробного описания, потому как становится неизвестным условие – насколько отправитель и получатель анонимны друг к другу, и следует ли считать неанонимность друг к другу нарушением анонимности, тем более, если таковые связи строятся на взаимной деанонимизации друг друга. Поэтому следует учитывать ещё два дополнительных внутренних свойства, относящихся к любому из вышепредставленных пунктов:
1. Система разграничивает абонентов информации. В такой концепции существует три возможных случая: 1) отправитель анонимен к получателю, но получатель известен отправителю; 2) отправитель известен получателю, но получатель анонимен к отправителю; 3) отправитель и получатель анонимны друг к другу. Примером являются 1) анонимный доступ к открытому Интернет ресурсу; 2) анонимное получение информации из ботнет системы со стороны сервера-координатора; 3) анонимный доступ к скрытому ресурсу в анонимной сети.
2. Система связывает абонентов информации. В такой концепции отправитель и получатель известны друг к другу. Системы построенные на данном пункте часто ограничены в своём применении, но, так или иначе, остаются способными представлять анонимность субъектов, в том числе и на уровне критерия ненаблюдаемости (более подробно в подразделе «Модель на базе очередей» раздела «Абстрактные анонимные сети»).
Идём далее
Если взглянуть на проблематику шире, то разумно интерпретировать анонимность в контексте таких базовых услуг безопасности, как конфиденциальность, подлинность и целостность.
Нет, это термины конкретно безопасности. Анонимность и безопасность хоть и связаны между собой и в определённых контекстах могут нести такие же недостатки (подобия неудобности в применении чего-либо), но они также и вступают часто в открытое противоречие между собой. В качестве примера чистый DC-сети (проблема обедающих криптографов). В такой сети не существует ни конфиденциальности (все пользователи знают отправляемое и получаемое сообщение), ни целостности (сообщение могло быть подменено коллизиями), ни подлинности (в теории любой пользователь мог отправить сообщение). Тем не менее, это анонимная сеть, где отправитель остаётся анонимным и нельзя здесь как-либо сказать, что это не анонимная сеть вовсе. Есть сам факт - анонимность отправителя.
Передача отдельного зашифрованного сообщения гарантирует анонимность отправителя, но не получателя.
Отсутствие анонимности получателя объясняется тем, что его персональные данные известны отправителю и могут быть разглашены (отправитель не заинтересован в разглашении своих собственных персональных данных, но это правило может не распространяться на чужие персональные данные).
Действует простой принцип: «Если кто-то, кроме тебя самого, знает твои персональные данные, то они могут быть разглашены». Однако для обеспечения неотслеживаемости необходимо задействовать дополнительные средства, например воспользоваться сетевым кодированием. Здесь мы видим, что анонимность и неотслеживаемость существуют сами по себе и никак не коррелируют.
У вас здесь много путаницы.
Во-первых, могут существовать системы, где отправитель информации неанонимен, а получатель - анонимен. Даже есть прикладное применение в этой схеме - ботнет системы. Сервер должен оставаться анонимным, а отправители нейтральными к анонимности. Пример из моей статьи:
Примером таковых сетей может являться сеть, где отправитель транспортирует полностью зашифрованное сообщение всем участникам сети, расшифровать которое может только тот, у кого есть приватный ключ ориентированный на данное сообщение (если здесь конечно используется асимметричная криптография). Теоретически все могут узнать отправителя информации, но узнать получателя и есть ли он вообще крайне проблематично, потому как в теории получателем может оказаться каждый, т.к. каждый получает эти сообщения.
Во-вторых, даже если была бы ненаблюдаемость отправителя и получателя, но при этом они переписывались и один из них как-то в ходе переписки обранил бы паспорт, а после этого другой абонент разослал таковой документ всем остальным, то таковая "жертва" тоже бы стала деанонимизирована. Вы описывается, а точнее размываете, совершенно сторонние вещи и называете их отсутствием анонимности. В моей же работе, речь шла конкретно о сетевой анонимности, без вглядывание в то, как информация внутри канала связи будет "протекать". Меня интересовал сам канал связи и конкретно его анонимность, а не анонимность передаваемых по нему персональных данных.
В третьих, предположим, что существует анонимность отправителя и неанонимность получателя. Иными словами соблюдается критерий ненаблюдаемости для отправителя, а целью служит доказательство несвязываемости отправителя-получателя. Предположим, что существует некий атакующий, который смог посредством несвязываемости обнаружить отправителя и получателя. Таким образом, он смог сломать и ненаблюдаемость отправителя. Это говорит о том, что несвязываемость уже включается в ненаблюдаемость, и посредством неё может быть нарушена таковая ненаблюдаемость.
Валидность этой ЭЦП свидетельствует о подлинности общедоступного ключа из сертификата. Как мы отметили выше, сертификат также содержит персональные данные заверителя. Это в свою очередь означает, что анонимность невозможна. Совершенно неважно, обеспечивается при этом неотслеживаемость или нет.
Если нужна анонимность, может легче тогда использовать чистый публичный ключ вместо сертификата? Публичный ключ также может заверяться кем-либо посредством связки ключ-значения = "идентификатор":"публичный ключ".
Сообщение можно сначала заверить ЭЦП при помощи секретного ключа отправителя, а потом зашифровать на общедоступном ключе получателя. Очевидно, что такая схема также не обеспечивает анонимности субъектов взаимодействия.
Почему и как это приводит к деанонимизации? Тут уже и додумать что-либо сложновато. Из вышеописанного я уже всё основное описал.
Это тот самый контрпример, который указывает на несостоятельность «доказательства», представленного Автором.
Контрпример оказался солянкой, где участвуют персональные данные, несвязываемость и ненаблюдаемость, сертификаты в одной составляющей. И опять таки, это доказательство было сформулировано ещё задолго до моей публикации, в том числе и в вашей литературе.
Логично заключить, что анонимность достижима при отказе от сертификатов общедоступных ключей. Иногда это оправдано (подробнее), однако при решении подавляющего большинства конвенциональных задач такое радикальное отступление от принципов асимметричной криптографии приводит к дискредитации базовых услуг безопасности.
Невозможно полностью отказаться от асимметричной криптографии.
Асимметричная криптография != сертификаты (или между абзацами была какая-то другая мысль, которая просто была удалена). Система сертификатов может работать на нескольких моделях. Чаще всего используемая - это централизованная, где существуют конкретно выделяемые центры сертификации. Наверное здесь не стоит объяснять, что централизация часто идёт в некое противоречие с анонимными сетями, которые обязаны быть, по своей сути, минимум гибридными системами. Иначе будут образовываться 1) узкие места в отказоустойчивости, 2) узкие места в анонимности. Есть также и другие системы сертификации - это сети доверенных соединений, в которых участники субъективно выставляют уровни доверия к другим участникам. Получение сертификатов (или публичных ключей) осуществляется посредством внутренней передачи таковой информации, без обращения к центрам сертификации. Как раз по второму пункту анонимные сети и могут существовать и быть анонимными структурами.
Последующие рассуждения уже к моей работе как-либо не относятся.
Нет, такого типа идентификации точно не должно быть. На самом деле, регистрация и идентификация уже в мессенджере существует, но лишь на уровне сети, где под регистрацией понимается генерация приватного ключа, а под идентификацией использование пары приватный/публичный ключей в сети.
Планируемая регистрация - это локальная регистрация по паролю. Сейчас проблема мессенджера заключается в том, что когда запускаешь HLS, он автоматически начинает работать от приватного ключа, расположенного в файле в открытом виде.
Введённый пароль пользователем может быть использован для шифрования и расшифрования приватного ключа, в следствие чего сам приватный ключ будет храниться у клиента в защищённом виде. Успешность расшифрования приватного ключа будет свидетельствовать об авторизации, разблокирующей последующую идентификацию пользователя.
На счёт первого случая согласен, недавно только его исправлял (на данный момент локально). Ранее по логике client был учтён для получения публичного ключа, сейчас та часть логики была вырезана из-за ненадобности как таковой.
На счёт HandleServiceTCP. Логика return nil сводится к тому, что поступили некорректные данные от какого-либо пользователя в сети, и как следствие их не следует обрабатывать и посылать таковому узлу ответ, либо сам принимающий некорректно выставил роуты. Если пользователь валидный, тогда он должен априори придерживаться ровно такого же списка правил и позволенных действий. Несогласованность параметров является технической ошибкой.
Анонимность заключается в невозможности определить состояние пользователя - отправляет ли он какую-то информацию, получает её или бездействует. Из этого, как следствие, становится невозможным определение - связывается ли он вообще хоть с кем-то в анализируемой сети. IP адреса здесь представляются лишь как множество всех участников сети, но идентификация и истинная маршрутизация между пользователями осуществляется на криптографическом уровне.
Для общего развития почему бы и нет. Tor и VPN хоть это и классика, но существуют куда более интересные способы анонимизации сетевого траффика. Так например, DC-сети (обедающие криптографы) представляют интересную модель анонимизации. В отличие от Tor или VPN такие сети могут предоставлять теоретически доказуемую анонимность участников. Другая сеть - Crowds интересна своей вероятностной маршрутизацией (хоть и неустойчивой к некоторым атакам). Некоторые сети, не анонимные, подобия Bitmessage имеют интересные способы идентификации участников в сети без необходимости знать и понимать где они находятся и к кому надо подключаться для связи с конкретным абонентом. В общем спектр разнородных технологий и работ был проделан достаточно большой, где можно найти ещё много чего интересного.
Сколько много душнил в хабре появилось, которые по существу так и не способны ничего сказать, кроме как придираться к неоднозначности единственного термина со стороны перевода, не читая при этом саму статью.
Вы уж удосудьтесь сначала прочитать, выделить все недостатки, а потом уже указывать нестыковки и противоречия. То что вы указали - это цирк на потеху публике, которая кстати по соотношению плюсов/минусов действительно любит хавать такую низкосортную критику.
Не знаю, может ли это помочь хоть как-то, но схожие задачи в своё время я пытался решать. Одной из таковых стало переписывание ядра Tendermint на ГОСТ криптографию. В конечном итоге, я написал пакет на go, который использовал криптопровайдер КриптоПРО и импортировал его в tendermint, заменив все криптографические пакеты.
ГОСТ tendermint: https://github.com/number571/tendermint
Пакет go-cryptopro: https://github.com/number571/go-cryptopro
Хоть сейчас этот проект я уже не поддерживаю, но может какие-то детали из него могут быть полезны.
Думаю "Практическая криптография" от Шнайера и Фергюсона подойдёт.
Не совсем понимаю при чём тут DES и 3DES, когда статья об Энигме. В самой статье я указал DES исключительно при грубом сравнении количества ключей с Энигмой.
Си выбран с условием того, что его код понятен многим программистам, т.к. таковой является стандартом де-факто современных императивных языков программирования, в то время как результирующий код на C++ может быть сильно переусложнён конструкциями.
Написанная мной программа на Си также базируется на объектах типа enigma_t и encoder_t, обладающих конкретно заданными функциями. Не обязательно использовать ООП языки, чтобы работать на уровне объектов.
Спецификаторы классов extern и static я писал с условием того, что эти функции могут быть перенесены в отдельный файл, на уровень библиотеки. Тут и становится логичным применение static. Спецификатор extern здесь служит исключительно для понимания того, что такая функция умышленно предназначена для вызова извне.
Копирование элементов массива необходимо для того, чтобы полностью отделить объект и его внутреннее состояние от внешних факторов, которые могли бы неявно его изменять. Это также сделано с условием, если таковой код будет использоваться где-либо ещё.
Так что вот, все ответы.
Краткий ответ — ничего, если брать за основу общий вид централизованного сервиса и не принимать в расчёт его специфику, а также масштабы потребляемой/анализируемой пользовательской информации.
Так например, если вы будете постоянно посылать сырые данные выходимые из анонимной сети (на примере HLS), которые будут иметь всегда фиксированный размер и конкретный JSON-формат с ключевыми словами, то централизованные системы смогут эффективно адаптироваться к подобному роду паразиту и относительно быстро ликвидировать его.
Тем не менее, если суметь адаптировать тайный канал связи к специфике работы централизованного сервиса, ровно как это делают биологические паразиты с целью лучшей приспосабливаемости к телу хозяина, то таковой сервис может даже ничего и не заметить.
Так например, если централизованный сервис представляет собой достаточно большую высоконагруженную систему, то генерируемый трафик в 0.2 RPS (загрузка 1MiB в 5 секунд) и 1 RPS (проверка новых сообщений) от каждого участника сети может быть даже незаметен такому сервису. Далее, адаптер типа Sender на своей стороне может как-либо скрывать поток информации "зашумляя" его примитивными методами, подобия дополнительного шифрования сообщения согласованным общим ключом всех участников. Это может достаточно сильно усложнить анализ трафика со стороны централизованного сервиса, потому что таким способом будет скрываться структура сырого сообщения в лице JSON-формата.
Также никто не запрещает настраивать генерацию трафика на меньший RPS, ровно как и размер генерируемой информации (в HLS, если не изменяет память это примерно 10KiB). Хоть в таком случае, производительность анонимизации трафика будет действительно ухудшена, тем не менее, это поспособствует более успешному и продолжительному выживанию тайных каналов связи в наиболее восприимчивых и чувствительных централизованных системах, в которых либо не существует таких больших нагрузок, как в примере выше, либо происходит постоянный и более детальный анализ активности пользователей. Поэтому функции F и F-¹ в адаптерах Sender и Receiver соответственно, могут проделывать дополнительные действия с целью адаптации генерируемого сырого трафика в менее подозрительный.
А извиняюсь, почему-то я подумал вообще про вопрос по поводу процессора. Тут уже я туплю. На счёт распада атомов урана я возможно также погорячился, потому как там также действительно присутствуют гамма-кванты при распаде. Тем не менее, вопрос скорее остаётся в том, что распад испускает гамма-кванты, но является ли сам распад квантовым явлением, полностью непредсказуемым, как это должно происходить со стороны квантовой механики (потому как существуют иные, неквантовые частицы)?
Есть какая-нибудь ссылка на квантовые вычисления в процессорах настоящего времени? Я не исключаю, что такого не может быть, но если таковые присутствуют, то скорее всего они генерируют гамму крайне медленно. Иначе это шло бы в противоречие с существованием специализированных QRNG, которые выходят в свет несмотря на новшества процессоров. Нашёл такую статью с Intel'ом https://en.wikipedia.org/wiki/RDRAND, но о каких-либо квантовых вычислениях речи не идёт (сам источник конечно тоже не ахти).
Ну на самом деле хуже становится. Мысль заключается в том, что компьютер - это есть алгоритм в физическом своём представлении. Так что два и три последующих варианта будут являться бессмыслицей.
Да. В качестве примера те же датчики шума кулера, которые могут часто выдавать повторяющиеся блоки, что в чистом виде сводило бы на нет их практическое использование в качестве ГСЧ. Алгоритмы накладываемые на сырую гамму способны улучшить её посредством определённых этапов "сжатия". Также и в описываемом мной ГСЧ, происходит сжатие блоков посредством их суммирования.
Дорогостоящая. Чтобы получить хорошее качества гаммы, становится необходимым объединение сразу нескольких источников энтропии - нескольких ГСЧ. Так например, крайне рискованно использовать один генератор и надеяться на то, что он будет выполнять свою роль всегда и безотказно хорошо. Некоторые датчики могут со временем приходить в негодность, некоторые могут барахлить в зависимости от условий эксплуатации, среды выполнения, некоторые требуют активности самого человека и т.д.
Всё это становится следствием дороговизны качественных ГСЧ, подобия того же распада атомов урана, или квантовых вычислений, или анализа погодных явлений в реальном времени. Качественные ГСЧ чаще всего стабильны и автономны, а их композиция с другими ГСЧ чаще всего излишня.
Потребность в могучем потоке случайных чисел действительно имеется. Сейчас все компьютеры, а точнее операционные системы, имеют внутри себя реализацию/реализации КСГПСЧ, потому что ГСЧ работают крайне медленно для настоящего времени. Проблема необходимости в постоянной генерации случайных чисел заключается в большей мере криптографическими особенностями. Необходимость генерировать случайные Nonce, подписывать передаваемые сообщения, использовать случайные векторы инициализации, генерировать асимметричную пару ключей и т.д. Эти механизмы работают постоянно и автономно, но они требуют всегда хорошего качества случайности. Если бы существовали недорогие ГСЧ, которые генерировали бы гамму быстро и при этом она являлась ещё бы и качественной, то многие КСГПСЧ стали бы просто ненужны. А так, в конечном итоге, мы переводим проблему случайности на псевдослучайные генераторы. В некоторых случаях даже КСГПСЧ могут быть сомнительным решением, допустим при генерации тех же асимметричных ключей. Тем не менее, последнее работает почти везде.
Ровно также как с шумом кулеров или другими физическими "карманными" ГСЧ. Процессор не может взять вне рамок себя какие-то случайные явления кроме состояния регистров в определённый промежуток времени, уровень своей нагруженности и т.д. В этом и состоит сложность, что в конце концов любое случайное явление должно относиться к физическому представлению, а последнее в свою очередь должно пытаться генерировать качественную меру неопределённости. Не исключение и ГСЧ на базе состояния гонки, где таковой, исходя из алгоритма, всё равно перенаправляет основные свои действия на манипуляцию с аппаратурой, а именно с тем как поступит CPU или GPU при параллельной записи в одну область памяти.
Чем сложнее система, тем больше шанс допустить в её архитектуре уязвимость. Безопасные системы должны быть просты, понятны, примитивны, открыты. Сложность - это буквально враг безопасности и когда кто-то делает навороченные приложения, добавляя всё больше новых фич, прослоек и "улучшений", где-то в мире начинает плакать один Шнайер.
Блокчейн - это не панацея, ровно также если мессенджер использует протокол Диффи-Хеллмана, то это не значит, что мессенджер безопасный. Блокчейн - это инструмент, который следует применять лишь по назначению и не пытаться натягивать сову на глобус.
При этом я не говорю, что Web3 - это плохо. Скорее Web3 являет собой переходную стадию к действительно безопасным приложениям, а не является точкой финализации. Web3 содержит в себе огромное количество противоречий, но способна совмещать в себе вполне безопасные действия (большинство проектов, тем не менее, небезопасны в действительности) с централизованным механизмам, за счёт которых подобные системы и живут.
По этому поводу я также писал статью https://habr.com/ru/post/696350/ .
Лисп, но несовсем обычный. Он эзотерический (в то время как LISP вполне себе нормальный язык программирования, в практическом смысле этого слова) и примитивный (даже с точки зрения LISP языков).
Эзотеричность выражается в его применении, а скорее даже в невозможности его нормального применения. Всё выполняется через неоптимизированные рекурсии, не существует ни ввода, ни вывода, почти каждая операция - это большое количество операций инкремента и декремента, которые находятся в рекурсивных вызовах. Это всё есть его ужасная сторона.
Примитивность его в нескольких деталях. Первая - это количество инструкций языка, их всего три штуки include, define и if. Не существует ни операций сложения, вычитания, умножения, деления и т.д. Тем не менее, он способен в себя их вбирать, но "соединяясь" с низкоуровневой частью. Вторая - это примитивность исполнения, где по умолчанию я в него вгрузил лишь операции инкремента, декремента и выражения больше, равно. Все остальные действия язык проводит сквозь уже свои инструкции, создавая сложение, вычитание и т.п. операции. Это всё есть его красивая сторона.
Не разрушает. ЭЦП может фигугировать конкретно в сетевых передачах для подтверждения истинности отправления, в роли аутентификации по публичному ключу и не более. Аутентификация != деанонимизация. Анонимность в вашем понимании уже используется на прикладном уровне, когда сами же пользователи своими транзакциями могут нарушать анонимность друг друга посредством сертификатов, в которых могут (опять таки могут) существовать персональные данные. Публичные ключи в чистом виде не выдают никакой информации и также могут применяться. В своём первом комментарии я это описал.
Почему именно отправителя? Получателю анонимность не нужна? Или может им нужна только анонимность друг для друга или вовсе друг от друга? А может анонимность связи между друг другом?
То что ЭЦП не факт, что относится к вами любимым сертификатам, а потому из-за ЭЦП персональные данные могут и не раскрываться вовсе. К тому же, и сертификаты могут не выдавать конкретной информации о пользователе, если последний "профильтрует" таковой сертификат, избавившись от всей персональной информации его однозначно идентифицирующей.
Отказаться в глобальном смысле - нет. Как минимум из-за самой централизованности большинства сетевых коммуникаций, где буквально проще и выгоднее пользоваться центрами сертификации. Отказаться в конкретике анонимных сетей - частично. В анонимных коммуникациях можно использовать доверенные соединения, исключающие сертификаты как таковые, в привычном их представлении.
Асимметричная криптография != сертификаты. Это я также описывал в первом комментарии.
С каждым вашим комментарием у меня всё больше начинает возникать вопросов по вашей работе, при этом чётких ответов на поставленные мной вопросы я особо и не вижу. Вы буквально игнорируете большинство моих суждений к вашей критике и отвечаете вскользь лишь по некоторым выборочным. Тут либо вы не можете ответить на поставленные вопросы и как-то корректно на них ответить, либо просто лень, что также может приводить к первому пункту, как несостоятельности самой критики. Иначе, если была бы структуризация - были бы и ответы, не виляющие, не приводящие к таким высказываниям как:
Поэтому ещё вопрос, кто теряет лицо.
1) Как опровергает? За счёт чего?
2) Я лишь привёл Трушину как пример того, что вы скидываете литературу, которую вскользь прочитывали, потому что в этой диссертации чёрно по белому написано суждение того, что "Анонимность отправителя/получателя влечет за собой анонимность сеанса связи", с чем автор и соглашается.
Собственно это то, что вы пытались опровергать из доказательства в моей работе.
Одно включает в себя другое = "Компрометация анонимности сеанса связи автоматически приводит к компрометации анонимности отправителя/получателя. В тоже время компрометация анонимности отправителя/получателя не приводит к компрометации анонимности сеанса связи". Это я также из работы Оксаны Вячеславовны.
"Одно может быть, а другого может не быть" - верно, но исключительно для несвязываемости. Таковая может существовать без ненаблюдаемости, а наоборот - нет. Тем не менее, вы пытались создать именно "конструктивное опровержение утверждения о том, что неотслеживаемость включает в себя анонимность". Это вовсе не об "Одно может быть, а другого может не быть".
Выше описал. Похоже больше на соломенное чучело. Говорите об одном, а в комментарии уже пишете о другом.
Вообще не спорю. Я не научный работник и близко, тем не менее тему я изучаю, а также интересуюсь работами косвенно или прямо связанными с анонимностью. Но так или иначе, это уже даёт плоды, где я могу видеть непонимание или попытку ошибочного понимания определений связанных с анонимностью.
Противоречий каких-либо связанных с моей работой вы не привели ни одно, хотя и был хороший настрой:
Если бы такие противоречия даже нашлись, я бы вам поблагодарил и исправил таковые. Но вы либо их умышленно скрыли (как истинный злодей), чтобы моя работа была хуже по содержанию, либо просто не нашли, либо что более вероятностно - даже мою статью не читали и вовсе, а просто привели ради красного словца, ради критики.
Не обязательно быть учёным, чтобы что-то новое изобретать или придумывать, или исследовать. Из "неучённости", становится лишь более низкой вероятность действительно правильного исследования. Именно поэтому свою работу я делаю наиболее открытой и всем её рекомендую прочитать. Это одна из единственных вещей, которая может оставаться объективной и независимой от автора исследования. Если тревога вызвана этим - так прочитайте статью, найдите противоречия и укажите их. А так, сама ваша критика получилась откровенно сказать поверхностной до первых ссылок в гугле про таковые термины как "несвязываемость" и "ненаблюдаемость".
Уже есть таковые аудиты и довольно регулярно их применяют. Когда компания привлекает множество смарт-контрактников также начинает привлекать и сервисы аудита написанных ими кодов.
Ответил.
Дочитал c:
Люблю статьи про анононимность, особенно если таковая направлена на мою, даже в целях критики )
Тем не менее, я всё же вижу в данном тексте некое непонимание анонимности в целом и моей работы в частности, поэтому буду по порядку отвечать на ту или иную критику.
Давайте начнём с этого утверждения. В комментарии под статьёй "Структурный анализ сетевой анонимности", я указал доказательство того, что ненаблюдаемость априори включает в себя несвязываемость (у вас под анонимностью понималась несвязываемость, а под неотслеживаемостью - ненаблюдаемость соответственно).
Теперь обратимся к нескольким источникам, один из которых вы сами же и указали в комментарии - "Трушина Оксана Вячеславовна «Разработка теоретико-информационных
методов обеспечения анонимности в телекоммуникационных сетях» по
специальности 05.13.17 (Теоретические основы информатики)". Кстати отличная диссертация, по ней нет возражений и даже более скажу, многие тезисы сходятся из теоретической части. Даже с учётом того, что тематики разные в плане дальнейшего исследования.
Переходим на 23 источник "Pfitzmann A., Hansen M. A terminology for talking about privacy by data minimization: Anonymity, Unlinkability, Undetectability, Unobservability, Pseudonymity, and Identity Management // http://dud.inf.tudresden.de/literatur/Anon_terminology_v0.34.pdf – 2010.". Запоминаем,
Теперь другая, вторая работа из которой я 1) таковые термины брал, 2) использовал для доказательства - https://www.pgpru.com/biblioteka/statji/sac
Сама данная работа ссылается на Пфитцмана и Хансена, работа которых также была указана в источниках Оксаны Вячеславовны в своей работе. Поэтому по поводу терминологии и доказательства я думаю здесь особо вопросов более не должно возникать.
Это можно сказать я наткнулся сразу на такое повествование с первых предложений, даже не начиная с моей критики. Т.к. я пишу комментарий последовательно, поточно, то боюсь представить, что будет далее с моей критикой.
Я бы не сказал, что таковая анонимность как либо востребована. Есть одно из главных противоречий между безопасностью (сюда вношу пока и анонимность) и комфортабельностью обычных пользователей. И как указывал Шнайер, люди выберут скорее удобную систему, чем безопасную. А т.к. анонимность представляет собой более высшую стадию, чем просто безопасность передаваемых данных, потому как должна скрывать ещё и инициаторов этих данных, то таковая система становится более медлительной и некомфортабельной. Востребованность становится крайне узка.
Данный момент непонимания я уже развеял выше.
Это также.
Именно так оно и есть, в том числе указывая ваш источник (в комментарии) я это дополнительно доказал.
Это крайне поверхностный тезис. Если для двух человек не существует анонимности (в данном случае речь идёт о идентификации как данных), иными словами, они идентифицируют себя открыто, но при этом нельзя узнать их состояния (отправляют ли они что-то или получают), то анонимности здесь также нет? Если ещё идти далее и предположить, что под данными здесь понимаются вообще любые данные, то это уже безопасность данных и зачем их скрывать от отправителя-получателя? Или под субъектами также понимаются промежуточные субъекты? Я бы поправил (уточнил) немного данное суждение.
Если это было направлено на мою статью, то вот опровержение из моей же статьи:
Идём далее
Нет, это термины конкретно безопасности. Анонимность и безопасность хоть и связаны между собой и в определённых контекстах могут нести такие же недостатки (подобия неудобности в применении чего-либо), но они также и вступают часто в открытое противоречие между собой. В качестве примера чистый DC-сети (проблема обедающих криптографов). В такой сети не существует ни конфиденциальности (все пользователи знают отправляемое и получаемое сообщение), ни целостности (сообщение могло быть подменено коллизиями), ни подлинности (в теории любой пользователь мог отправить сообщение). Тем не менее, это анонимная сеть, где отправитель остаётся анонимным и нельзя здесь как-либо сказать, что это не анонимная сеть вовсе. Есть сам факт - анонимность отправителя.
У вас здесь много путаницы.
Во-первых, могут существовать системы, где отправитель информации неанонимен, а получатель - анонимен. Даже есть прикладное применение в этой схеме - ботнет системы. Сервер должен оставаться анонимным, а отправители нейтральными к анонимности. Пример из моей статьи:
Во-вторых, даже если была бы ненаблюдаемость отправителя и получателя, но при этом они переписывались и один из них как-то в ходе переписки обранил бы паспорт, а после этого другой абонент разослал таковой документ всем остальным, то таковая "жертва" тоже бы стала деанонимизирована. Вы описывается, а точнее размываете, совершенно сторонние вещи и называете их отсутствием анонимности. В моей же работе, речь шла конкретно о сетевой анонимности, без вглядывание в то, как информация внутри канала связи будет "протекать". Меня интересовал сам канал связи и конкретно его анонимность, а не анонимность передаваемых по нему персональных данных.
В третьих, предположим, что существует анонимность отправителя и неанонимность получателя. Иными словами соблюдается критерий ненаблюдаемости для отправителя, а целью служит доказательство несвязываемости отправителя-получателя. Предположим, что существует некий атакующий, который смог посредством несвязываемости обнаружить отправителя и получателя. Таким образом, он смог сломать и ненаблюдаемость отправителя. Это говорит о том, что несвязываемость уже включается в ненаблюдаемость, и посредством неё может быть нарушена таковая ненаблюдаемость.
Если нужна анонимность, может легче тогда использовать чистый публичный ключ вместо сертификата? Публичный ключ также может заверяться кем-либо посредством связки ключ-значения = "идентификатор":"публичный ключ".
Почему и как это приводит к деанонимизации? Тут уже и додумать что-либо сложновато. Из вышеописанного я уже всё основное описал.
Контрпример оказался солянкой, где участвуют персональные данные, несвязываемость и ненаблюдаемость, сертификаты в одной составляющей. И опять таки, это доказательство было сформулировано ещё задолго до моей публикации, в том числе и в вашей литературе.
Асимметричная криптография != сертификаты (или между абзацами была какая-то другая мысль, которая просто была удалена). Система сертификатов может работать на нескольких моделях. Чаще всего используемая - это централизованная, где существуют конкретно выделяемые центры сертификации. Наверное здесь не стоит объяснять, что централизация часто идёт в некое противоречие с анонимными сетями, которые обязаны быть, по своей сути, минимум гибридными системами. Иначе будут образовываться 1) узкие места в отказоустойчивости, 2) узкие места в анонимности. Есть также и другие системы сертификации - это сети доверенных соединений, в которых участники субъективно выставляют уровни доверия к другим участникам. Получение сертификатов (или публичных ключей) осуществляется посредством внутренней передачи таковой информации, без обращения к центрам сертификации. Как раз по второму пункту анонимные сети и могут существовать и быть анонимными структурами.
Последующие рассуждения уже к моей работе как-либо не относятся.
Нет, такого типа идентификации точно не должно быть. На самом деле, регистрация и идентификация уже в мессенджере существует, но лишь на уровне сети, где под регистрацией понимается генерация приватного ключа, а под идентификацией использование пары приватный/публичный ключей в сети.
Планируемая регистрация - это локальная регистрация по паролю. Сейчас проблема мессенджера заключается в том, что когда запускаешь HLS, он автоматически начинает работать от приватного ключа, расположенного в файле в открытом виде.
Введённый пароль пользователем может быть использован для шифрования и расшифрования приватного ключа, в следствие чего сам приватный ключ будет храниться у клиента в защищённом виде. Успешность расшифрования приватного ключа будет свидетельствовать об авторизации, разблокирующей последующую идентификацию пользователя.
На счёт первого случая согласен, недавно только его исправлял (на данный момент локально). Ранее по логике client был учтён для получения публичного ключа, сейчас та часть логики была вырезана из-за ненадобности как таковой.
На счёт
HandleServiceTCP. Логика return nil сводится к тому, что поступили некорректные данные от какого-либо пользователя в сети, и как следствие их не следует обрабатывать и посылать таковому узлу ответ, либо сам принимающий некорректно выставил роуты. Если пользователь валидный, тогда он должен априори придерживаться ровно такого же списка правил и позволенных действий. Несогласованность параметров является технической ошибкой.Анонимность заключается в невозможности определить состояние пользователя - отправляет ли он какую-то информацию, получает её или бездействует. Из этого, как следствие, становится невозможным определение - связывается ли он вообще хоть с кем-то в анализируемой сети. IP адреса здесь представляются лишь как множество всех участников сети, но идентификация и истинная маршрутизация между пользователями осуществляется на криптографическом уровне.
Для общего развития почему бы и нет. Tor и VPN хоть это и классика, но существуют куда более интересные способы анонимизации сетевого траффика. Так например, DC-сети (обедающие криптографы) представляют интересную модель анонимизации. В отличие от Tor или VPN такие сети могут предоставлять теоретически доказуемую анонимность участников. Другая сеть - Crowds интересна своей вероятностной маршрутизацией (хоть и неустойчивой к некоторым атакам). Некоторые сети, не анонимные, подобия Bitmessage имеют интересные способы идентификации участников в сети без необходимости знать и понимать где они находятся и к кому надо подключаться для связи с конкретным абонентом. В общем спектр разнородных технологий и работ был проделан достаточно большой, где можно найти ещё много чего интересного.
Сколько много душнил в хабре появилось, которые по существу так и не способны ничего сказать, кроме как придираться к неоднозначности единственного термина со стороны перевода, не читая при этом саму статью.
Вы уж удосудьтесь сначала прочитать, выделить все недостатки, а потом уже указывать нестыковки и противоречия. То что вы указали - это цирк на потеху публике, которая кстати по соотношению плюсов/минусов действительно любит хавать такую низкосортную критику.