Re: [Cfrg] The SESPAKE protocol and PAKE requirements

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

Dear Jörn,
Thank you for an updated version of the draft – we'll revise it one more
time in a week (a week prior to the deadline marked by Alexey yesterday).

Now I'd like only to mention a small misprint: "Cryptograpic" in reference
[P1363].

Thank you for your work on the draft.

Kindest regards,
Stanislav


2016-02-25 8:39 GMT+03:00 Stanislav V. Smyshlyaev <[e-mail]>:

> Dear Jörn,
> Thank you very much for your comments! SESPAKE will of course work with
> any underlying hash/HMAC/elliptic curve/PBKDF and we’ll prepare a new
> version of our draft which will explicitly stress it.
> I do not insist on addition of any specific words about primitives
> specification in the requirements draft. In contrary to the question with
> counters handling (our previous discussion), I think it is ok if this issue
> will be addressed by any author of a draft at his own discretion.
>
> Kindest regards,
> Stanislav
>
>
> 2016-02-23 9:52 GMT+03:00 Schmidt, Jörn-Marc <
> [e-mail]>:
>
>> Dear Stanislav,
>>
>> Thank you for your input!
>>
>> >What do you think about defining a policy of algorithm usage in PAKE
>> protocols?
>> >For example, in the current version of SESPAKE RFC draft we are based on
>> Russian standards – GOST R 34.11-2012 hash and HMAC, but of course the
>> >document that refers only to GOSTs cannot become a CFRG document.
>>
>> >Shouldn't we require multi-algorithm support – as in the PAKE
>> requirements, as in our SESPAKE?
>>
>> You mean to add a requirement to state which algorithms can be used as
>> underlying primitives?
>> I haven't analyzed SESPAKE in detail - but wouldn't it work with any
>> cryptographic hash function?
>> In case a PAKE requires a special property of the underlying hash
>> function/cipher/etc., I think this could be covered with
>> "R2: A PAKE scheme SHOULD come with a security proof and clearly state
>> its assumptions and models." by adding a sentence about useful primitives.
>>
>> I personally would leave it up to the designer of the PAKE scheme to
>> decide whether the scheme mentions a specific primitive (e.g. is specified
>> using AES & SHA2) or leaves it up to the implementer (e.g. speaking of
>> block cipher & hash function in an abstract manner). Do you think we should
>> push in one direction in the requirements draft?
>>
>> Best regards,
>>
>> Jörn
>>
>>
>>
>>
>