Re: [Ace] Adoption of Low Latency Group Communication Security Work in ACE

Rene Struik <rstruik.ext@gmail.com> Tue, 26 July 2016 01:01 UTC

Return-Path: <rstruik.ext@gmail.com>
X-Original-To: ace@ietfa.amsl.com
Delivered-To: ace@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E3D612DA97 for <ace@ietfa.amsl.com>; Mon, 25 Jul 2016 18:01:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GJWIb-7nBw3S for <ace@ietfa.amsl.com>; Mon, 25 Jul 2016 18:01:11 -0700 (PDT)
Received: from mail-it0-x229.google.com (mail-it0-x229.google.com [IPv6:2607:f8b0:4001:c0b::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC86112DA98 for <ace@ietf.org>; Mon, 25 Jul 2016 18:00:33 -0700 (PDT)
Received: by mail-it0-x229.google.com with SMTP id u186so99396860ita.0 for <ace@ietf.org>; Mon, 25 Jul 2016 18:00:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to; bh=76jsgJsb4oj9AAczEOGNLnI9uFlh03nexlmtk4K9kj4=; b=LtTqhm/VHOwQ3HgN2l/7v42XzgtZ6cNsT+WZOmKdXrmaDUVluM6UOs4uwLuuJ9HkZs 1A/G7iwslNEcd/pVagWy8QdLy2wKVASLr4SZEvV0xd44shGdXRI0WZxVVQsv9eISKCNV tiMK8snWRhz0ezJAjakit1wkki/0P54+fsyOazjYWc5ZqJfOxxF57RHp1+m28peNzFWo oJpfWVlHGGaY0EbY8OSejMsgAf13TJbQG+vOq4Oq7VGOds4KsRX/4khEwJdtBveHEsX0 Y2+mdzXulRRYYPBgyTdCuZaaQEiDDFSSmpnycbWmmUwtuovI7+k97jBtiNr1djPpAAcg XiNw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to; bh=76jsgJsb4oj9AAczEOGNLnI9uFlh03nexlmtk4K9kj4=; b=UPF0oc4UJBvyK0XmTNrk8QXwRRvaomlAePDyNNZPXJ4qSv3CFVYDi79HZd6Tps+0TS GFtclHFjY8qu1l5GWDpXcNxQ7Enz9tfKnB3bn4H+RQnMEHj1deVpqxFnLwS2YMyy9s7s pH6D5Xj23ishimdNFu61UTjNWfGXN5Bdob8Q/dPAY1s1wHpbvdtPMRD0Qj1y9Ex0lanl ByUWW9IdXuCt8aW/buDPxx6Xl46VprlEUzYSaffWSOu/cotRrfBZ5agSMaLLZ7tx7ToD 13H5lKm4hEwdRZRLtAJ49aJ6E4XDm+5cJtvBognIUcrD124JKKh1aGKt7SDnRS8D3+GL R4oQ==
X-Gm-Message-State: ALyK8tJMjrxwPV887jHzT1MG1VISK2zo0QLIShFLwJm6qoklp3XzZEpqt65nAX2W5Mb6Mg==
X-Received: by 10.36.55.2 with SMTP id r2mr92005195itr.73.1469494832158; Mon, 25 Jul 2016 18:00:32 -0700 (PDT)
Received: from [192.168.0.14] (CPE7cb21b2cb904-CM7cb21b2cb901.cpe.net.cable.rogers.com. [174.112.186.144]) by smtp.gmail.com with ESMTPSA id z65sm12597584ioi.28.2016.07.25.18.00.26 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 25 Jul 2016 18:00:31 -0700 (PDT)
To: "Kumar, Sandeep" <sandeep.kumar@philips.com>, Stephen Farrell <stephen.farrell@cs.tcd.ie>, Somaraju Abhinav <abhinav.somaraju@tridonic.com>, Michael StJohns <mstjohns@comcast.net>, "ace@ietf.org" <ace@ietf.org>
References: <578F4D59.8050005@gmx.net> <5E393DF26B791A428E5F003BB6C5342AB3716D64@OC11EXPO33.exchange.mit.edu> <23666.1469091857@obiwan.sandelman.ca> <95b0103c-ba2d-6cd8-6241-228df46e530b@sics.se> <8ca27108-a8b9-7b07-e752-656247716708@comcast.net> <HE1PR0601MB22030003D2913DA6096CB3E4FC0D0@HE1PR0601MB2203.eurprd06.prod.outlook.com> <a318cda7-ebf2-5a5c-d86a-9d67fb41a82f@comcast.net> <HE1PR0601MB2203D1C2C96278B23D71AD31FC0D0@HE1PR0601MB2203.eurprd06.prod.outlook.com> <f293e325-bea2-5c27-c677-563f05c60da0@cs.tcd.ie> <bf8531981ecd4a0db3607f9ef5328d38@VI1PR9003MB0237.MGDPHG.emi.philips.com>
From: Rene Struik <rstruik.ext@gmail.com>
Message-ID: <8bbc028d-0960-3f93-ccc2-e8746fd98ca6@gmail.com>
Date: Mon, 25 Jul 2016 21:00:21 -0400
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0
MIME-Version: 1.0
In-Reply-To: <bf8531981ecd4a0db3607f9ef5328d38@VI1PR9003MB0237.MGDPHG.emi.philips.com>
Content-Type: multipart/alternative; boundary="------------A563B726F58E75ADC544F316"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/iEb0XnAIMAB_V3I8LjMFQRj1Fe0>
Subject: Re: [Ace] Adoption of Low Latency Group Communication Security Work in ACE
X-BeenThere: ace@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" <ace.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ace>, <mailto:ace-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ace/>
List-Post: <mailto:ace@ietf.org>
List-Help: <mailto:ace-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ace>, <mailto:ace-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 26 Jul 2016 01:01:13 -0000

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-bounces@ietf.org] On Behalf Of Stephen Farrell
> Sent: Monday, July 25, 2016 9:26 PM
> To: Somaraju Abhinav; Michael StJohns; 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
> https://www.ietf.org/mailman/listinfo/ace


-- 
email: rstruik.ext@gmail.com | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363