Re: [Cfrg] I updated 3 drafts related to a FSU KeyEX

KATO Akihiro <kato.akihiro@po.ntts.co.jp> Thu, 28 April 2016 09:59 UTC

Return-Path: <kato.akihiro@po.ntts.co.jp>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8C0A12D0E9 for <cfrg@ietfa.amsl.com>; Thu, 28 Apr 2016 02:59:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.897
X-Spam-Level:
X-Spam-Status: No, score=-2.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 l6GvWooMCN4S for <cfrg@ietfa.amsl.com>; Thu, 28 Apr 2016 02:59:09 -0700 (PDT)
Received: from mail12.ics.ntts.co.jp (mail12.ics.ntts.co.jp [210.232.35.65]) by ietfa.amsl.com (Postfix) with ESMTP id 0EA8D12B010 for <cfrg@irtf.org>; Thu, 28 Apr 2016 02:59:08 -0700 (PDT)
Received: from sadoku34.silk.ntts.co.jp (sadoku34 [10.7.18.34]) by mail12.ics.ntts.co.jp (unknown) with ESMTP id u3S9x5H3023649; Thu, 28 Apr 2016 18:59:05 +0900 (JST)
Received: (from root@localhost) by sadoku34.silk.ntts.co.jp (unknown) id u3S9x5ki015437; Thu, 28 Apr 2016 18:59:05 +0900 (JST)
Received: from unknown [10.107.0.33] by sadoku34.silk.ntts.co.jp with SMTP id UAA15436; Thu, 28 Apr 2016 18:59:05 +0900
Received: from mail137.silk.ntts.co.jp (ccmds33.silk.ntts.co.jp [127.0.0.1]) by ccmds33.silk.ntts.co.jp (unknown) with ESMTP id u3S9x5Xx016383; Thu, 28 Apr 2016 18:59:05 +0900
Received: from mail137.silk.ntts.co.jp (localhost [127.0.0.1]) by mail137.silk.ntts.co.jp (unknown) with ESMTP id u3S9x5T1016239; Thu, 28 Apr 2016 18:59:05 +0900
Received: from ccmds33 ([10.107.0.135]) by mail137.silk.ntts.co.jp (unknown) with SMTP id u3S9x5uf016236; Thu, 28 Apr 2016 18:59:05 +0900
From: KATO Akihiro <kato.akihiro@po.ntts.co.jp>
References: <57208A04.4070804@po.ntts.co.jp> <7a3f5420-db18-496b-af32-e490bf6d0d80@akr.io> <CAEseHRqYNGhGaA+8HhUFDNxLc2WU=5GJf+om52RRuWwtEHUhmg@mail.gmail.com> <5721D74E.3010407@cs.tcd.ie>
Message-ID: <5721DED5.8090608@po.ntts.co.jp>
Date: Thu, 28 Apr 2016 18:58:45 +0900
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2
MIME-Version: 1.0
In-Reply-To: <5721D74E.3010407@cs.tcd.ie>
Content-Type: text/plain; charset="iso-2022-jp"
Content-Transfer-Encoding: 7bit
X-CC-Mail-RelayStamp: CC-Mail-V4.3-Client
X-CC-Mail-RelayStamp: CC-Mail-V5.2.1-Client-Relayed
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>, Michael Scott <mike.scott@miracl.com>, "cfrg@irtf.org" <cfrg@irtf.org>
X-TM-AS-MML: No
X-CC-Mail-RelayStamp: CC-Mail-V4.3-Server
Archived-At: <http://mailarchive.ietf.org/arch/msg/cfrg/MbiGPE95CGVkd12yjkgbcHfkU_o>
Subject: Re: [Cfrg] I updated 3 drafts related to a FSU KeyEX
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/cfrg>, <mailto:cfrg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cfrg/>
List-Post: <mailto:cfrg@irtf.org>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Thu, 28 Apr 2016 09:59:12 -0000

Hi Stephen,

At FSU case, the KGC cannot get session key.

Look the page 7 and 8 of
https://www.ietf.org/proceedings/94/slides/slides-94-cfrg-0.pdf . The
session key encrypted ephemeral public key. If the KGC have all static
secret key, that cannot see session key and plain text.

There is no key escrow on FSU key exchange.

Regards.

On 2016/04/28 18:26, Stephen Farrell wrote:
>
> Hi Mike,
>
> On 28/04/16 09:35, Michael Scott wrote:
>> Maybe the more accurate phrase "n uniquely attractive targets" where
>> n=2,3,4... doesn't carry quite the same punch!
>
> I'm sorry, but for me, it does have exactly the same
> punch. If there are key generators, they can collude
> or be coerced. Or even more likely, in a realistic
> commercial Internet-scale deployment, it's quite likely
> all of them (even if operated by different entities)
> may be running on one or two mega-hosting platform,
> so there may well be only one thing to break into
> even if it looks like N things.
>
>  From my POV, the mandatory key escrow aspect of IBE
> is basically fatal for all but possibly some small
> set of niche applications.
>
> Cheers,
> S.
>
>
>
>
> _______________________________________________
> Cfrg mailing list
> Cfrg@irtf.org
> https://www.irtf.org/mailman/listinfo/cfrg
>