19.12 // Новые ветки стабильных версий Tor и Tor Browser Bundle
12 декабря стабильная версия Tor переведена на 0.2.4.19. Одним из основных нововведений является переход на криптографию на эллиптических кривых (ECC), с размерами ключей, которые позволяют снизить загрузку узлов, одновременно повысив стойкость шифрованного соединения. При этом использована кривая "curve25519" от Дэниэла Бернштейна, что является альтернативой стандарту НИСТ. Также ликвидированы потенциальные уязвимости с кэшированием на стороне клиента ответов DNS, которые могли сохраняться при смене исходящих узлов и служить своеобразными метками трафика; улучшена защита директорий скрытых сервисов; увеличен интервал работы со сторожевыми узлами.
С 19 декабря прекращается поддержка стабильных веток Торбраузера 2.x и 3.0. Всем пользователям рекомендуется перейти на TBB версии 3.5. В новой версии TBB отсутствует контроллер Vidalia, а запуск локального tor-процесса осуществляется непосредственно из самого TBB.
Источник: Tor-talk mailing list, The Torproject Blog.
комментариев: 9796 документов: 488 редакций: 5664
Существует ли способ доказать, что кривая выбрана не злонамеренно, и ни у кого нет к ней отмычки? Извиняюсь за оффтоп.
комментариев: 9796 документов: 488 редакций: 5664
У Бернштейна и НИСТ кривые оптимизированные, но обоснование незлонамеренности критериев выбора кривой DJB приведено в работе.
Теперь 2-3 месяца. Точное время жизни генерируется случайным образом, но так, чтобы оно попадало в этот интервал?
Если я понял правильно, криптостойкость симметричного ключа в 128 бит там приравнивают к длине RSA-ключей в 3072 бита. При всём этом в GnuPG при генерации RSA-ключей вроде до сих пор 2048 — дефолт. Кто из них занижает/завышает оценки на безопасность?
При заходе по ссылке на сайт АНБ в логах TBB:
Если АНБ сможет факторизовать ключи DH-1024, которые ранее использовались в Tor, оно сможет расшифровать его трафик?
Первый раз о таком слышу.
Всю жизнь думал, что иксовое окружение как раз формируется в терминале настройками (скрипт с прописываемыми переменными ~/.xsession и конфиг ~/.Xresources). Можно ещё добавить конфиги оконного менеджера, но сам он ничего в настройках иксов не меняет и не лезет, куда его не просили.
Не совсем так. Сначала запускается Tor. Как только Tor успешно запущен, запускается окно firefox. Если есть проблемы с запуском Tor'а, окно firefox'а не появится. А чтобы Tor запустился, он должен получить достаточно информации из сети, чтобы построить цепочки, только после этого он рапортует
По ссылке:
В упор не понимаю, почему «both»? Если через about:config уже полностью отключено, какой смысл лезть в настройки NoScript? Он может случайно включить JS, даже если в about:config стоит javascript.enabled=false?
Вообще, если посмотреть на этот лист... Это только changelog, а не полное описание всего и вся, которое есть в тикетах и коментах к ним. Но даже чтобы не просто прочитать, а хотя бы бегло пробежаться глазами по одним только заголовкам changelog'а, уже нужно минут 15. А если внимательно вдумчиво прочитать его весь — уже час или больше. Вникнуть в то, что сделано, просмотрев все тикеты — работа на несколько дней минимум. Чтобы просто более-менее детально себе представлять, что сейчас происходит в Tor Project, надо заниматься чтением рассылки и их сайта круглые сутки. И это только TBB, не говоря уже о других программах для безопасности. Я вынужден констатировать, что современный Tor — это страшный гигантский комбайн, монстр, в котором уже столько всего наворочено, что одиночке пришлось бы несколько лет пухнуть над всей информацией, чтобы детально понять, как он сейчас работает и почему протокол именно таков.
Они бы и до этого дошли,* да, боюсь, производительность JS для таких масштабных задач их бы вряд ли устроила. Впрочем, сама идея написать Tor-клиент на JS звучит весело. ☺
Во фразах
CSE глазами автоматически читается как CNE, ничего не могу с собой поделать. ☹
Как-то это неубедительно звучит. Если бы каждый для себя генерировал кривую, то можно было бы на рандом сослаться. Но, как я понимаю, стороны (в общем случае друг другу недоверяющие) должны договориться о выборе кривой. И одна сторона может предложить кривую, которая кажется рандомной, а реально у неё к ней отмычка есть. Может такое быть?
То же касается предложений к стандартам, оптимизированных кривых и т.д. Хорошо, пусть кто-то предложил метод, описал его и предъявил результат. Как мне потом проверить, что результат действительно случаен? Как можно приписать случайность конкретному числу? Мы же со свечкой не стояли, когда автор кривой её генерировал. Не имею ничего против djb, но всё-таки на основе чего выстраивается доверие к кривым в ECC? Насколько исчерпывающий аудит предложенных констант может провести постороннее лицо?
*А что, это удобно: ничего устанавливать в браузер не нужно; зашёл по ссылке — подхватил
вирьTor, теперь всё само работаети анонимно и безопасно.комментариев: 9796 документов: 488 редакций: 5664
Да. Об этом в форуме неоднократно упоминалось. Последнее обсуждение здесь.
Большинство страниц сайта работает через https, но не все. В "Https everywhere" правил для этого сайта нет, так что проблема или фича на стороне сервера.
s/Tor/OpenSource//g
В обычном DH и DSA можно брать параметры (не кривой, а g и p) от НИСТ, к которым также были подозрения, а в SSL есть опция самому сгенерировать
такие параметры. Только это несколько ресурсоёмко. Если обе стороны хотят использовать неконвенциональные параметеры — теоретически они могут их сгенерировать через совместный рэндом или необязательно даже рэндом, любое значение для запуска детерминированного ГПСЧ.
Nothing up my sleeve number.
Для какого-то алгоритма встречалось описание, когда использовали такое число для запуска конвенционального ГПСЧ и строгие критерии останова оптимизации на ограниченном количестве чисел выхода. Примерно как «генерируем 10000 параметров, из них выбираем самый лучший, вероятность таким путём получить параметр с предопределёнными для закладки свойствами низка до такой-то величины».
В конкурсе AES и особенно SHA-3 отсутствие закладок в константах нужно было доказывать.
А в Tor как выбираются эти параметры? Взяты со стандарта или сгенерены самостоятельно?
комментариев: 9796 документов: 488 редакций: 5664
комментариев: 9796 документов: 488 редакций: 5664
Точно не знаю, старая версия DH называлась в торе "TAP", новая "NTor", можно поискать по описанию старых версий протокола.
Динамический выбор p для DH использовался в бриджах, для узлов его тоже хотели ввести, но не помню, чем дело закончилось. А статические параметры были взяты то ли с какого-то rfc, то ли так, как по умолчанию у серверов Apache.
Для g вроде всегда использовалось только число 2.
комментариев: 9796 документов: 488 редакций: 5664
Только в версиях до 3.5 неисправленные баги, критичные для деанонимизации — что-то связанное с обработкой изображений.
В логах Tor:
Просто так получилось, что данные опции ускоряют не только НИСТовские кривые, но и Бернштейновские? Иначе как объяснить упоминание НИСТ?