Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx> writes: > 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. Ok, understood. Thanks for the clarification. >> 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. There's no real reason. I just didn't dare to promote what I considered mere input parameter sets to full-fledged crypto_alg instances with their associated overhead each: - the global crypto_alg_list will get longer, which might have an impact on the lookup searches, - every ffdheXYZ(dh) template instance will need to have individual TVs associated with it. However, I take it as that's fine and I'd be more than happy to implement the ffhdheXYZ(dh) template approach you suggested in a v3. > > 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. Makes sense. Thanks! Nicolai -- SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany (HRB 36809, AG Nürnberg), GF: Ivo Totev
