Am Mittwoch, 15. Februar 2017, 12:02:43 CET schrieb Herbert Xu: Hi Herbert, > Stephan Müller <smueller@xxxxxxxxxx> wrote: > > Hi, > > > > The Qualcomm QCE driver implementation defines: > > .flags = QCE_ALG_AES | QCE_MODE_XTS, > > .name = "xts(aes)", > > .drv_name = "xts-aes-qce", > > .blocksize = AES_BLOCK_SIZE, > > .ivsize = AES_BLOCK_SIZE, > > .min_keysize = AES_MIN_KEY_SIZE, > > .max_keysize = AES_MAX_KEY_SIZE, > > > > and > > > > alg->cra_ablkcipher.min_keysize = def->min_keysize; > > alg->cra_ablkcipher.max_keysize = def->max_keysize; > > alg->cra_ablkcipher.setkey = qce_ablkcipher_setkey; > > > > Thus, this driver has the limits of 128 to 256 bits for the key. > > Furthermore, the common setkey function is used. > > > > May I ask how the key for AES XTS is supposed to be handled here > > considering that the kernel crypto API expects that the AES key and the > > tweak key is set via one setkey call. I.e. the setkey should expect 256 > > through 512 bits. > If the hardware doesn't support it then it needs to be handled with > a fallback. Shouldn't testmgr catch this though? It should be caught there because there are test vectors with a klen of 64 bytes. Thus, the setkey should fail. Ciao Stephan
