Pull to refresh

Comments 32

Спасибо за обратную связь!

Это бот, судя по всему. Посмотрите на его однотипные комментарии.

Сейчас ему в лс напишу и проверим. Мне теперь интересно, а кто вообще заинтересован в том, что бы крутить этих ботов? Пустой аккаунт это едва ли раскручивает...

Корпоративный блог RUVDS например

Вы ошибаетесь. Статьи наших авторов в комментариях от ботов не нуждаются.

Для корпоративного бота он слишком широкий спектр контента поглощает и комментирует. Я уже написал ему лично и теперь готов заступиться за его репутацию) Просто человек читает хабр (как это делают ещё тысячи других анонов) и оставляет односложные комментарии для поддержки понравившихся статей. Он сказал, что теперь будет писать развёрнутее, что-бы не рисковать кармой

Я проверил, он самый настоящий человечек. Пусть он и публикует однотипные комментарии. Мне он сказал, что если его подозревают в фейковой активности, то он перестанет писать однотипные комментарии...

ну уж извините за то что у меня нет разнообразия, мне не хватает фантазии на комментарии

Тогда не нужно комментировать. На Хабре за такие комменты сливали мгновенно когда-то. Поэтому в комменты было интересно заходить - умные люди писали интересные вещи, а теперь тут вот это.

Давно не читал такого отборного технотекстового дисцилята. Эко вас торкнуло. Мне кажется без серьёзного симпозиума и не разобраться.

Спасибо за приятный комментарий!

Давай сюда уже зачетку...

1. На правах придирок

Вы справедливо заметите: так ведь Diffie Hellman — протокол симметричного шифрования, ключ-то в конце получился одинаковый!

Когда это DH стал протоколом симметричного шифрования?

Отсутствие алгоритма взлома ключа для квантовых вычислителей

Когда это EC криптография стала невзламываема для квантовых вычислений?

2. На правах непродуманной архитектуры

Каждый участник будет хранить у себя все файлы сети одновременно и самостоятельно просматривать их, индексировать, рендерить и т. д.

Сеть Tor есть крайне плохой выбор для такого рода хранилищ, когда пользователь подгружает всю базу данных / файлов себе на локальный компьютер или сервер. Если предположить, что вдруг, магическим образом, заспавнилась запрещёнка, то все начинают её подгружать себе. Ответственность за этот файл лежит теперь не на раздающем, а на хранящем.

Сеть Tor хорошо анонимизирует отправителей, но плохо анонимизирует получателей / сервера, собственно в этой архитектуре - всех P2P узлов. Банальный способ атаки будет сводиться к существованию двух атакующих: активного внутреннего и пассивного внешнего. Цель активного - просто генерация большого количества запросов на один из доменов. Цель пассивного - смотреть за аномально большим траффиком и вырисовывать получателей такого траффика. Если внешний наблюдатель - есть государство, то вся анонимность буквально будет рушиться на глазах, а все причастные с подгруженной запрещёнкой будут в сию минуту в местах не столь отдалённых.

Спасибо за первый развернутый комментарий!

Протокол Ди́ффи — Хе́ллмана (англ. Diffie–Hellman key exchange protocol, DH) — криптографический протокол, ... симметричного шифрования.

Симметри́чные криптосисте́мы (также симметричное шифрованиесимметричные шифры) (англ. symmetric-key algorithm) — способ шифраавфования, в котором для шифрования и расшифрования применяется один и тот же криптографический ключ.

А вот про квантовые компьютеры действительно накосячил. Видимо где-то словил фейк. По отношению необходимой мощности к длине ключа EC все же выигрывает, однако гипотетически, должна ломаться адаптированным алгоритмом Шора, как и RSA. Сейчас ещё немного копну в теме и отредактирую статью, спасибо.

По поводу архитектуры, как по мне, самое интересное. Да, ответственность за запрещёнку лежит на пользователях, однако, является ли это проблемой, если пользователя нельзя деанонимизировать?

Ваш способ атаки на сервер Tor мне тоже не совсем понятен. Имея сеть (Tor) с архитектурой запрос-ответ, мы едва ли можем рассчитывать на теоретический доказуемую анонимность. Атака при помощи перегрузки конкретного клиента и вычисления его по аномально большому трафику звучит хорошо только на бумаге или в криптографической задачке. Если мы хотим реально принять против неё меры при проектировании сети, то достаточно ввести искусственные ограничения на отдачу/прием на стороне клиента. Что-то по типу задачи на базе очередей (https://habr.com/ru/articles/753902/)

В реальности же с ограничением пропускной способности узлов справляется естественная сетевая модель современного клирнета с кучей маршрутизаторов\ретрансляторов. Если бы государство могло так легко взять и таргетированно (в сговоре с интернет-провайдером) отследить по тепловой карте трафика реальный адрес какого-нибуть сайта в Tor, думаете он бы продолжил свое существование?
Возможно я вас не так понял, но мне действительно интересно)

Как понял, определение DH было взято из википедии. Тогда вот полное определение:

Протокол Ди́ффи — Хе́ллмана (англ. Diffie–Hellman key exchange protocol, DH) — криптографический протокол, позволяющий двум и более сторонам получить общий секретный ключ, используя незащищенный от прослушивания канал связи. Полученный ключ используется для шифрования дальнейшего обмена с помощью алгоритмов симметричного шифрования.

Нигде не сказано, что это протокол симметричного шифрования, это протокол распределения ключей. То, что его результаты используют уже в массе своей симметричные алгоритмы шифрования ничего не говорит о какой-либо симметричной сущности самого DH. Полученный секретный ключ может например использоваться в HMAC, что уже не есть симметричное шифрование.

По поводу архитектуры, как по мне, самое интересное. Да, ответственность за запрещёнку лежит на пользователях, однако, является ли это проблемой, если пользователя нельзя деанонимизировать?

Если нельзя - проблемы нет. Если льзя - проблема есть. В сети Tor, и в таком использовании, деанонимизировать можно.

В реальности же с ограничением пропускной способности узлов справляется естественная сетевая модель современного клирнета с кучей маршрутизаторов\ретрансляторов.

Вряд ли это так. Наблюдателю известны все маршруты в пределах собственных границ, известен и нормализованный уровень трафика, известен и аномальный уровень трафика. Наложение одного на другое уже может дать чёткие маршруты, даже без учёта анализа сети Tor по его специфичному виду протокола.

Если бы государство могло так легко взять и таргетированно (в сговоре с интернет-провайдером) отследить по тепловой карте трафика реальный адрес какого-нибуть сайта в Tor, думаете он бы продолжил свое существование?

Да, потому что Tor использует следующую модель угроз:

  1. Анонимность сосредоточена на клиентской стороне больше, чем на серверной. Определить связь клиента с сервером сложнее, когда неподконтрольны клиент и сервер, нежели когда неподконтролен только сервер. Вероятность же инвертированной ситуации, когда сервер окажется подконтрольным, а клиент - нет, куда меньше, как минимум за счёт того, что сервер есть хранитель информации, профита с его деанонимизации можно получить куда больше,

  2. В основе Tor заложен принцип федеративности, когда маршрутизирующие узлы располагаются на границах разных государств, а сам пакет множественно шифруется и внешне самоизменяется при переходе от одного узла к другому. Когда же происходит слежение за аномально большим трафиком на конечных точках, то от такой маршрутизации смысла становится ровно нуль, если сервер находится в пределах видимости внешнего наблюдателя, даже если сам пакет изменял свою форму в неподконтрольных государствах,

  3. За счёт P2P архитектуры ситуация из второго пункта ухудшает ситуацию ещё больше. Существующие даркнет сайты, тобишь сервера в сети Tor продолжают существовать и функционировать лишь по той простой причине, что отправитель (клиент) и получатель (сервер) находятся в разных государствах. Сам сайт же деплоится в нескольких государствах. Вследствие этого: 1) массовые запросы начинают расщепляться по нескольким репликам, 2) выход из строя одного сервера не приводит к падению сайта. Когда отправитель и получатель находятся в пределах одного государства, тогда анонимизация в сети Tor начинает работать крайне плохо, даже с учётом всей запутывающей маршрутизации. У P2P сети, состоящей из рядовых пользователей, такой возможности как реплицировать себя на множество государств нет. А даже если будет, то всплывёт ещё масса других вопросов, как минимум на счёт консистентности хранимых данных и последующей анонимизации в новых условиях.

Идея хорошая и интересная. НО это "прототип"...Который поднимает интересные вопросы. Например для распределенного хранения использовать ситуацию, когда ни на одном компьютере не хранится целый файл пригодный к расшифровке.

Точно, возможность-то прикрутить сюда схему Шамира я и забыл упомянуть! Это действительно хорошее дополнение

Спасибо за первый развернутый комментарий!


Протокол Ди́ффи — Хе́ллмана
 (англ. Diffie–Hellman key exchange protocol, DH) — криптографический протокол, ... симметричного шифрования.

Симметри́чные криптосисте́мы (также симметричное шифрованиесимметричные шифры) (англ. symmetric-key algorithm) — способ шифраавфования, в котором для шифрования и расшифрования применяется один и тот же криптографический ключ.

А вот про квантовые компьютеры действительно накосячил. Видимо где-то словил фейк. По отношению необходимой мощности к длине ключа EC все же выигрывает, однако гипотетически, должна ломаться адаптированным алгоритмом Шора, как и RSA. Сейчас ещё немного копну в теме и отредактирую статью, спасибо.

По поводу архитектуры, как по мне, самое интересное. Да, ответственность за запрещёнку лежит на пользователях, однако, является ли это проблемой, если пользователя нельзя деанонимизировать?

Ваш способ атаки на сервер Tor мне тоже не совсем понятен. Имея сеть (Tor) с архитектурой запрос-ответ, мы едва ли можем рассчитывать на теоретический доказуемую анонимность. Атака при помощи перегрузки конкретного клиента и вычисления его по аномально большому трафику звучит хорошо только на бумаге или в криптографической задачке. Если мы хотим реально принять против неё меры при проектировании сети, то достаточно ввести искусственные ограничения на отдачу/прием на стороне клиента. Что-то по типу задачи на базе очередей (https://habr.com/ru/articles/753902/)

В реальности же с ограничением пропускной способности узлов справляется естественная сетевая модель современного клирнета с кучей маршрутизаторов\ретрансляторов. Если бы государство могло так легко взять и таргетированно (в сговоре с интернет-провайдером) отследить по тепловой карте трафика реальный адрес какого-нибуть сайта в Tor, думаете он бы продолжил свое существование?
Возможно я вас не так понял, но мне действительно интересно)

Написать ник @a1batross так как написали вы, это очень мощно

Так причина того, что они переключились на мой репозиторий, потому что они не знают что версия в Google Play является устаревшей.

Актуальная версия Termux в F-Droid, так как Google задолбал ставить палки в колёса при обновлении Termux. Я в той дискуссии участвовал, создал бэкап репозитория, который в итоге стал зеркалом. Примерно тогда же они переименовали репозитории, а я сделал симлинки ради себя потому что было лень править /etc/apt/sources.list.

И вот как бы теперь у меня дилемма. Я могу снести эти симлинки, потому что в общем-то костыль, предложенный в статье, не должен работать и может случайно отломаться создав кучу нытья разработчикам Termux. Я могу не сносить симлинки, потому что кто-то на них полагается (полагаю что авторы статьи не единственные).

Поинтересовался у разработчиков, нужно ли это. Удалил симлинки, так что просьба статью отредактировать приложив ссылку на актуальную версию Termux в F-Droid.

Спасибо за материал, читать занятно.

Но чем дальше читал, тем больше ощущение, что переизобретался ipfs.

Чем от IPFS принципиально отличается? там тоже файловая система, домены и p2p...

На самом деле есть base64url, который можно использовать в урлах. А я использую base64ae, который воспринимается всеми инструментами как одно слово, что довольно удобно.

Не очень понял, как у вас получился публичный ключ в 32 байта. Я вот генерирую на JS приватный P-256 ключ, он состоит из 3 чисел: x, y, d. Каждое число - 32 байта. Публичный ключ - это числа x и y. Итого 64 байта - публичная часть и 32 - приватная.

Ну и гляньте эти проекты, наверняка будет интересно:

  • crus.hyoo.ru - децентрализованная база с синхронизацией в реальном времени, где все изменения подписываются приватным ключом автора. Принцип работы похож на ваш - каждый узел хранит то, что ему интересно и раздаёт при заинтересованности от других узлов.

  • page.hyoo.ru - построенная на прототипе этой базы вики система. В принципе, если завернуть её в тор, то получится что-то типа того, что вы делаете, только с рилтаймом и прямо в браузере. WebSocket/WebRTC ведь не сложно завернуть в тор?

  • Скоро ещё будет ещё своя система контроля версий, которая зеркалирует файлы в базу, что позволит легко шарить файлы через ту же инфраструктуру, при этом пересылая только дельты их изменений.

!mkdir keys
!chmod 700 keys

Это - vulnerability, потому что есть промежуток времени пока chmod не применен. Использовать umask

А как атакующему воспользоваться этой уязвимостью? Промежуток времени такой есть, но всё это время каталог пуст.

Если интересно, стоит поискать этот тип уязвимостей, там много всячины будет. Тут навскидку: создать файл с тем же именем и получить его дескриптор. Вот получится ли пройтись по папке, в самом деле не знаю:

  1. Папка создалась

  2. Берем дескриптор

  3. Пользователь запрещает нам +x на папку (листинг)

  4. Можно ли теперь благодаря дескриптору получить листинг или уже нет?

Беглый эксперимент в питоне говорит, что получится:

import os
# Делаем mkdir keys от имени другого пользователя
dir_fd = os.open("keys", os.O_RDONLY)
# Делаем chmod 700 keys
dir_fd2 = os.open("keys", os.O_RDONLY)
# PermissionError - второй раз открыть уже не даёт
os.listdir(dir_fd)
# ['secret.txt'] - но старый dir_fd продолжает работать
os.open("secret.txt", os.O_RDONLY, dir_fd=dir_fd)
# PermissionError - прочитать или записать файл уже не даёт

Ого, очень информативно, спасибо)

Это лучше чем организовано во Freenet'е или нет, в плане расшаривания файлов и анонимности, или это не сопоставимо?

Sign up to leave a comment.