Таким образом, майнинг - инструмент добычи некой субстанции, которая не существует в реальной природе, однако стоит реальных денег. Всё дело в вычислительных мощностях. Криптовалюта - цена за вычисление (точнее за железо).
Потраченные вычислительные мощности лишь в очень малой доле придают криптовалюте свою стоимость P, выражаясь суммарной стоимостью потреблённых ресурсов S делёных на количество выпущенных монет k: P=S/k. Собственно в теории именно такой стоимостью должны были бы обладать криптовалюты на базе концепта майнинга (PoW), без учёта изменения сложности майнинга самой системой. Следовательно, итоговая сумма всех выпущенных монет = V(P), выраженная всеми израсходованными ресурсами = V(S) становится эквивалентна стоимости самих этих ресурсов. А связано всё с тем, что в таком концепте не существует синтеза нескольких продуктов воедино, нет никакого человеческого труда во всём этом процессе производства криптовалюты. Поэтому сама стоимость P становится лишь стоимостью приобретённого железа S, и как следствие, криптовалюты в такой парадигме были бы ни чем иными как обменом железа X на деньги M через промежуточную стадию криптовалюты K, то-есть X->K->M.
Но тем не менее, на практике всё куда сложнее. Большая часть стоимости криптовалюты P' (вне P) обретает свою значимость лишь базируясь на уже имеющихся валютах, которые в свою очередь привязаны к вполне материальным трудозатратам - добыче золота, серебра, нефти, алмазов и т.д. Следовательно, рост стоимости криптовалюты начинает быть пропорционален количеству вливаемого капитала в эти самые криптовалюты. Из этого, само P становится лишь константой и довольно малой, в то время как P' начинает играть решающую линейную роль.
При этом также стоит сказать, что в некоторых криптовалютах P и вовсе может не существовать, а точнее может существовать лишь в пренебрежимо малой величине. К таким криптовалютам следует относить все механизмы консенсуса, которые не связаны с массовым потреблением материальных ресурсов. Величина P становится лишь выражением потребления в поддержании работоспособности системы, без операций увеличивающих само потребление.
Такую связь P' в сравнении с P, уже неоднократно можно наблюдать на примере того же злосчастного Dogecoin, стоимость которого возрастает от количества вливаемого капитала, и падает от количества выведенного капитала. Такую же связь можно наблюдать на примере Bitcoin'a, когда таковой начинает падать в цене - начинают падать в цене и все остальные криптовалюты. Словно Bitcoin становится чёрной дырой на рынке криптовалют, потому что уменьшение стоимости Bitcoin'a приводит равносильно к попыткам вывода капитала из других криптовалют, и как следствие, к уменьшению их стоимости.
Четвёртый пункт миф до поры до времени, пока компания не станет монополией, о чём собственно в самой статье и говорится. Нет конкурентов - нет проблем с репутацией.
Так что прежде, чем списывать со счетов репутационные риски, подумайте, сколько клиентов удалят ваше мобильное приложение или уйдут к конкурентам после того, как произойдет подобный инцидент и выйдет статья с подробным описанием уязвимости.
Собственно это легко наблюдается и в современном мире на примере провалов сбера и яндекса в сливах персональных данных пользователей. Сливы произошли, репутация понизилась, но приложения продолжают работать, клиенты продолжают пользоваться приложениями. Как раз это и говорит о том, что репутация ничего не стоит, с учётом успешно выстроенной монополии. А такие монополии в современном мире не редкость.
Это зависит от того, на что именно должен идти упор изучения. Так например, если хотите изучать классическую криптографию, то думаю подойдёт "Книга шифров" от Сингха. В ней достаточно интересно и подробно расписана история криптографии, основные её события, в совокупности с изобретаемыми алгоритмами. Если нужно изучать современную криптографию, то тут для наиболее лёгкого погружения могу посоветовать мангу по криптографии от Масааки, Синтъити, Идэро. Хоть и материал подаётся в забавной форме, тем не менее, он достаточно подробно расписывает основы современной криптографии.
Протокол Диффи-Хеллмана не так идеален, как описан в статье, и может содержать массу условностей при безопасном применении. Как минимум на нём работает старая добрая MITM атака. Как максимум необходимо использовать надёжные простые числа. В статье это к сожалению никак не затрагивалось, хотя тема очень важная, потому что без подобного рода простых чисел протокол Диффи-Хеллмана может просто скатиться к маркетинговой рекламе. Для новичков такой материал хоть и будет понятнее, чем с подробностями, но такие облегчения просто приведут к неправильной картине восприятия самого протокола. На счёт подобного рода подводных камней протокола Диффи-Хеллмана очень хорошо написано в книге "Практическая криптография" (Шнайер, Фергюсон).
Криптография и стеганография - это разные науки, хоть и обе защищают информацию. Одна (криптография) защищает информацию посредством шифрования, когда существует факт сообщения, но смысл неясен. Другая (стеганография) защищает информацию посредством самого факта её сокрытия. Обе науки развивались иногда параллельно, иногда в синтезе. Но их даже теоретически нельзя связать, кроме того, что они защищают информацию. Плюс к этому криптография, вырадившись из своей классической оболочки, стала также способной не только предоставлять конфиденциальность информации, но также её целостность и аутентификацию. Стеганография в этом плане отстаёт, как в способах применения, так и на практике.
Изначально мы имеем ключ K=KEY и сообщение M=HELLOWORLD. Первое, что мы делаем - это выписываем ключ и слева-направо вписываем само сообщение. Пустые ячейки заполняем нейтральными или случайными символами. В моём случае - это нейтральные символы X. Получаем на выходе следующую таблицу.
Далее, начинается второй этап - сортировку ключа и столбцов соответственно. Если сортировать ключ по порядку символов алфавита, то мы получим последовательность EKY. Теперь создаём новую таблицу с ключом K=EKY, но отсортировав сам ключ мы также должны и отсортировать столбцы под ключом ровно в таком же порядке. Получаем уже такую таблицу.
И последний, третий этап - это считывание полученных символов в определённом порядке. В моём случае я выбрал снизу-вверх, справа-налево. Примерно как это показано на таблице ниже.
Таким образом, я получаю шифртекст C=XLWLDOLHXROE.
Не знаю, может ли это помочь хоть как-то, но схожие задачи в своё время я пытался решать. Одной из таковых стало переписывание ядра 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) Я лишь привёл Трушину как пример того, что вы скидываете литературу, которую вскользь прочитывали, потому что в этой диссертации чёрно по белому написано суждение того, что "Анонимность отправителя/получателя влечет за собой анонимность сеанса связи", с чем автор и соглашается.
Собственно это то, что вы пытались опровергать из доказательства в моей работе.
Одно не включает другого, тем более априори. Это разные вещи. Одно может быть, а другого может не быть.
Одно включает в себя другое = "Компрометация анонимности сеанса связи автоматически приводит к компрометации анонимности отправителя/получателя. В тоже время компрометация анонимности отправителя/получателя не приводит к компрометации анонимности сеанса связи". Это я также из работы Оксаны Вячеславовны.
"Одно может быть, а другого может не быть" - верно, но исключительно для несвязываемости. Таковая может существовать без ненаблюдаемости, а наоборот - нет. Тем не менее, вы пытались создать именно "конструктивное опровержение утверждения о том, что неотслеживаемость включает в себя анонимность". Это вовсе не об "Одно может быть, а другого может не быть".
И не надо валить всё в одну кучу. Об этом ясно написано в заметке и следует из приведенной цитаты.
Выше описал. Похоже больше на соломенное чучело. Говорите об одном, а в комментарии уже пишете о другом.
И не надо всуе рассуждать про исследование — в работе Трушиной такое исследование есть и конкретный результат есть.
Вообще не спорю. Я не научный работник и близко, тем не менее тему я изучаю, а также интересуюсь работами косвенно или прямо связанными с анонимностью. Но так или иначе, это уже даёт плоды, где я могу видеть непонимание или попытку ошибочного понимания определений связанных с анонимностью.
Противоречий каких-либо связанных с моей работой вы не привели ни одно, хотя и был хороший настрой:
Однако, если речь идёт о теории в классической трактовке, то необходимо обеспечить полноту и непротиворечивость положений, составляющих смысловое содержании последней. К сожалению, здесь имеются некоторые упущения, которые мы постараемся продемонстрировать при помощи простого контрпримера.
Если бы такие противоречия даже нашлись, я бы вам поблагодарил и исправил таковые. Но вы либо их умышленно скрыли (как истинный злодей), чтобы моя работа была хуже по содержанию, либо просто не нашли, либо что более вероятностно - даже мою статью не читали и вовсе, а просто привели ради красного словца, ради критики.
Это ведь диссертация, которая защищалась на совете. А перед этим были публикации в рецензируемых изданиях. У вас этого нет, но есть претензия на «теорию». Это вызывает тревогу.
Не обязательно быть учёным, чтобы что-то новое изобретать или придумывать, или исследовать. Из "неучённости", становится лишь более низкой вероятность действительно правильного исследования. Именно поэтому свою работу я делаю наиболее открытой и всем её рекомендую прочитать. Это одна из единственных вещей, которая может оставаться объективной и независимой от автора исследования. Если тревога вызвана этим - так прочитайте статью, найдите противоречия и укажите их. А так, сама ваша критика получилась откровенно сказать поверхностной до первых ссылок в гугле про таковые термины как "несвязываемость" и "ненаблюдаемость".
Уже есть таковые аудиты и довольно регулярно их применяют. Когда компания привлекает множество смарт-контрактников также начинает привлекать и сервисы аудита написанных ими кодов.
Потраченные вычислительные мощности лишь в очень малой доле придают криптовалюте свою стоимость P, выражаясь суммарной стоимостью потреблённых ресурсов S делёных на количество выпущенных монет k: P=S/k. Собственно в теории именно такой стоимостью должны были бы обладать криптовалюты на базе концепта майнинга (PoW), без учёта изменения сложности майнинга самой системой. Следовательно, итоговая сумма всех выпущенных монет = V(P), выраженная всеми израсходованными ресурсами = V(S) становится эквивалентна стоимости самих этих ресурсов. А связано всё с тем, что в таком концепте не существует синтеза нескольких продуктов воедино, нет никакого человеческого труда во всём этом процессе производства криптовалюты. Поэтому сама стоимость P становится лишь стоимостью приобретённого железа S, и как следствие, криптовалюты в такой парадигме были бы ни чем иными как обменом железа X на деньги M через промежуточную стадию криптовалюты K, то-есть X->K->M.
Но тем не менее, на практике всё куда сложнее. Большая часть стоимости криптовалюты P' (вне P) обретает свою значимость лишь базируясь на уже имеющихся валютах, которые в свою очередь привязаны к вполне материальным трудозатратам - добыче золота, серебра, нефти, алмазов и т.д. Следовательно, рост стоимости криптовалюты начинает быть пропорционален количеству вливаемого капитала в эти самые криптовалюты. Из этого, само P становится лишь константой и довольно малой, в то время как P' начинает играть решающую линейную роль.
При этом также стоит сказать, что в некоторых криптовалютах P и вовсе может не существовать, а точнее может существовать лишь в пренебрежимо малой величине. К таким криптовалютам следует относить все механизмы консенсуса, которые не связаны с массовым потреблением материальных ресурсов. Величина P становится лишь выражением потребления в поддержании работоспособности системы, без операций увеличивающих само потребление.
Такую связь P' в сравнении с P, уже неоднократно можно наблюдать на примере того же злосчастного Dogecoin, стоимость которого возрастает от количества вливаемого капитала, и падает от количества выведенного капитала. Такую же связь можно наблюдать на примере Bitcoin'a, когда таковой начинает падать в цене - начинают падать в цене и все остальные криптовалюты. Словно Bitcoin становится чёрной дырой на рынке криптовалют, потому что уменьшение стоимости Bitcoin'a приводит равносильно к попыткам вывода капитала из других криптовалют, и как следствие, к уменьшению их стоимости.
Четвёртый пункт миф до поры до времени, пока компания не станет монополией, о чём собственно в самой статье и говорится. Нет конкурентов - нет проблем с репутацией.
Собственно это легко наблюдается и в современном мире на примере провалов сбера и яндекса в сливах персональных данных пользователей. Сливы произошли, репутация понизилась, но приложения продолжают работать, клиенты продолжают пользоваться приложениями. Как раз это и говорит о том, что репутация ничего не стоит, с учётом успешно выстроенной монополии. А такие монополии в современном мире не редкость.
Это зависит от того, на что именно должен идти упор изучения. Так например, если хотите изучать классическую криптографию, то думаю подойдёт "Книга шифров" от Сингха. В ней достаточно интересно и подробно расписана история криптографии, основные её события, в совокупности с изобретаемыми алгоритмами. Если нужно изучать современную криптографию, то тут для наиболее лёгкого погружения могу посоветовать мангу по криптографии от Масааки, Синтъити, Идэро. Хоть и материал подаётся в забавной форме, тем не менее, он достаточно подробно расписывает основы современной криптографии.
Протокол Диффи-Хеллмана не так идеален, как описан в статье, и может содержать массу условностей при безопасном применении. Как минимум на нём работает старая добрая MITM атака. Как максимум необходимо использовать надёжные простые числа. В статье это к сожалению никак не затрагивалось, хотя тема очень важная, потому что без подобного рода простых чисел протокол Диффи-Хеллмана может просто скатиться к маркетинговой рекламе.
Для новичков такой материал хоть и будет понятнее, чем с подробностями, но такие облегчения просто приведут к неправильной картине восприятия самого протокола. На счёт подобного рода подводных камней протокола Диффи-Хеллмана очень хорошо написано в книге "Практическая криптография" (Шнайер, Фергюсон).
*Стеганографию
Криптография и стеганография - это разные науки, хоть и обе защищают информацию. Одна (криптография) защищает информацию посредством шифрования, когда существует факт сообщения, но смысл неясен. Другая (стеганография) защищает информацию посредством самого факта её сокрытия. Обе науки развивались иногда параллельно, иногда в синтезе. Но их даже теоретически нельзя связать, кроме того, что они защищают информацию. Плюс к этому криптография, вырадившись из своей классической оболочки, стала также способной не только предоставлять конфиденциальность информации, но также её целостность и аутентификацию. Стеганография в этом плане отстаёт, как в способах применения, так и на практике.
Изначально мы имеем ключ K=KEY и сообщение M=HELLOWORLD. Первое, что мы делаем - это выписываем ключ и слева-направо вписываем само сообщение. Пустые ячейки заполняем нейтральными или случайными символами. В моём случае - это нейтральные символы X. Получаем на выходе следующую таблицу.
Далее, начинается второй этап - сортировку ключа и столбцов соответственно. Если сортировать ключ по порядку символов алфавита, то мы получим последовательность EKY. Теперь создаём новую таблицу с ключом K=EKY, но отсортировав сам ключ мы также должны и отсортировать столбцы под ключом ровно в таком же порядке. Получаем уже такую таблицу.
И последний, третий этап - это считывание полученных символов в определённом порядке. В моём случае я выбрал снизу-вверх, справа-налево. Примерно как это показано на таблице ниже.
Таким образом, я получаю шифртекст C=XLWLDOLHXROE.
Не знаю, может ли это помочь хоть как-то, но схожие задачи в своё время я пытался решать. Одной из таковых стало переписывание ядра 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: