Re: [Ace] Group Communication Security Disagreements
Derek Atkins <derek@ihtfp.com> Thu, 28 July 2016 15:31 UTC
Return-Path: <derek@ihtfp.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 BCC7912D866 for <ace@ietfa.amsl.com>; Thu, 28 Jul 2016 08:31:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ihtfp.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 3yv65bKHKBjX for <ace@ietfa.amsl.com>; Thu, 28 Jul 2016 08:31:20 -0700 (PDT)
Received: from mail2.ihtfp.org (MAIL2.IHTFP.ORG [204.107.200.7]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D92112D847 for <ace@ietf.org>; Thu, 28 Jul 2016 08:31:20 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id B6BE7E2030; Thu, 28 Jul 2016 11:30:48 -0400 (EDT)
Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 22593-05; Thu, 28 Jul 2016 11:30:40 -0400 (EDT)
Received: from securerf.ihtfp.org (IHTFP-DHCP-159.IHTFP.ORG [192.168.248.159]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mocana.ihtfp.org", Issuer "IHTFP Consulting Certification Authority" (verified OK)) by mail2.ihtfp.org (Postfix) with ESMTPS id C32C1E200A; Thu, 28 Jul 2016 11:30:39 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ihtfp.com; s=default; t=1469719839; bh=Tojtj2bJfxQ6umPwEglgikUfKfrQOko51nuILCCsXJ8=; h=From:To:Cc:Subject:References:Date:In-Reply-To; b=T09Z5PjyAvgipyqEj3MhOZL8Tr72gh7Q0nm0MP85kD07Z1rCdgY97Y6aUwGR1L6wv ngwLLyZqD/GB+ZE5cB43Iu0XKAycjWSyBlRVuau03frOTNEVn6gO9wupIlyIkwQLAF +hkJSrXA3gEoekYJX8IYjvTjzO3xOH39+wcUb58I=
Received: (from warlord@localhost) by securerf.ihtfp.org (8.15.2/8.14.8/Submit) id u6SFUZlP014103; Thu, 28 Jul 2016 11:30:35 -0400
From: Derek Atkins <derek@ihtfp.com>
To: "Grunwald, Markus" <M.Grunwald@osram.com>
References: <57909032.10809@gmx.net> <6d259c5b-28e3-c748-4590-0c9f942fe343@comcast.net> <378a0359-6b31-a30c-af28-8ea567b06b00@cisco.com> <57963480.2000809@gmx.net> <0d4c6d56-ebb5-2f43-d555-29c336396033@ericsson.com> <15169.1469642303@obiwan.sandelman.ca> <CAHbuEH4u=AF1LSoDq+YfLwt+VX1OOrj54331GuZmyjLswHvNnw@mail.gmail.com> <3271.1469656595@obiwan.sandelman.ca> <32aa7104-70df-80c7-8d6e-537b66716de9@comcast.net> <4D6B5484A4456C4684818BBF9B04AC2133162F8ECB@EXC-MCHMBX33.mch.osram.de>
Date: Thu, 28 Jul 2016 11:30:35 -0400
In-Reply-To: <4D6B5484A4456C4684818BBF9B04AC2133162F8ECB@EXC-MCHMBX33.mch.osram.de> (Markus Grunwald's message of "Thu, 28 Jul 2016 15:14:25 +0200")
Message-ID: <sjmk2g54w6c.fsf@securerf.ihtfp.org>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Virus-Scanned: Maia Mailguard 1.0.2a
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/MB4HwjFfgRt405ffmsXR7e9V5Go>
Cc: "ace@ietf.org" <ace@ietf.org>
Subject: Re: [Ace] Group Communication Security Disagreements
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: Thu, 28 Jul 2016 15:31:22 -0000
Hi,
"Grunwald, Markus" <M.Grunwald@osram.com> writes:
> - How are applications handled that are not able to provide private/
> public key encryption?
>
> I may (most possibly) have missed something, but the only answer that you seem
> to accept is “public key encryption”, period. Then let me ask directly: how
> should systems that have to reply in a tight margin be handled? People will
> simply not buy a lighting solution where the light will switch on 500ms after
> you pressed the switch. They will lough at this “solution”.
True, but there are other public-key games in town.
> So, throw more hardware at it? For light switches that cost €100, adding a
> crypto chip for ¢50 might not be a problem. But there are parts like ECG where
> ¢2 matter. One of them will be in every luminaire…
Indeed. Cost is an important characteristic. On the other hand it's
definitely not going to come for free. So where is the cost/benefit
curve cross over?
> This means, there are systems that cannot afford to provide public key
> encryption. Do you want an IoT without light? Let’s not bow to the
> “discrimination of the light switch”, at least not for the parking house/
> parking lot. An Airport is a different beast.
For the record, I've been working on a group theoretic public-key
signature scheme that's looking very promising. It's designed to run
extremely efficiently in these extremely constrained devices. In our
tests so far signature verification is 1-2 orders of magnitude faster
than ECDSA verification, and runs extremely well in 8, 16, and 32-bit
environments. For example, on an ARM Cortex-M3 the verification runs in
under 10ms. (I believe Hannes was reporting 200-400ms for ECDSA
verification). Something to keep in mind when thinking about how hard
it is to work with public key signature verification on these devices.
-derek
--
Derek Atkins 617-623-3745
derek@ihtfp.com www.ihtfp.com
Computer and Internet Security Consultant
- Re: [Ace] Group Communication Security Disagreeme… Michael Richardson
- Re: [Ace] Group Communication Security Disagreeme… Mohit Sethi
- Re: [Ace] Group Communication Security Disagreeme… Hannes Tschofenig
- Re: [Ace] Group Communication Security Disagreeme… Mohit Sethi
- Re: [Ace] Group Communication Security Disagreeme… Eliot Lear
- Re: [Ace] Group Communication Security Disagreeme… Hannes Tschofenig
- Re: [Ace] Group Communication Security Disagreeme… Eliot Lear
- Re: [Ace] Group Communication Security Disagreeme… Hannes Tschofenig
- Re: [Ace] Group Communication Security Disagreeme… Derek Atkins
- Re: [Ace] Group Communication Security Disagreeme… Eliot Lear
- Re: [Ace] Group Communication Security Disagreeme… Michael StJohns
- [Ace] (on signature verification times) Re: Group… Rene Struik
- [Ace] Group Communication Security Disagreements Hannes Tschofenig
- Re: [Ace] Group Communication Security Disagreeme… Derek Atkins
- Re: [Ace] Group Communication Security Disagreeme… Eliot Lear
- Re: [Ace] Group Communication Security Disagreeme… Paul Duffy
- Re: [Ace] Group Communication Security Disagreeme… Michael Richardson
- Re: [Ace] Group Communication Security Disagreeme… Grunwald, Markus
- Re: [Ace] Group Communication Security Disagreeme… Michael StJohns
- Re: [Ace] Group Communication Security Disagreeme… Michael Richardson
- Re: [Ace] Group Communication Security Disagreeme… Kathleen Moriarty
- Re: [Ace] Group Communication Security Disagreeme… Michael StJohns
- Re: [Ace] Group Communication Security Disagreeme… Ludwig Seitz
- Re: [Ace] Group Communication Security Disagreeme… Eliot Lear
- Re: [Ace] Group Communication Security Disagreeme… Somaraju Abhinav
- Re: [Ace] Group Communication Security Disagreeme… Eliot Lear
- Re: [Ace] Group Communication Security Disagreeme… Michael StJohns
- Re: [Ace] Group Communication Security Disagreeme… Eliot Lear
- Re: [Ace] Group Communication Security Disagreeme… Michael StJohns