Ted, Some clarifications:
Ted Lemon wrote: > Sent: Tuesday, September 14, 2010 4:07 PM > To: Tony Cheneau > Cc: [email protected] Group; [email protected]; Droms; [email protected] > Subject: Re: [CGA-EXT] [dhcwg] Follow up request for review of draft- > ietf-csi-dhcpv6-cga-ps > > On Sep 14, 2010, at 6:08 PM, Tony Cheneau wrote: > > So, as long as the public/private key are generated on the node, I > > would say that you will not need to communicate the private key (in > > clear or in a ciphered form). > > Actually, this is clear as mud to me. What is the big compute job > that's being done on the server, then? Can you point me to the RFC I > should be reading that explains all this? Sorry to be obtuse. :'} If you have a look at the CGA generation algorithm described in RFC 3972 you will see that there are potentially two distinct computationally intensive tasks: 1. generation of public-private (RSA) key pair 2. generation of a CGA modifier value for a given Security Parameter (Sec) as per RFC 3972. (The Sec is used to harden the resistance of brute force attacks on the 64-bits IIDs of CGAs.) #2 above might become computationally intensive for values of the Sec higher than zero (if it's zero any Modifier satisfies 3972). Back in 2002 I remember running the algorithm on then standard personal computers (e.g., x86 / ~1GhZ) and it would took ~20 seconds for Sec = 1 and a couple of minutes for Sec = 2. I do not remember going higher... I understand the proposal is to offload #2 to the server while #1 would not be. IMHO it does not any make sense to offload when Sec is set to 0 because the computational load is nil. When Sec is set to 1 the computational load of #2 seems to be in the same order of magnitude as for #1, which does not necessarily means that offloading is useless as #1 might not need to be done by the constrained device itself (e.g., it's been offload to someone else, and result is stored on a smartcard.) That being set I have not been convinced yet that there's a real world use case for Sec values higher than zero. HTH, --julien _______________________________________________ CGA-EXT mailing list [email protected] https://www.ietf.org/mailman/listinfo/cga-ext
