RE: non 2048-bit keys
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
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
Re: non 2048-bit keys
>> ... 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