On Mon, Dec 20, 2021 at 04:27:35PM +0100, Nicolai Stange wrote: > > Just for my understanding: the problem here is having a (single) enum > for the representation of all the possible "known" groups in the first > place or more that the individual group id enum members have hard-coded > values assigned to them each? Yes the fact that you need to have a list of all "known" groups is the issue. > However, after some back and forth, I opted against doing something > similar for dh at the time, because there are quite some more possible > parameter sets than there are for ecdh, namely ten vs. three. If we were I don't understand why we can't support ten or an even larger number of parameter sets. If you are concerned about code duplication then there are ways around that. Or do you have another specific concern in mind with respect to a large number of parameter sets under this scheme? > Anyway, just to make sure I'm getting it right: when you're saying > "template", you mean to implement a crypto_template for instantiating > patterns like "dh(ffdhe2048)", "dh(ffdhe3072)" and so on? The dh(...) > template instantiations would keep a crypto_spawn for referring to the > underlying, non-template "dh" kpp_alg so that "dh" implementations of > higher priority (hpre + qat) would take over once they'd become > available, correct? The template would work in the other dirirection. It would look like ffdhe2048(dh) with dh being implemented in either software or hardware. The template wrapper would simply supply the relevant parameters. Cheers, -- Email: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
