Privacyprotect.org что это ?
что это реальная защита для владельцев доменов или хитрый способ воровства доменов у "анонимных" пользователей? на сайте не сказано на кого реально регистрируются домены и как это юридически...
Ссылки
[link1] http://privacyprotect.org/about-privacyprotection/?PHPSESSID=f504ba5bb46c0048841f14a0806127a9
[link2] http://privacyprotect.org/about-us/?PHPSESSID=f504ba5bb46c0048841f14a0806127a9
[link3] http://ru.wikipedia.org/wiki/Namecoin
[link4] http://pgp.mit.edu:11371/pks/lookup?search=0xfaebd5fc&op=index&fingerprint=on
[link5] http://www.pgpru.com/comment60175
[link6] https://debian-administration.org/users/dkg/weblog/105
[link7] http://www.asheesh.org/note/debian/short-key-ids-are-bad-news.html
[link8] https://en.wikipedia.org/wiki/Preimage_attack
[link9] https://www.ietf.org/mail-archive/web/openpgp/current/msg07195.html
[link10] https://en.wikipedia.org/wiki/Collision_resistance
[link11] https://en.wikipedia.org/wiki/Birthday_problem
[link12] http://www.anekdot.ru/id/165728/
Разве по ссылкам внизу [эта[link1] и эта[link2]] плохо объяснено? Регистрируют на себя, причём, видать, это происходит совершенно автоматически. Воруют или нет — не знаю, но цель сервиса — не защита от разрегистрации доменов (они сами пишут, что не владеют доменными именами), а защита личных данных, указанных при регистрации домена. По сути они выполняют роль посредника между регистратором доменов и владельцами сайтов, проксируя личные данные whois (заменяя их своими). Похоже на юридическое прокси типа оффшора: перед регистратором доменов владельцем будут выступать они, а реальный владелец будете типа вы.
Отдельно пишут, что все абузы по телефону и почтовому адресу будут отклоняться перенаправлением на форму на сайте, т.е. эта форма — единственный вид связи с реальным владельцем домена. Дальше, наверное, забыли написать, что не реагируют на абузы, но от разрегистрации домена регистратором это всё равно не спасёт. Регистраторы доменов, кстати, тоже не всесильны: если домен решили украть ЮСА, они просто пропишут его сразу на корневых DNS-серверах, и всё на том. Протокол DNS устроен так, что корневые DNS могут распоряжаться абсолютно любыми DNS-именами, в том числе нижележащего уровня: вместо запроса на DNS-сервер нижнего уровня могут вернуть DNS-клиенту ответ «не существует», и всё на том.
Создаётся домен .bit[link3].
Домены .onion и .i2p уже давно есть, дело осталось за малым: научить всех юзеров ими пользоваться, чтобы они стали общепринятыми. Более того, в отличие от .bit домены .onion и .i2p совершенно бесплатны и случайны, что делает киберсквоттинг бессмысленным.
И являются одновременно отпечатками аутентифицирующих самосгенерированных сертификатов в соответствующих сетях.
Ну если бы все ресурсы висели на индивидуальных айпишниках, как м.б. в случае IPv6, а обращение к ним шло бы только по IP-адресу, а не имени, то "сквоттинг" тоже бы не имел смысла. Разве что из-за красиво запоминающегося номера.
В случае криптоотпечатков: подобрать полный отпечаток нельзя (это равноценно взлому криптопротокола), проблема запоминаемости имени просто игнорируется. "Сквотить" совсем нечего.
Этот вопрос ранее обсуждался, но непонятность не разрешилась. В адресе используются первые сколько-то символов отпечатка, во-первых. Во-вторых, сбрутить их проще, чем весь отпечаток. Есть тулза для генерации отпечатков методом подбора, с её помощью можно добиться, чтобы первые 5-6 символов давали нужное слово. Если генерить некриптостойкие ключи, т.е. ориентироваться только на совпадение отпечатков, то, предположительно, скорость генерации ключей может быть ещё сильней повышена. И как поведёт себя Tor, когда появятся 2 разных onion-сайта, но с одинаковым адресом, не понятно. Может ли это использоваться в качестве атаки на целевой сайт?
Вот насколько сложно сгенерить PGP-ключ, чтобы совпал 16-ричный key id? Алфавит из 16 символов, слово длиной 16 букв, число вариантов — 1616, среднее время на подбор будет в 2 раза меньше, т.е. 1616/2 ≈ 9.2⋅1018 ≈ 263 — много это или мало? Ответ очевиден, сбрутать могут даже любители. Можно что-то аналогичное посчитать и для адресов в onion.
Кстати, были инициативы сделать внутриторовский домен .tor, чтобы на него можно было вешать любые адреса, которые потом будут разрешаться в соответствующий onion-адрес. Заглохли ли эти инициативы — не знаю.
[offtopic]
Только ключ будет неработоспособный, и полный отпечаток не будет совпадать. Смысл?
[/offtopic]
Проблема обсуждалась в рассылке GnuPG. Смысл в том, что при текущем стандарте это позволит прицельно задосить (заблокировать) скачивание чье-го либо ключа с серверов открытых ключей, которые будут возвращать ошибку при поиске. Вроде предполагается ввести в серверах поддержку поиска по полному отпечатку.
Теоретически, такая же уязвимость может докатиться и до системы согласования соединений со скрытыми Tor-сервисами, если в той сети не предусмотрена возможность разрулить конфликт при раздаче цепочек по совпадающем onion-именам. В I2P и Freedom, кажется есть возможность использовать как короткие, так и длинные отпечатки.
Насколько помню, это обсуждалось год или полтора назад. SKS с тех пор разве не пропатчили? Это легко проверить, если у кого-то под рукой есть список дубликатных 64-битовых keyID. Попытался сейчас погуглить, но наглилось только то, что сайт J. Harris'а со списком дубликатов прекратил существование.
[offtopic]
Подозреваю, что в том числе и троллинга[link4] ради.
[/offtopic]
Так уже в относительно новых SKS это есть. Можно искать по полным 160-битным, коротким 32-битным и по "средним" 64-битным.
Почему неработоспособный? Если генерировать ключи стандартным образом, то всё ОК будет.
Почему ошибку? Ключи-то есть с заданным отпечатком. Наверняка будут выдавать тот ключ, который быстрее найдётся.
Да, а что, по-моему, зарегать акк на pgpru с 16-ричным keyid'ом, совпадающим с SATtva'овским — это очень угарно. Я б сделал, но лень, стар я уже. ;)
Тогда на поиск коллизии уйдёт, скажем мягко, немного больше времени, что ставит под вопрос любительский характер атаки.
Линейно больше, что не принципиально. Число итераций как было 263, так и им и останется, просто время на итерацию несколько возрастёт. Думаю, современные кластеры такое быстро сделают, а доступ к кластерам есть у всех, кому не лень.
Число итераций само по себе мало о чём не говорит (если оно изначально не выходит за разумные пределы). Предположим, вы хэшируете короткий пароль со сложностью 225 по PBKDF2 с таким числом итераций, что проверка занимает минуту. Даже в этом случае на брутфорс уйдёт лет 50.
А как движок на pgpru.com переварит существование двух ключей с одинаковыми key id'ами? Будут ли проблемы с одинаковыми 8-мизначачными? А с одинаковыми 16-значными? Надо бы подумать об этом, пока доступ к кластеру есть.
Не правильно. На характеристиках типов функций f(n) строится вся complexity theory. Не зря там полиномальное время отличают от экспоненциального. Если угодно, на обывательском уровне можно сказать так: решить полиномиальную задачу можно экстенсивными затратами, экспоненциальную — только интенсивными (кардинально менять модель вычислений или сам алгоритм).
Допустим, это так для ПК. А теперь представьте, что у вас в распоряжении находится кластер, 1024 процессора, каждый из которых — четырёхядерник. Вычисление коллизии легко параллелится, поэтому делите время на 4096: 50⋅365/4096 ≈ 4.5 дня. Может, вас побрутать немного?
Скорее, пожалуй, да, чем нет. Выглядит примерно так: регаем акк, грузим ключ, удаляем ключ. При удалении движок ссылается на keyid и поэтому сносит как коллизионный ключ, так и SATtva'овский. SATtva потом смотрит, видит, что ключ на pgpru пропал, думает, что взломали. А, может, даже и ещё веселее...
Внутренние операции с ключами производятся по полным отпечаткам.
Убедили.
Заметка старая, но на форуме ещё не упоминалась:
Мотив в том, что, похоже, keyid'ы до сих пор много где используются, но мы об этом не подозреваем, что может вести к дырам в безопасности или просто к бажному поведению.
Гы, SATtva, лол[link12]. Неужели GnuPG на pgpru.com особый, пропатченный? Как в воду глядели:
Насколько помню, WK упоминал об этом в рассылке, так что, за что купил — за то продал (если только не протупил и не понял что-то неправильно).