Privacyprotect.org что это ?
что это реальная защита для владельцев доменов или хитрый способ воровства доменов у "анонимных" пользователей? на сайте не сказано на кого реально регистрируются домены и как это юридически...
|
||||||||||||||||||||||||||
|
||||||||||||||||||||||||||
Нормы пользования. Некоторые права на материалы сайта защищены по условиям лицензии CreativeCommons. Движок
openSpace 0.8.25a и дизайн сайта © 2006-2007 Vlad "SATtva" Miller.
|
||||||||||||||||||||||||||
Отдельно пишут, что все абузы по телефону и почтовому адресу будут отклоняться перенаправлением на форму на сайте, т.е. эта форма — единственный вид связи с реальным владельцем домена. Дальше, наверное, забыли написать, что не реагируют на абузы, но от разрегистрации домена регистратором это всё равно не спасёт. Регистраторы доменов, кстати, тоже не всесильны: если домен решили украть ЮСА, они просто пропишут его сразу на корневых DNS-серверах, и всё на том. Протокол DNS устроен так, что корневые DNS могут распоряжаться абсолютно любыми DNS-именами, в том числе нижележащего уровня: вместо запроса на DNS-сервер нижнего уровня могут вернуть DNS-клиенту ответ «не существует», и всё на том.
Создаётся домен .bit.
Домены .onion и .i2p уже давно есть, дело осталось за малым: научить всех юзеров ими пользоваться, чтобы они стали общепринятыми. Более того, в отличие от .bit домены .onion и .i2p совершенно бесплатны и случайны, что делает киберсквоттинг бессмысленным.
комментариев: 9796 документов: 488 редакций: 5664
И являются одновременно отпечатками аутентифицирующих самосгенерированных сертификатов в соответствующих сетях.
Ну если бы все ресурсы висели на индивидуальных айпишниках, как м.б. в случае IPv6, а обращение к ним шло бы только по IP-адресу, а не имени, то "сквоттинг" тоже бы не имел смысла. Разве что из-за красиво запоминающегося номера.
В случае криптоотпечатков: подобрать полный отпечаток нельзя (это равноценно взлому криптопротокола), проблема запоминаемости имени просто игнорируется. "Сквотить" совсем нечего.
Этот вопрос ранее обсуждался, но непонятность не разрешилась. В адресе используются первые сколько-то символов отпечатка, во-первых. Во-вторых, сбрутить их проще, чем весь отпечаток. Есть тулза для генерации отпечатков методом подбора, с её помощью можно добиться, чтобы первые 5-6 символов давали нужное слово. Если генерить некриптостойкие ключи, т.е. ориентироваться только на совпадение отпечатков, то, предположительно, скорость генерации ключей может быть ещё сильней повышена. И как поведёт себя Tor, когда появятся 2 разных onion-сайта, но с одинаковым адресом, не понятно. Может ли это использоваться в качестве атаки на целевой сайт?
Вот насколько сложно сгенерить PGP-ключ, чтобы совпал 16-ричный key id? Алфавит из 16 символов, слово длиной 16 букв, число вариантов — 1616, среднее время на подбор будет в 2 раза меньше, т.е. 1616/2 ≈ 9.2⋅1018 ≈ 263 — много это или мало? Ответ очевиден, сбрутать могут даже любители. Можно что-то аналогичное посчитать и для адресов в onion.
Кстати, были инициативы сделать внутриторовский домен .tor, чтобы на него можно было вешать любые адреса, которые потом будут разрешаться в соответствующий onion-адрес. Заглохли ли эти инициативы — не знаю.
комментариев: 11558 документов: 1036 редакций: 4118
Только ключ будет неработоспособный, и полный отпечаток не будет совпадать. Смысл?
[/offtopic]
комментариев: 9796 документов: 488 редакций: 5664
Проблема обсуждалась в рассылке GnuPG. Смысл в том, что при текущем стандарте это позволит прицельно задосить (заблокировать) скачивание чье-го либо ключа с серверов открытых ключей, которые будут возвращать ошибку при поиске. Вроде предполагается ввести в серверах поддержку поиска по полному отпечатку.
Теоретически, такая же уязвимость может докатиться и до системы согласования соединений со скрытыми Tor-сервисами, если в той сети не предусмотрена возможность разрулить конфликт при раздаче цепочек по совпадающем onion-именам. В I2P и Freedom, кажется есть возможность использовать как короткие, так и длинные отпечатки.
комментариев: 11558 документов: 1036 редакций: 4118
комментариев: 1060 документов: 16 редакций: 32
[offtopic]
Подозреваю, что в том числе и троллинга ради.
[/offtopic]
Так уже в относительно новых SKS это есть. Можно искать по полным 160-битным, коротким 32-битным и по "средним" 64-битным.
Почему неработоспособный? Если генерировать ключи стандартным образом, то всё ОК будет.
Почему ошибку? Ключи-то есть с заданным отпечатком. Наверняка будут выдавать тот ключ, который быстрее найдётся.
Да, а что, по-моему, зарегать акк на pgpru с 16-ричным keyid'ом, совпадающим с SATtva'овским — это очень угарно. Я б сделал, но лень, стар я уже. ;)
комментариев: 11558 документов: 1036 редакций: 4118
Тогда на поиск коллизии уйдёт, скажем мягко, немного больше времени, что ставит под вопрос любительский характер атаки.
Линейно больше, что не принципиально. Число итераций как было 263, так и им и останется, просто время на итерацию несколько возрастёт. Думаю, современные кластеры такое быстро сделают, а доступ к кластерам есть у всех, кому не лень.
комментариев: 11558 документов: 1036 редакций: 4118
Число итераций само по себе мало о чём не говорит (если оно изначально не выходит за разумные пределы). Предположим, вы хэшируете короткий пароль со сложностью 225 по PBKDF2 с таким числом итераций, что проверка занимает минуту. Даже в этом случае на брутфорс уйдёт лет 50.
А как движок на pgpru.com переварит существование двух ключей с одинаковыми key id'ами? Будут ли проблемы с одинаковыми 8-мизначачными? А с одинаковыми 16-значными? Надо бы подумать об этом, пока доступ к кластеру есть.
Не правильно. На характеристиках типов функций f(n) строится вся complexity theory. Не зря там полиномальное время отличают от экспоненциального. Если угодно, на обывательском уровне можно сказать так: решить полиномиальную задачу можно экстенсивными затратами, экспоненциальную — только интенсивными (кардинально менять модель вычислений или сам алгоритм).
Допустим, это так для ПК. А теперь представьте, что у вас в распоряжении находится кластер, 1024 процессора, каждый из которых — четырёхядерник. Вычисление коллизии легко параллелится, поэтому делите время на 4096: 50⋅365/4096 ≈ 4.5 дня. Может, вас побрутать немного?
Скорее, пожалуй, да, чем нет. Выглядит примерно так: регаем акк, грузим ключ, удаляем ключ. При удалении движок ссылается на keyid и поэтому сносит как коллизионный ключ, так и SATtva'овский. SATtva потом смотрит, видит, что ключ на pgpru пропал, думает, что взломали. А, может, даже и ещё веселее...