Re: [Cfrg] The SESPAKE protocol and PAKE requirements

[Schmidt, Jörn-Marc <[e-mail]>]

Hi Stanislav,

I think I got your point: it's necessary to explicitly point out what to proof, right?

What about adding something like "In particular, the proof must show that (1) a passive adversary cannot learn anything about the password by eavesdropping a key agreement and (2) the probability of an active adversary to succeed is limited by the number of guesses divided by the password-length." after the last sentence ("[...]assumptions and used models.")?

Best regards,

Jörn

-----Ursprüngliche Nachricht-----
Von: Станислав Смышляев [mailto:[e-mail]] 
Gesendet: Dienstag, 26. April 2016 16:41
An: Schmidt, Jörn-Marc
Cc: [e-mail]
Betreff: Re: The SESPAKE protocol and PAKE requirements

‎Dear Jorn,

Thank you very much for your response.

That's my point: Eve obviously can always guess the password with a nonzero probability, but that doesn't mean that we do not need to address false authentication attacks at all - this only means that it has to be proven that for a certain PAKE protocol the probability of Eve's false authentication has the form of q/|D| + \nu(n), where D is the password set, n is the security parameter, q is the limit of trials (online) and \nu(n) is negligible if all used primitives are strong. ‎

A proof of a statement of this kind is crucial to evaluate the real security (in fact, probability of a false authentication or obtaining some info about a key) for a specific allowed limit of trials, password length and alphabet and adversary resources. 

‎Thus I think it is important to specify that the PAKE proposal must have a clear (and proven) security evaluation (kind of "Pr <= q/|D| + \nu(n)" ) for threats of 1) key distinguishing and 2) false authentication. 
‎
Best regards,
Stanislav‎
  Исходное сообщение  
От: Schmidt, Jörn-Marc
Отправлено: вторник, 26 апреля 2016 г., 15:22
Кому: Stanislav V. Smyshlyaev
Копия: [e-mail]
Тема: AW: The SESPAKE protocol and PAKE requirements

Hi Stanislav,

thank you for reviewing the document and your feedback. 


>Maybe it will be helpful to add in Section 4 (after it is stressed that "PAKE scheme should come with a security proof and also clearly state its assumptions and used models"), which threats are most relevant (and >thus which threats must be addressed in adversary models considered in secutiy proofs)? For instance, a threat of distinguishing a key from a random string and a threat of false authentication.


I'm not completely sure how to address this. My understanding of a proof for a PAKE scheme is that Eve must not learn more than that there was a key agreement when listening to one. In case she hits the password by guessing, she wins - that's something you cannot prevent. I tried to describe this in the Section 4: 
"That is, if Eve is unable to take information from a passive attack or a single active attack and enumerate through her dictionary then the only attack left is repeated guessing attacks. Eve learns one thing from a single active attack: whether her single guess is correct or not. In other words, the security of a PAKE scheme is based on the idea that Eve, who is trying to impersonate Alice cannot efficiently verify a password guess without interacting with Bob (or Alice) and hence is detected. "

Do you have a suggestion how to improve this section to underline specific threats? 

Best regards,


Jörn