On 1/21/2010 12:12 PM, Eric Rescorla wrote:
On Thu, Jan 21, 2010 at 11:38 AM, Paul Hoffman<paul.hoff...@vpnc.org> wrote:
At 2:17 PM -0500 1/21/10, Edward Lewis wrote:
At 11:05 -0800 1/21/10, Eric Rescorla wrote:
I still don't understand why this implies the need for regular changes
as opposed to changes triggered by personnel changes.
I'm a bit lost following this thread now.
For the time being, let's ignore personnel changes and whether a key is in an
HSM (environment), i.e., assume there's no organizational threat to a key.
The question is, how long does a key last?
Meaning - if I am using an RSA-SHA256 key of 1024 bits, at what point does it's
security value reach essentially 0?
Is the point X number of signatures?
No. There is no suspicion on the part of any cryptographer that I know of that
the number of visible signatures is significant for a 1024-bit or above key.
Agreed. Recall that with PKC an attacker can generate as many
plaintext/ciphertext pairs as
he wants.
Is the point Y number of days?
Yes, if the number of days is in the thousands (currently) and the value of
this key is high. Otherwise, no.
I actually sort of disagree with this. I don't see how to evaluate
this question in a meaningful
way, and it's not a cryptographic question. Let's say for the sake of
argument that we know
if requires C CPU-hours to break a key and that each CPU costs $H but
is free to run once
you own it (not true). In that case, an attacker with $D to spend can
break a single key in
C/(D/H) hours. How long is that key secure for? Who knows. Most of
the variance is in attacker
motivation and funding, not time.
Actually Eric if the credential is only valid for a period of time which
is less than the amount of time needed with CPU Resource created by $D
(i.e the money to pay for CPU $H) then the process is very relevant so
the issue is how long is the credential negotiable for and is that
number less than the perimeter of the 'can be hacked with these
resources' ???
http://www.nvidia.com/object/cuda_home.html#
For most keys, no, at least for the next five years or so.
No its not.
That is, the *cost* of breaking a 1024-bit key, when that is feasible, is still
much higher than the value of the broken key.
The problem is that nVidia CUDA based brute force engines are
available that produce 42TF of compute engine off the shelf and for
under 10K... and gee whiz they rock for factoring. Especially when ten
gamers get together and put 20 of the SLI enabled GX2 and other quad GPU
cards which effectively sport 240 thread cores per card. Compare that to
the wimpy Quad-Core P4's on the market today and you will start to see
the future.
In this instance nVidia's TESLA systems rock
http://www.nvidia.com/object/tesla_computing_solutions.html - Imaging
what you can do to a PW with one of these running FreeBSD or Linux and
John the Ripper. I think its less than 2 years before factoring engines
based on nVidia Cores are common place outside the NSA.
Remember that a broken signing key is only valuable until the fact that it is
broken is discovered and fixed. So, even if an attacker breaks your signing
key, when he/she starts to use it for nefarious purposes and you discover that,
you roll your key and the entire time of breaking the new key must be used
again before they can mount another attack.
Exactly. So rolling it preemptively doesn't help much.
-Ekr
The "need for regular changes" stems from assumptions made in the early days of
DNSSEC development that have gone pretty much unchallenged until recently. The door is
open to (re)visit this topic, if anyone wants to venture opinions.
See above. :-)
So, the referenced post summarizes my opinion. I don't care enough about it to
fight it to the death here, however.
What I'd like to hear is:
"Crypto-expert __________ says an RSA-SHA256 key of 1024 bits is good for _______
signatures/days."
If you hear that, the the value for the first variable will be worthless. You
have to factor in the value of the key to the attacker for the short period in
which they can use it before their actions are discovered and the broken key is
replaced.
I more or less agree with this. You may want to hear that, but there's
no meaningful answer.
-Ekr
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
No virus found in this incoming message.
Checked by AVG - www.avg.com
Version: 8.5.432 / Virus Database: 271.1.1/2636 - Release Date: 01/21/10
07:34:00
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
