[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: TSVN and SSL

From: Thomas Harold <thomas-lists_at_nybeta.com>
Date: Tue, 21 Jan 2014 10:46:55 -0500

On 1/20/2014 5:37 AM, Simon D Morris wrote:
> Perhaps someone with more knowledge of SSL could give some advice:
>
> What constitutes "good practice" at present for key lengths, algorithms
> and the like for server and client keys and certificates, in the context
> of an Apache HTTPS solution and TSVN?

The main issue with RSA keys is that every time you double the number of
bits, the CPU time increases by a factor of 6x-7x.

http://www.javamex.com/tutorials/cryptography/rsa_key_length.shtml

http://kemptechnologies.com/loadbalancingresource/kemp-load-balancer-white-papers-web-ip-load-balancer-information/moving-to-2048-ssl-keys-and-the-impact-on-computing-resources

So while moving to 4096 bit RSA sounds good in theory if you are worried
that 2048 bit is too weak, it will have a (measurable?) impact on how
fast TSVN can setup the SSL connection to the server.

Maybe it's better to move up to 3072 bit keys instead of jumping
straight from 2048 to 4096. But that depends on what level of adversary
you are willing to guard against. Personally, I think RSA/2048 is fine
for the next 5-10 years or so, against all attackers with less then 1
million USD in funding. If you're still using RSA/1024 or lower, then
it's definitely time to upgrade.

Or consider using some of the ECs (Elliptic Curve), which provide
equivalent or better security at smaller bit lengths and less CPU power.
  Most sources seem to feel that 200-224 bits of EC is equivalent to
RSA/2048.

------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=3071857

To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2014-01-21 16:47:13 CET

This is an archived mail posted to the TortoiseSVN Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.