Jacob Appelbaum <[email protected]> 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, > Jake
As far as the certificate fields [1], the key size [2] and the certificate time length are concerned, I'm wondering if it would be worth it using the EFF's SSL Observatory data [3] 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 <[email protected]> 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 [2] 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 [4]. [1]: Like you said, one could claim that the current Tor TLS certificates could be fingerprinted by their empty O/L/ST/C/OU fields. [2]: By the way, the key size upgrade (and the addition of more ciphersuites) is also planned as part of the Tor ciphersuite migration. [3]: https://www.eff.org/files/downloaded-certificates.tar.lzma.torrent https://www.eff.org/files/csv-db-files.tar.lzma.torrent [4]: Check out "An Implementation of the AKS Primality Test" from Robert G. Salembier and Paul Southerington, for example.
