id: Гость   вход   регистрация
текущее время 09:36 29/03/2024
создать
просмотр
ссылки

Privacyprotect.org что это ?


что это реальная защита для владельцев доменов или хитрый способ воровства доменов у "анонимных" пользователей? на сайте не сказано на кого реально регистрируются домены и как это юридически...


 
На страницу: 1, 2 След.
Комментарии
— Гость (27/01/2013 03:01)   <#>
Разве по ссылкам внизу [эта и эта] плохо объяснено? Регистрируют на себя, причём, видать, это происходит совершенно автоматически. Воруют или нет — не знаю, но цель сервиса — не защита от разрегистрации доменов (они сами пишут, что не владеют доменными именами), а защита личных данных, указанных при регистрации домена. По сути они выполняют роль посредника между регистратором доменов и владельцами сайтов, проксируя личные данные whois (заменяя их своими). Похоже на юридическое прокси типа оффшора: перед регистратором доменов владельцем будут выступать они, а реальный владелец будете типа вы.

Отдельно пишут, что все абузы по телефону и почтовому адресу будут отклоняться перенаправлением на форму на сайте, т.е. эта форма — единственный вид связи с реальным владельцем домена. Дальше, наверное, забыли написать, что не реагируют на абузы, но от разрегистрации домена регистратором это всё равно не спасёт. Регистраторы доменов, кстати, тоже не всесильны: если домен решили украть ЮСА, они просто пропишут его сразу на корневых DNS-серверах, и всё на том. Протокол DNS устроен так, что корневые DNS могут распоряжаться абсолютно любыми DNS-именами, в том числе нижележащего уровня: вместо запроса на DNS-сервер нижнего уровня могут вернуть DNS-клиенту ответ «не существует», и всё на том.
— Гость (27/01/2013 03:30)   <#>
если домен решили украть ЮСА, они просто пропишут его сразу на корневых DNS-серверах, и всё на том.

Создаётся домен .bit.
— Гость (27/01/2013 04:56)   <#>
Создаётся домен .bit.

Домены .onion и .i2p уже давно есть, дело осталось за малым: научить всех юзеров ими пользоваться, чтобы они стали общепринятыми. Более того, в отличие от .bit домены .onion и .i2p совершенно бесплатны и случайны, что делает киберсквоттинг бессмысленным.
— unknown (27/01/2013 19:13, исправлен 27/01/2013 19:19)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664

И являются одновременно отпечатками аутентифицирующих самосгенерированных сертификатов в соответствующих сетях.



Ну если бы все ресурсы висели на индивидуальных айпишниках, как м.б. в случае IPv6, а обращение к ним шло бы только по IP-адресу, а не имени, то "сквоттинг" тоже бы не имел смысла. Разве что из-за красиво запоминающегося номера.


В случае криптоотпечатков: подобрать полный отпечаток нельзя (это равноценно взлому криптопротокола), проблема запоминаемости имени просто игнорируется. "Сквотить" совсем нечего.

— Гость (28/01/2013 00:58)   <#>
подобрать полный отпечаток нельзя

Этот вопрос ранее обсуждался, но непонятность не разрешилась. В адресе используются первые сколько-то символов отпечатка, во-первых. Во-вторых, сбрутить их проще, чем весь отпечаток. Есть тулза для генерации отпечатков методом подбора, с её помощью можно добиться, чтобы первые 5-6 символов давали нужное слово. Если генерить некриптостойкие ключи, т.е. ориентироваться только на совпадение отпечатков, то, предположительно, скорость генерации ключей может быть ещё сильней повышена. И как поведёт себя Tor, когда появятся 2 разных onion-сайта, но с одинаковым адресом, не понятно. Может ли это использоваться в качестве атаки на целевой сайт?

Вот насколько сложно сгенерить PGP-ключ, чтобы совпал 16-ричный key id? Алфавит из 16 символов, слово длиной 16 букв, число вариантов — 1616, среднее время на подбор будет в 2 раза меньше, т.е. 1616/2 ≈ 9.2⋅1018 ≈ 263 — много это или мало? Ответ очевиден, сбрутать могут даже любители. Можно что-то аналогичное посчитать и для адресов в onion.

Кстати, были инициативы сделать внутриторовский домен .tor, чтобы на него можно было вешать любые адреса, которые потом будут разрешаться в соответствующий onion-адрес. Заглохли ли эти инициативы — не знаю.
— SATtva (28/01/2013 08:51)   профиль/связь   <#>
комментариев: 11558   документов: 1036   редакций: 4118
[offtopic]
Вот насколько сложно сгенерить PGP-ключ, чтобы совпал 16-ричный key id? ... Ответ очевиден, сбрутать могут даже любители.

Только ключ будет неработоспособный, и полный отпечаток не будет совпадать. Смысл?
[/offtopic]
— unknown (28/01/2013 09:41, исправлен 28/01/2013 09:45)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664

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


Теоретически, такая же уязвимость может докатиться и до системы согласования соединений со скрытыми Tor-сервисами, если в той сети не предусмотрена возможность разрулить конфликт при раздаче цепочек по совпадающем onion-именам. В I2P и Freedom, кажется есть возможность использовать как короткие, так и длинные отпечатки.

— SATtva (28/01/2013 09:54)   профиль/связь   <#>
комментариев: 11558   документов: 1036   редакций: 4118
Насколько помню, это обсуждалось год или полтора назад. SKS с тех пор разве не пропатчили? Это легко проверить, если у кого-то под рукой есть список дубликатных 64-битовых keyID. Попытался сейчас погуглить, но наглилось только то, что сайт J. Harris'а со списком дубликатов прекратил существование.
— sentaus (28/01/2013 10:00, исправлен 28/01/2013 10:01)   профиль/связь   <#>
комментариев: 1060   документов: 16   редакций: 32

[offtopic]

и полный отпечаток не будет совпадать. Смысл?

Подозреваю, что в том числе и троллинга ради.
[/offtopic]


Вроде предполагается ввести в серверах поддержку поиска по полному отпечатку.

Так уже в относительно новых SKS это есть. Можно искать по полным 160-битным, коротким 32-битным и по "средним" 64-битным.

— Гость (28/01/2013 10:59)   <#>
Только ключ будет неработоспособный, и полный отпечаток не будет совпадать. Смысл?

Почему неработоспособный? Если генерировать ключи стандартным образом, то всё ОК будет.

будут возвращать ошибку при поиске.

Почему ошибку? Ключи-то есть с заданным отпечатком. Наверняка будут выдавать тот ключ, который быстрее найдётся.

Подозреваю, что в том числе и троллинга ради.

Да, а что, по-моему, зарегать акк на pgpru с 16-ричным keyid'ом, совпадающим с SATtva'овским — это очень угарно. Я б сделал, но лень, стар я уже. ;)
— SATtva (28/01/2013 11:18)   профиль/связь   <#>
комментариев: 11558   документов: 1036   редакций: 4118
Почему неработоспособный? Если генерировать ключи стандартным образом, то всё ОК будет.

Тогда на поиск коллизии уйдёт, скажем мягко, немного больше времени, что ставит под вопрос любительский характер атаки.
— Гость (28/01/2013 19:25)   <#>
Тогда на поиск коллизии уйдёт, скажем мягко, немного больше времени, что ставит под вопрос любительский характер атаки.

Линейно больше, что не принципиально. Число итераций как было 263, так и им и останется, просто время на итерацию несколько возрастёт. Думаю, современные кластеры такое быстро сделают, а доступ к кластерам есть у всех, кому не лень.
— SATtva (29/01/2013 13:22)   профиль/связь   <#>
комментариев: 11558   документов: 1036   редакций: 4118
Число итераций как было 263, так и им и останется, просто время на итерацию несколько возрастёт.

Число итераций само по себе мало о чём не говорит (если оно изначально не выходит за разумные пределы). Предположим, вы хэшируете короткий пароль со сложностью 225 по PBKDF2 с таким числом итераций, что проверка занимает минуту. Даже в этом случае на брутфорс уйдёт лет 50.
— Гость (29/01/2013 13:52)   <#>
Да, а что, по-моему, зарегать акк на pgpru с 16-ричным keyid'ом, совпадающим с SATtva'овским — это очень угарно. Я б сделал, но лень, стар я уже. ;)
Тогда на поиск коллизии уйдёт, скажем мягко, немного больше времени, что ставит под вопрос любительский характер атаки.

А как движок на pgpru.com переварит существование двух ключей с одинаковыми key id'ами? Будут ли проблемы с одинаковыми 8-мизначачными? А с одинаковыми 16-значными? Надо бы подумать об этом, пока доступ к кластеру есть.

Число итераций само по себе мало о чём не говорит

Не правильно. На характеристиках типов функций f(n) строится вся complexity theory. Не зря там полиномальное время отличают от экспоненциального. Если угодно, на обывательском уровне можно сказать так: решить полиномиальную задачу можно экстенсивными затратами, экспоненциальную — только интенсивными (кардинально менять модель вычислений или сам алгоритм).

Даже в этом случае на брутфорс уйдёт лет 50.

Допустим, это так для ПК. А теперь представьте, что у вас в распоряжении находится кластер, 1024 процессора, каждый из которых — четырёхядерник. Вычисление коллизии легко параллелится, поэтому делите время на 4096: 50⋅365/4096 ≈ 4.5 дня. Может, вас побрутать немного?
— Гость (29/01/2013 13:58)   <#>
Будут ли проблемы с одинаковыми 8-мизначачными? А с одинаковыми 16-значными?

Скорее, пожалуй, да, чем нет. Выглядит примерно так: регаем акк, грузим ключ, удаляем ключ. При удалении движок ссылается на keyid и поэтому сносит как коллизионный ключ, так и SATtva'овский. SATtva потом смотрит, видит, что ключ на pgpru пропал, думает, что взломали. А, может, даже и ещё веселее...
На страницу: 1, 2 След.
Ваша оценка документа [показать результаты]
-3-2-1 0+1+2+3