[tor-dev] Extending deadline for small features in 0.2.3.x by one week (to the 13th)

[Nick Mathewson]

On Mon, Jan 9, 2012 at 9:13 PM, Jacob Appelbaum <jacob at appelbaum.net> wrote:
> On 01/09/2012 06:01 PM, Nick Mathewson wrote:
>> On Mon, Jan 9, 2012 at 8:49 PM, Jacob Appelbaum <jacob at appelbaum.net> wrote:
>>>
>>> Should I make such a branch and request it for review?
>>
>> I don't think this is a good idea for 0.2.3.x without data.  Specifically:
>>
>>    * What fraction of servers on the net right now use 2048-bit RSA
>> link keys and 2048-bit DH groups?  (Or 1024 bit RSA keys and 1536-bit
>> DH keys, etc)
>
> All new EV certs must be 2048-bit RSA - generally speaking, they all use
> 1024-bit DH groups or a different default provided by the web server
> software.

Well, we can't forge EV certs, so we should probably instead be
looking at the fraction of 2048 non-EV certs out there.

Also, having longer RSA keys than DH groups is totally backwards for
our needs. We'd like the work factor for breaking forward-secrecy to
be pretty high, since it's relevant for longer, whereas the work
factor for impersonating a server is less important, since we can move
to longer keys later.

I wonder if EFF's SSL observatory has data here.

>>    * How much would this slow down typical clients and servers?
>>
>
> That's a good question - how shall we answer that?

Testing or calculation, I'd guess.

>>>From a security POV, increasing the link key modulus size of 2048 bits
>> doesn't seem to do anything useful.  If somebody wants to decrypt an
>> intercepted communication, the DH g^x value is what they need to
>> solve.  OTOH, if we want to stop somebody from *impersonating* a
>> server, then using a 2048-bit link key wouldn't do any good: factoring
>> the identity key would give equally good results.
>>
>
> I want to stop sniffers from having useful data. A 2048-bit link key
> with a 2048-bit DH group seems like a fine idea and seems to be far
> beyond the current reach of anything public - whereas 1024bit seems less
> than perfect in short order...

For beating passive observer, it's the DH group size that matters.

[...]
>> So my thought is that we should target 0.2.4.x for this kind of thing,
>> and do it properly.
>
> Ok. I suppose the good news is that this is all server side. So we
> really only need a few thousand servers to upgrade rather than millions
> of clients, right?

Sounds right. Though really, we should also be looking into similar
increases in key strength for our other crypto too, particularly our
circuit handshake.  My new-crypto-ops draft tried to make progress
here; I should try to revise it soon.

cheers,
-- 
Nick