At 9:46 PM -0400 4/24/09, Joe Abley wrote:
>On 24 Apr 2009, at 21:17, Paul Hoffman wrote:
>
>>At 7:53 PM -0400 4/24/09, Joe Abley wrote:
>>>It seems fruitless to debate whether 1024 bits is sufficient if there's no
>>>real cost to just choosing (say) 4096 bits and avoiding the discussion.
>>
>>Please read the text: larger keys incur a real cost to people validating.
>
>The text contains the following sentence: "In a standard CPU, it takes about
>four times as long to sign or verify with a 2048-bit key as it does with a
>1024-bit key." I couldn't find any other discussion of the cost to validators
>of large key sizes.
2048 is "large". :-) As I said earlier in this thread, 'openssl speed' is your
friend.
sign verify sign/s verify/s
rsa 1024 bits 0.007343s 0.000322s 136.2 3107.6
rsa 2048 bits 0.042943s 0.001093s 23.3 914.8
rsa 4096 bits 0.275508s 0.003920s 3.6 255.1
At least on this box with this build of OpenSSL, the multiplier is about three
times for each doubling of the key size.
>If there is a practical limit to key size due to concerns about peoples'
>validators running out of steam, then I think it needs to be stated clearly.
>Otherwise as a zone administrator my instinct will be to use keys that are as
>large as possible, since the costs incurred by doing so are going to be borne
>by other people and all I see is benefit (in the form of increased comfort
>level and a better story for upper management, even if there is no practical
>improvement in security).
That's certainly your option. Another option is to listen to cryptographers
about what is possible with a reasonable amount of money and time, and stop
there.
>On the flip side, how can the "real cost" for validator-operators that you
>assert be quantified?
Exactly.
>I have a hand in running a couple of non-validating resolvers for a local ISP.
>35,000 customers are served by two machines running BIND 9.5.x on FreeBSD 7.1,
>and the CPUs are 96% idle at peak load. That's a fair amount of headroom, even
>ignoring the fact that the ISP in question is in the process of replacing each
>machine with an ECMP/OSPF cluster of two machines in order to simplify ad-hoc
>maintenance.
>
>I'm not arguing about the assertion that there is a limit to what validators
>can tolerate. However, it seems reasonable to ask if it's the kind of limit
>that we need to worry about, and not, the kind of limit that is always going
>to fit in that headroom as validator hardware gets upgraded on a typical cycle
>and DNSSEC deployment proceeds over time.
How will you know? Why not stop when enough is enough?
--Paul Hoffman, Director
--VPN Consortium
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
