Hi Rene Makes more sense this way. Need to also add replay protection but that should be just part of the hash. Will it make things better for user experience? That depends on how big the pool of (good randomized) pre-computed values can be created before they run out and causes a stuck behavior.
Regards Sandeep From: Rene Struik [mailto:rstruik....@gmail.com] Sent: Tuesday, July 26, 2016 3:00 AM To: Kumar, Sandeep; Stephen Farrell; Somaraju Abhinav; Michael StJohns; ace@ietf.org Subject: Re: [Ace] Adoption of Low Latency Group Communication Security Work in ACE Hi Sandeep: Fair enough, but with, e.g., ECDSA, computation of the ephemeral key R:=kG can be carried out independently of the remainder of the signature computation (where one computes e:=h(m), and calculates s:=(1/k)(e-r*d)(mod n) and subsequently outputs (r,s), where r is derived from R). So, if one wishes to, one can pre-compute many ephemeral key pairs (k, kG) and use those on demand {David Naccache, if I remember correctly, elaborated on these types of "labor division" in a 1998 paper}. So, in the Philips high-granularity luminary, the one simply hashes the state (still only a few-bytes entry) and then combines e with r, d, k, to produce signature component s -- a simple linear equation with two modular multiplies as cost. Let's make things better... Rene On 7/25/2016 5:34 PM, Kumar, Sandeep wrote: Because sometimes a lightswitch can have more than two states. [http://images.philips.com/is/image/PhilipsConsumer/6916431PH-IMS-en_GB?wid=494&hei=435&$pnglarge$] The color dial on this switch (src: http://www.philips.co.uk/c-p/6916431PH/livingcolors-remote-control) can set the color of lights one chooses. That would be quite some precomputations. Sandeep -----Original Message----- From: Ace [mailto:ace-boun...@ietf.org] On Behalf Of Stephen Farrell Sent: Monday, July 25, 2016 9:26 PM To: Somaraju Abhinav; Michael StJohns; ace@ietf.org<mailto:ace@ietf.org> Subject: Re: [Ace] Adoption of Low Latency Group Communication Security Work in ACE On 25/07/16 17:59, Somaraju Abhinav wrote: > we essentially have 50-100 ms for the signing+verification process and > I do not know of a solution that does this Just a clarifying question: why can't the signing possibly be done asynchronously? E.g. the private key holder could sign a value that will only be sent later - as long as it has one of those ready to emit whenever needed one can ignore the signing time. That can have power consumption consequences but I'd guess that's ok for a lightswitch. If signing can be done ahead of time, then only verification time has to be considered. S. ________________________________ The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message. _______________________________________________ Ace mailing list Ace@ietf.org<mailto:Ace@ietf.org> https://www.ietf.org/mailman/listinfo/ace -- email: rstruik....@gmail.com<mailto:rstruik....@gmail.com> | Skype: rstruik cell: +1 (647) 867-5658 | US: +1 (415) 690-7363
_______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
