При этом использована кривая "curve25519" от Дэниэла Бернштейна

Raise the default time that a client keeps an entry guard from "1-2 months" to "2-3 months", as suggested by Tariq Elahi's WPES 2012 paper. (We would make it even longer, but we need better client load balancing first.) Also, make the guard lifetime controllable via a new GuardLifetime torrc option and a GuardLifetime consensus parameter. Start of a fix for bug 8240; bugfix on 0.1.1.11-alpha.

Redirection loop trying to set HTTPS on:
  http://www.nsa.gov/business/programs/elliptic_curve.shtml
(falling back to HTTP)
Redirection loop trying to set HTTPS on:
  http://www.nsa.gov/_root/images/nav_home-off.jpg
(falling back to HTTP)
Redirection loop trying to set HTTPS on:
  http://www.nsa.gov/_root/css/main.css
(falling back to HTTP)
Redirection loop trying to set HTTPS on:
  http://www.nsa.gov/_root/images/header.jpg
(falling back to HTTP)

Tor has successfully opened a circuit. Looks like client functionality is working

How do I disable JavaScript?
…
If you want to be extra safe, use both the about:config setting and NoScript.

NIST and NSA, with some participation from CSE

Most of work on standards done by US federal employees (NIST and NSA, with some help from CSE)

Да. Об этом в форуме неоднократно упоминалось. Последнее обсуждение здесь.

Большинство страниц сайта работает через https, но не все. В "Https everywhere" правил для этого сайта нет, так что проблема или фича на стороне сервера.

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

s/Tor/OpenSource//g

Если бы каждый для себя генерировал кривую, то можно было бы на рандом сослаться. Но, как я понимаю, стороны (в общем случае друг другу недоверяющие) должны договориться о выборе кривой. И одна сторона может предложить кривую, которая кажется рандомной, а реально у неё к ней отмычка есть. Может такое быть?

В обычном DH и DSA можно брать параметры (не кривой, а g и p) от НИСТ, к которым также были подозрения, а в SSL есть опция самому сгенерировать
такие параметры. Только это несколько ресурсоёмко. Если обе стороны хотят использовать неконвенциональные параметеры — теоретически они могут их сгенерировать через совместный рэндом или необязательно даже рэндом, любое значение для запуска детерминированного ГПСЧ.

Как мне потом проверить, что результат действительно случаен? Как можно приписать случайность конкретному числу? Мы же со свечкой не стояли, когда автор кривой её генерировал.

Nothing up my sleeve number.

Для какого-то алгоритма встречалось описание, когда использовали такое число для запуска конвенционального ГПСЧ и строгие критерии останова оптимизации на ограниченном количестве чисел выхода. Примерно как «генерируем 10000 параметров, из них выбираем самый лучший, вероятность таким путём получить параметр с предопределёнными для закладки свойствами низка до такой-то величины».

В конкурсе AES и особенно SHA-3 отсутствие закладок в константах нужно было доказывать.

Точно не знаю, старая версия DH называлась в торе "TAP", новая "NTor", можно поискать по описанию старых версий протокола.

Динамический выбор p для DH использовался в бриджах, для узлов его тоже хотели ввести, но не помню, чем дело закончилось. А статические параметры были взяты то ли с какого-то rfc, то ли так, как по умолчанию у серверов Apache.

Для g вроде всегда использовалось только число 2.

For Diffie-Hellman, we use a generator (g) of 2. For the modulus (p), we
use the 1024-bit safe prime from rfc2409 section 6.2 whose hex
representation is:

"FFFFFFFFFFFFFFFFC90FDAA22168C234C4C6628B80DC1CD129024E08"
"8A67CC74020BBEA63B139B22514A08798E3404DDEF9519B3CD3A431B"
"302B0A6DF25F14374FE1356D6D51C245E485B576625E7EC6F44C42E9"
"A637ED6B0BFF5CB6F406B7EDEE386BFB5A899FA5AE9F24117C4B1FE6"
"49286651ECE65381FFFFFFFFFFFFFFFF"

XXX XX XX:XX:XX.XXX [notice] We were built to run on a XX-bit CPU, with OpenSSL X.X.X or later, but with a version of OpenSSL that apparently lacks accelerated support for the NIST P-224 and P-256 groups. Building openssl with such support (using the enable-ec_nistp_64_gcc_128 option when configuring it) would make ECDH much faster.