Re: [Cfrg] The SESPAKE protocol and PAKE requirements

["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
>
>
>
>