[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: xxx-draft-spec-for-TLS-normalization.txt
- To: or-dev@xxxxxxxxxxxxx
- Subject: Re: xxx-draft-spec-for-TLS-normalization.txt
- From: George Kadianakis <desnacked@xxxxxxxxx>
- Date: Thu, 27 Jan 2011 10:47:01 +0100
- Delivered-to: archiver@xxxxxxxx
- Delivered-to: or-dev-outgoing@xxxxxxxx
- Delivered-to: or-dev@xxxxxxxx
- Delivery-date: Thu, 27 Jan 2011 04:47:17 -0500
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:from:to:subject:in-reply-to:references :user-agent:date:message-id:mime-version:content-type; bh=5q6LQLLlIzhoE7xWUcJVWbLNF7ImFyg0JF4FPqVa0CY=; b=wKRSx1ow5ssg1HpM584chkNtUyiddU3Ugg90mg4+DlszRhf+SoaxwFLNw8L2yTB9Ib Ok+QIGdnemEXuj8w1boCwSzqqlrNLyUKsl+DUDjWNRMHJuzz4XPmiVZ+l+7jX5fiJUOg vCKcvhPc3wO+ODyX06yv0Efu7B9Y5MNJapuQ0=
- Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:subject:in-reply-to:references:user-agent:date:message-id :mime-version:content-type; b=aA61KPjuqjywiIfME2sOCKj7UryfWALpys2AEWnkJVWvdp124+7tbNKy1bz2oySZtn r/jeVzoatBq+x1AJ/p3W28mwaAP2SBPgQD/dPCWY2tJQVTMbrK26//HWj5JHNX0hdbMi lQ28qhnPqXIFNWx4TDIhEayVG1+S+xzYAfGs0=
- In-reply-to: <4D409534.3080302@xxxxxxxxxxxxx> (Jacob Appelbaum's message of "Wed, 26 Jan 2011 13:42:12 -0800")
- References: <4D409534.3080302@xxxxxxxxxxxxx>
- Reply-to: or-dev@xxxxxxxxxxxxx
- Sender: owner-or-dev@xxxxxxxxxxxxx
- User-agent: Microsoft Outlook Express 6.00.2900.5843
Jacob Appelbaum <jacob@xxxxxxxxxxxxx> 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 <mansourmoufid@xxxxxxxxx> 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.