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

From: KATO Akihiro <[email-masked]>
Date: Wed, 27 Apr 2016 18:44:36 +0900

Hi cfrg folks,

We have recently updated three I-Ds related ID-based authenticated key
exchange..

draft-kato-fsu-key-exchange-01.txt
draft-kato-optimal-ate-pairings-01.txt
draft-kasamatsu-bncurves-02.txt

The I-Ds specifies key exchange protocols, pairing algorithm, and pairing
friendly curves respectively.

The main change from -00 to -01 of FSU is added an "Our Motivation"
section that came from a hannes's question on FSU,

Thank you for Hannes Tschofenig and Tadanori Teruya by the on/off-list
comments and questions.

We would appreciate your any technical/editorial comments and suggestions
on our I-Ds and works.

Regards.

KATO, Akihiro

----------------------

A New Internet-Draft is available from the on-line Internet-Drafts
directories.

        Title           : FSU Key Exchange
        Authors         : Akihiro Kato
                          Thomas Hardjono
                          Tetsutaro Kobayashi
                          Tsunekazu Saito
                          Koutarou Suzuki
	Filename        : draft-kato-fsu-key-exchange-01.txt
	Pages           : 26
	Date            : 2016-03-18

Abstract:
   This draft proposes an identity-based authenticated key exchange
   protocol following the extended Canetti-Krawczyk (id-eCK) model.  The
   protocol is currently the most efficient among the id-eCK protocols.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-kato-fsu-key-exchange/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-kato-fsu-key-exchange-01

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-kato-fsu-key-exchange-01

-------

A New Internet-Draft is available from the on-line Internet-Drafts
directories.

        Title           : Optimal Ate Pairing
        Authors         : Akihiro Kato
                          Michael Scott
                          Tetsutaro Kobayashi
                          Yuto Kawahara
	Filename        : draft-kato-optimal-ate-pairings-01.txt
	Pages           : 17
	Date            : 2016-03-18

Abstract:
   Pairing is a special map from two elliptic curve that called Pairing-
   friend curves to a finite field and is useful mathematical tools for
   constructing cryptographic primitives.  It allows us to construct
   powerful primitives. (e.g. [3] and [4])

   There are some types of pairing and its choice has an impact on the
   performance of the primitive.  For example, Tate Pairing [3] and Ate
   Pairing [4] are specified in IETF.  This memo focuses on Optimal Ate
   Pairing [2] which is an improvement of Ate Pairing.

   This memo defines Optimal Ate Pairing for any pairing-friendly curve.
   We can obtain concrete algorithm by deciding parameters and building
   blocks based on the form of a curve and the description in this memo.
   It enables us to reduce the cost for specifying Optimal Ate Pairing
   over additional curves.  Furthermore, this memo provides concrete
   algorithm for Optimal Ate Pairing over BN-curves [7] and its test
   vectors.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-kato-optimal-ate-pairings/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-kato-optimal-ate-pairings-01

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-kato-optimal-ate-pairings-01

--------------------------

A New Internet-Draft is available from the on-line Internet-Drafts
directories.

        Title           : Barreto-Naehrig Curves
        Authors         : Akihiro Kato
                          Michael Scott
                          Tetsutaro Kobayashi
                          Yuto Kawahara
	Filename        : draft-kasamatsu-bncurves-02.txt
	Pages           : 24
	Date            : 2016-03-18

Abstract:
   Elliptic curves with pairings are useful tools for constructing
   cryptographic primitives.  In this memo, we specify domain parameters
   of Barreto-Naehrig curves (BN-curves) [8].  The BN-curve is an
   elliptic curve suitable for pairings and allows us to achieve high
   security and efficiency of cryptographic schemes.  This memo
   specifies domain parameters of four 254-bit BN-curves [1] [2] [5]
   which allow us to obtain efficient implementations.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-kasamatsu-bncurves/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-kasamatsu-bncurves-02

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-kasamatsu-bncurves-02

---

From: Alyssa Rowan <[email-masked]>
Date: Thu, 28 Apr 2016 07:43:28 +0100

On 2016-04-27 10:44, KATO Akihiro wrote:

> We have recently updated three I-Ds related ID-based authenticated
> key exchange..

> The main change from -00 to -01 of FSU is added an "Our
> Motivation" section that came from a hannes's question on FSU,

Thank you: but having read your answer, I still have some difficulty
in understanding why you are endorsing adding manufacturer-centralised
key escrow to the list of security problems embedded devices face?

IBE moves the entire key management issue into one uniquely attractive
target. Within one organisation's LAN, I could perhaps understand; on
any public network, I don't think I could find it fit for use.

- -- 
/akr

---

From: Michael Scott <[email-masked]>
Date: Thu, 28 Apr 2016 09:35:12 +0100

You say "IBE moves the entire key management issue into one uniquely
attractive target."

But it doesn't have to. You should read section 6 ("Distributed PKG") of
the original Boneh & Franklin  IBE paper

https://crypto.stanford.edu/~dabo/papers/bfibe.pdf

I suspect that many commentators are completely unaware of this
possibility, which is trivially easy to implement.

Maybe the more accurate phrase "n uniquely attractive targets" where
n=2,3,4... doesn't carry quite the same punch!

Mike Scott

On Thu, Apr 28, 2016 at 7:43 AM, Alyssa Rowan <[email-masked]> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
> -----BEGIN PGP SIGNATURE-----
>
> iQIcBAEBCgAGBQJXIbEKAAoJEOyEjtkWi2t6ATkQALU9FseflinnBydrZpjV9Utm
> NcL1wF3lChbRu1Zu99Snrbpwh+Lz2d3TjnyTaufJJnrIPiE54MTnVzrjk44+I7B3
> z5FuQHxfo3Rg78je0jyOyLaS5N9YzYMYFexcGY+vu65hyPJmlEmUmxvWvZ7BEl/4
> sfuYeBzTGkONanmqyC0ZLdEhGW1i5hFadyhZP4lSHD4gvpRVf4DUQDNvPJP11y6l
> KKBtWEWXuKr9ExvyYrZ8poPE773yiGdIWVW4Ty/g0RpPWU8CHfbHzCiE1Mrfmfqf
> YUsgdF18FglscBy8hdJx64jWIWQ2Std6Xs9mFse8t9WbAVkpR1C9bele5IFxszN9
> JKyqfsaZJX5agW8t3hNx4u7LK3LB8lTPiXNOxVYan9RjgxYh+nShZ7/2/xacMIwX
> FLNvPVQGG57sKTUc0vOTFGmaoXiaxzEeEGDHLXRJ8yS9fT6PLNQ+OZS1tQwV98F7
> 7YsDTBBfxzFZVni6IwZCcdUFGD+J2C/ZFFKhi+mZsIahibtkmse5vSdDyOa0Ld9r
> qbOE4nKpIOuEQzA6uX4Sko6qbSB8Q7OKWtH8IrHv0/4RjCMN5WBzSlKi59FVu/Vl
> Zo4z2Q9RmtYz41GWa87HYkxPT5cIBWlbSVdMx+8J4gAgKKjqZAyjdwqk76JEkSme
> lhAlPbUz+UrAxEVscZ68
> =Zy18
> -----END PGP SIGNATURE-----
>
> _______________________________________________
> Cfrg mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/cfrg
>

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 28 Apr 2016 10:26:38 +0100

Hi Mike,

> 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.

---

From: Michael Scott <[email-masked]>
Date: Thu, 28 Apr 2016 10:54:07 +0100

Hello Stephen,

On Thu, Apr 28, 2016 at 10:26 AM, Stephen Farrell <[email-masked]
> wrote:

> even if it looks like N things.

Well I guess you would have to take care not to do it like that!

Mike

---

From: KATO Akihiro <[email-masked]>
Date: Thu, 28 Apr 2016 18:58:45 +0900

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.

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 28 Apr 2016 11:01:46 +0100

Hiya,

> Well I guess you would have to take care not to do it like that!

Easier said than done these days though.

And aside from crypto, collusion, coercion and all of that,
it's just way way harder to deploy some application that
depends on a currently non-existent infrastructure which we'd
like to be provided by independent entities.

For all their faults, we have the web PKI and DNS and I
guess BTC has the blockchain. If IBE depends on another
similar piece of infrastructure being created then I
reckon that's another nail in the coffin. (My belief is
that such bits of infrastructure only get created when
many stars align, and is basically unpredictable.)

For me, it's kinda like PAKEs - really cool math, but
the overall system benefit is nowhere near as cool.

S.

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 28 Apr 2016 11:06:05 +0100

> There is no key escrow on FSU key exchange.

Eh? Doesn't slide 4 show that the KGC can fake anyone since
it generates their secret keys? That's close enough to mandatory
key escrow for me though sure, perhaps a better term for the
KGC rules-them-all would have been better:-)

S.

---

From: KATO Akihiro <[email-masked]>
Date: Thu, 28 Apr 2016 19:17:45 +0900

Hi Stephen,

Slide 4 shows generic case on IBE scheme. After "FSU Key Exchange 
Protocol" slide shows FSU key exchange specific. We made the FSU protocol 
that care about the protection of the session key very much.

Regards.

---

From: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Thu, 28 Apr 2016 14:36:35 +0000

I agree with Alyssa and Stephen.
-- 
Regards,
Uri Blumenthal