SRP needs an EVP API

[richsalz]

3.0 deprecated the SRP API (#14132). This issue is to remind the project that an EVP API needs to be written to replace that code.

[ntwerdochlib]

Curious if a decision has been (or close to being) made regarding the SRP EVP API? Is anyone actively working on it? I use the SRP functionality within libcrypto, and I need to decide if I need to rewrite my code if this functionality is slated for removal.

[mattcaswell]

There is no one actively working on this at the moment.

[ntwerdochlib]

I am interested in taking this on, provided it is something that you would feel comfortable with someone new to this project implementing. I have looking for some documentation around guidelines/design for the EVP API. Is there something you know of I could refer too? I suppose it could be sorted out through PR iterations as well.

[mattcaswell]

I would recommend starting with a design document to outline what you have in mind, e.g. something along the lines of this:

#21443

It is likely that the OTC (OpenSSL Technical Committee) would want to take a look at/discuss the design (and even agree that this is a sensible thing to want to do at all).

I do wonder whether it could be made to fit the existing key exchange APIs or as an extension to them - or do PAKEs need something entirely new:

https://www.openssl.org/docs/manmaster/man3/EVP_PKEY_derive_init_ex.html

IMO, from an EVP API perspective the design of an API should be considered in terms of a more generic PAKE perspective rather than SRP in particular.

Also to be considered would be the equivalent provider interface. E.g. here's the documentation for the key exchange interface:

https://www.openssl.org/docs/manmaster/man7/provider-keyexch.html

[ntwerdochlib]

Thank you. I will review the information you provided and get back with you.

[mattcaswell]

One other thought...it could be that the API may be closer to the existing KDF API rather than the key exchange one:

https://www.openssl.org/docs/manmaster/man3/EVP_KDF_derive.html

[slontis]

The RFC appears to use SHA1 which is not ideal.

[ntwerdochlib]

I am going to first approach this as a PAKE EVP API, seeing if it can be generalized to support all/most of the PAKE offerings.

In regards to the use of SHA1 in SRP, my assumption (i.e. not scientific) is that it must not be a critical point in the overall design, or the authors would have updated it to use SAH2 by now?

[paulidale]

It doesn't look all that close to the KDF API. It's got many more steps e.g.