On Tue, Apr 1, 2014 at 5:39 AM, Olafur Gudmundsson <o...@ogud.com> wrote:
> Doing these big jumps is the wrong thing to do, increasing the key size > increases three things: > time to generate signatures > bits on the wire > verification time. > > I care more about verification time than bits on the wire (as I think that > is a red herring). > Signing time increase is a self inflicted wound so that is immaterial. > > sign verify sign/s verify/s > rsa 1024 bits 0.000256s 0.000016s 3902.8 62233.2 > rsa 2048 bits 0.001722s 0.000053s 580.7 18852.8 > rsa 4096 bits 0.012506s 0.000199s 80.0 5016.8 > > Thus doubling the key size decreases the verification performance by > roughly by about 70%. > With those numbers; if the validating resolver uses speculative/optimistic concurrency [1] then jumping from 1024 to 4096 bits, the user-impact is that ~180us are added to the overall resolution time. Zero in the cached case. There is an impact on the overall capacity of the resolver, though it's a function of cache-miss-rate (since cache hits need not be verified). Large centralised resolver operators may face some pressure (anyone doing validation locally is unlikely to notice), but is it sensible to compromise your zone security to accommodate that? [1] There's no need to wait for a response to be validated before recursing, a validating resolver can first recurse and later backtrack if the parent signature doesn't verify. -- Colm
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
