Re: [dnsext] Adopting draft: draft-hoffman-dnssec-ecdsa-04.txt

[Phillip Hallam-Baker <[e-mail]>]

Well if the attacks are not theoretical we should not be considering
them at all.


I would ignore communication for calculation of work factor.

Shamir's TWIRL device shows one way of avoiding the communication issue.

We are talking about worst case here and we are always going to have a
significant degree of ambiguity. But even if you assume infinite
memory and infinite communication bandwidth, you can arrive at a lower
bound for the work factor.

We can also impose reasonable memory constraints like limiting the
number of storage locations to the number of atoms in the earth's
crust or whatever.


But the main point is that while everyone in the IETF is welcome to
participate in such a discussion we should be having exactly one
discussion, not one per WG. And we certainly should not be having
different discussions leading to different conclusions.


On Fri, Jan 7, 2011 at 10:14 AM, Florian Weimer <[e-mail]> wrote:
> * Phillip Hallam-Baker:
>
>> Work factor using known best attack is much better defined.
>
> Nope, because attacks tend to be theoretical, and it is hard to tell
> if the attacks could actually implemented as described in the
> technical reports, given sufficient resources.  Things like
> communication overhead in a parallel implementation are difficult to
> estimate and often not taken into account.  Even if this is resolved
> in some way (but it won't ever happen, I'm pretty sure), you have to
> deal with the question of trade-offs: how do you fold sizes and
> bandwidths of several types of storage, processing speeds and
> communication costs into a single number?
>
> If there are working attacks which you can run on real hardware, it
> makes sense to speak of work factors.  But then, you don't want to use
> the algorithms anymore, so this isn't an interesting case, either.
>
>> But all this is really outside the parameters of what DNSEXT should
>> have to concern itself with.
>
> I agree.  If there's a solution for this issue (due to very
> significant advances in cryptography, which are rather unlikely, given
> past performance), then the DNSSEC standards can use that knowledge.
> Right now, there is no such thing, at least in the public literature.
>
> --
> Florian Weimer                <[e-mail]>
> BFK edv-consulting GmbH       http://www.bfk.de/
> Kriegsstraße 100              tel: [phone]
> D-76133 Karlsruhe             fax: [phone]
>



-- 
Website: http://hallambaker.com/
_______________________________________________
dnsext mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/dnsext