On Fri, 2 Aug 2019 at 06:55, Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx> wrote: > > 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. > Understood. But that is not the problem. The problem is that we want to instantiate a cipher based on the cipher algorithm that is encapsulated by the skcipher, and how that is encoded in the name is not straightforward. To use your GCM analogy: gcm_base(ctr-ppc-spe, ghash-generic) is a supported aead identifier, but there is nothing in the name that identifies the skcipher as one that encapsulates AES. > 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. > That might be a useful enhancement by itself, but it does not fix the issue above. The only way to instantiate the same cipher as the one encapsulated by "cbc-ppc-spe" is to instantiate the latter, parse the cipher name and pass it to crypto_alloc_cipher() > 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. > Yeah, that makes sense. But we have h/w drivers that instantiate authenc(X,Y) in its entirety, and passing those driver names is something that is supported today, so we can't just remove that. > > > 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 -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
