Re: [Cfrg] Requirements for PAKE schemes

["Stanislav V. Smyshlyaev" <[e-mail]>]

Good afternoon!

The order of most security bounds of PAKE protocols is determined by the
value  $q{send}/|D|$, where $D$ is a size of a password set and $q_{send}$
is a number of the adversary’s active impacts on the channel. The active
impact assumes that the adversary can intercept a data in the channel and
change it. A PAKE protocol is secure if a little number of such impacts
cannot lead to the adversary’s success for some threat. It means that for
the secure protocol any active impact leads to the fail abortion of the
protocol. The bounds of the security can be reflected in the particular
values if there are limitations for the value $q_{send}$.  In practice it
can be achieved with counters that limit the number of unsuccessful
authentication attempts. These limitations are the essential part of the
protocol as they define the final security. For example, their absence
leads to the vulnerability of the protocol to the online password brute
force attack.

So we think that it is of highly importance to add the following
requirement: the description of the protocol of the PAKE type MUST include
the limitations and detailed description of the following counters:
-          counters of the fail connections in a row,
-          counters of the fail connections for the particular password,
-          counters of the total connections (successful and unsuccessful)
for the current password.


Best regards,
Stanislav V. Smyshlyaev, Ph.D.,
Head of Information Security Department,
CryptoPro LLC


<[e-mail]> wrote:

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