Re: [Cfrg] Requirements for PAKE schemes

[辛星漢 <[e-mail]>]

Dear Jörn,

Thank you for the document.

Here are some comments:
1. It is somewhat misleading to differ balanced and augmented by a type of password storage in Section 3.1 because in balanced PAKE protocols passwords can be stored as elements generated with a one-way function. As you already wrote in the second paragraph, the difference is whether it is providing KCI or not.

2. In Section 3.3, “~ while the second one proposes a generic construction that allows transferring any two-party PAKE into a GPAKE protocol.”. However, there are other papers to convert 2-party PAKE to group PAKE (e.g., [ACGP11]).
M. Abdalla et al., “Contributory Password-Authenticated Group Key Exchange with Join Capability,”' CT-RSA 2011

Best regards,
Shin

------------------------------------------------------------------------------
SeongHan Shin
Information Technology Research Institute (ITRI),
National Institute of Advanced Industrial Science and Technology (AIST),
8F, AIST Tokyo Waterfront Bio-IT Research Building,
2-4-7 Aomi, Koto-ku, Tokyo, 135-0064, Japan
Tel : [phone]
E-mail : [e-mail]
------------------------------------------------------------------------------

________________________________________
差出人: Cfrg <[e-mail]> が  の代理で送信Schmidt, Jörn-Marc <[e-mail]>
送信日時: 2015年7月7日 16:20
宛先: Paul Lambert; [e-mail]
件名: Re: [Cfrg] Requirements for PAKE schemes

Dear Paul,

Thanks a lot for your feedback.

>Nicely written Š A couple general comments, in section 5 it states:
>"This technique can be used  to parlay a short one-time code, into a
long-lived public key.²
>This seems much more interesting than just setting up shared secrets.
Perhaps it could be included in the MAY comments to help promote the
>addressing of this capability.  A PAKE plus long-lived public key is an
important building block for pairing/setup of devices that use public keys
for authentication.

I'll add a MAY requirement in the next version.


>Where long-lived public keys are used, a requirement should also be added
to discuss the privacy properties of the scheme.

Good point - I'm happy to address privacy in the next version.

Cheers,

Jörn