Re: [Cfrg] [MASSMAIL]Re: Requirements for PAKE schemes

["Grigory Marshalko" <[e-mail]>]

Hi, for these heuristics we can use approaches like fuzzy extractors and the corresponding theory in order to determine corresponding limitations. But this of cause would require training phases.

Regards,
Grigory Marshalko,
expert,
Technical committee for standardisation "Cryptography and security mechanisms" (ТC 26)
www.tc26.ru

28 января 2016 г., 21:10, "Mike Hamburg"  написал:

Hello Dr Smyshlyaev,

It's worth noting that in many systems, the risk of DoS weighs against the risk of password guessing. The designers of these systems may not find it acceptable to hard lock an account based on a global count of attempts, especially if most of their adversaries are not powerful. For example, eBay doesn't want people to lock out the accounts of their competitors just by trying 10 times to log in.  In these systems, heuristics are used (based eg on IP, CAPTCHAs or browser metrics) to deter guessing.  The same sort of work is applicable to PAKE systems. So I don't think brute force prevention will be so one-size-fits-all. 

Cheers,
-- Mike

Sent from my phone.  Please excuse brevity and typos.

On Jan 28, 2016, at 02:59, Stanislav V. Smyshlyaev  wrote:
  

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
 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] (mailto:[e-mail]) ------------------------------------------------------------------------------

 
_______________________________________________
Cfrg mailing list
[e-mail] (mailto:[e-mail])
https://www.irtf.org/mailman/listinfo/cfrg (https://www.irtf.org/mailman/listinfo/cfrg)