desnacked at gmail.com
Thu Jan 27 09:47:01 UTC 2011
Jacob Appelbaum <jacob at appelbaum.net> writes:
> I've re-worded and added some feedback from Tom and others to this
> draft. If anyone has any further comments before this becomes a numbered
> proposal - please reply on or-dev rather than privately as I'd like to
> keep the thread going in the open.
> All the best,
As far as the certificate fields , the key size  and the
certificate time length are concerned, I'm wondering if it would be
worth it using the EFF's SSL Observatory data  to figure out the most
conservative values to use (and in the case of cert. fields, which
fields are actually usually used in the real world).
Mansour Moufid <mansourmoufid at gmail.com> writes:
>> As a security precaution, care must be taken to ensure that we do not generate
>> weak primes or known filtered primes. Both weak and filtered primes will
>> undermine the TLS connection security properties. OpenSSH solves this issue
>> dynamically in RFC 4419  and may provide a solution that works reasonably
>> well for Tor. More research in this area including Miller-Rabin primality tests
>> will need to be analyzed and probably added to Tor.
>RFC 4419 suggests the Miller-Rabin test because it is efficient and
>well-known. Perhaps Tor could use the AKS primality test, which is
>also efficient, and deterministic.
The problem with AKS - and the reason it's not used in real life
applications - is it's terrible performance when in contrast with all
the other probabilistic primality tests .
: Like you said, one could claim that the current Tor TLS
certificates could be fingerprinted by their empty O/L/ST/C/OU fields.
: By the way, the key size upgrade (and the addition of more
ciphersuites) is also planned as part of the Tor ciphersuite migration.
: Check out "An Implementation of the AKS Primality Test" from
Robert G. Salembier and Paul Southerington, for example.
More information about the tor-dev