RE: non 2048-bit keys

2010-08-16 Thread ian.farquhar
Samuel Neves wrote:

 If an attacker creating a special-purpose machine to break your keys is
 a realistic scenario, why are you even considering keys of that size?

What's the threat model?

If the set of possible actors includes first world SIGINT agencies, then yes, 
it is a reasonable assumption that a special configuration of system has been 
created to factor keys.  Think IBM or pre-acquisition SGI or pre-acquisition 
Sun as a supplier of such hardware, scaled up way beyond the configurations 
you'd get in the marketing literature (tens of thousands of cores, terabytes of 
physical RAM, low-range nine-figure price tags).

But as such an attack would likely cost millions of dollars per key, because 
the time to solution would be weeks or even months, then they'll only be using 
it as a last resort.  As Peter correctly pointed out, there are so many other 
viable threat vectors which are available, especially human-in-the-loop ones, 
which would likely be exhausted before that solution was tried.

For non-government level attacks, I agree that such a scenario is unrealistic.

Ian.

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


Re: non 2048-bit keys

2010-08-15 Thread John Gilmore
  ... 2048-bit keys performing
 at 1/9th of 1024-bit. My own internal benchmarks have been closer to
 1/7th to 1/8th. Either way, that's back in line with the above stated
 90-95% overhead. Meaning, in Dan's words 2048 ain't happening.

Can I abuse a phrase and call this binary thinking?

There is no reason that the next step after 1024 bits has to be 2048 bits.
How about 1032 bits?  Or 1040?  Or 1104?
How about 1200 bits?  How about 1536?  How about 1600?  1808?

I have a theory that if everyone picked a pseudo-random key size above
1024 and below 2048, rather than standardizing on Yet Another Fixed
Keysize, we'd avoid making a powerful incentive for bad guys to build
a key-cracker optimized for one size.  Which incentive we have
currently created at 1024 bits.  It's the Microsoft Windows of key
sizes -- the target that gets you 90+% of the market.  So pick a
larger size than 1024 that your server load can live with, even if it
isn't 2048.  And don't tell anybody else what size you picked :-).

John

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


Re: non 2048-bit keys

2010-08-15 Thread Samuel Neves

If an attacker creating a special-purpose machine to break your keys is
a realistic scenario, why are you even considering keys of that size?

Best regards,
Samuel Neves

On 15-08-2010 04:25, John Gilmore wrote:
  ... 2048-bit keys performing
 at 1/9th of 1024-bit. My own internal benchmarks have been closer to
 1/7th to 1/8th. Either way, that's back in line with the above stated
 90-95% overhead. Meaning, in Dan's words 2048 ain't happening.
 Can I abuse a phrase and call this binary thinking?

 There is no reason that the next step after 1024 bits has to be 2048 bits.
 How about 1032 bits?  Or 1040?  Or 1104?
 How about 1200 bits?  How about 1536?  How about 1600?  1808?

 I have a theory that if everyone picked a pseudo-random key size above
 1024 and below 2048, rather than standardizing on Yet Another Fixed
 Keysize, we'd avoid making a powerful incentive for bad guys to build
 a key-cracker optimized for one size.  Which incentive we have
 currently created at 1024 bits.  It's the Microsoft Windows of key
 sizes -- the target that gets you 90+% of the market.  So pick a
 larger size than 1024 that your server load can live with, even if it
 isn't 2048.  And don't tell anybody else what size you picked :-).

   John

 -
 The Cryptography Mailing List
 Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com


-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com