On Fri, Jul 26, 2019 at 12:00:20PM +0300, Ard Biesheuvel wrote: > > For Y and Z, it is not straightforward either: since the crypto API > permits the use of driver names in addition to the plain CRA names, > we'd have to infer from the first parameter which cipher is being > used. We don't really permit that. It might work but it is certainly not guaranteed to work. The only thing we guarantee is that the algorithm name and the canonical driver name will work. For example, with gcm you can either say gcm(aes) or gcm_base(drv_name1, drv_name2). Anything else is not supported. So I would envisage something similar for essiv where essiv just has U, X and Y (as you said that U and X are independent) while you can then have an essiv_base that spells everything out in detail. Also, do we allow anything other than HMAC for X? If not then that should be encoded either into the name by dropping the hmac in the algorithm name and adding it through the driver name, or by checking for it in the template creation function. What I'd like to achieve is a state where we support only what is currently supported and no more. > > Because this is legacy stuff, I don't want it to support any more > > than what is currently being supported by dm-crypt. > > > > Similary for the skcipher case, given > > > > essiv(cbc(X),Y,Z) > > > > is it ever possible for X != Y? If not then we should just make the > > algorithm name essiv(X,Z). > > > > Same problem. We'd need to instantiate the skcipher and parse the cra_name. > > Perhaps we should introduce a crypto API call that infers the cra_name > from a cra_driver_name? You don't need to do that. Just copy whatever gcm does in its creation function when you invoke it as gcm_base. Thanks, -- Email: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
