Am Donnerstag, 7. Mai 2015, 17:44:53 schrieb Yao Dongdong:
Hi Yao,
>while we use crypto api for userspace to do vectors test for AEAD(aes-gcm),
>we encounter a problem. There are some test vector's PTlen is 0,for example:
>[Keylen = 128]
>[IVlen = 96]
>[PTlen = 0]
>[AADlen = 0]
>[Taglen = 128]
>
>Count = 0
>Key = 7e93936b2e2188cfa9c9882ad901312f
>IV = b6879804163b9eaf5bfe5218
>CT =
>AAD =
>Tag = aa77daf382d0d63480ff8c8a2dee149e
>
>In testing vectors like that, we will get an error result that the decrypt
>return is success but the right return is a ghash verify fail.
>After digging into the kernel(3.10) code, we find the function sock_aio_read
>in net/socket.c has a judgement of iocb->ki_left which will be 0 when we
>do an aes-gcm decrypt decribed above.
>
>static ssize_t sock_aio_read(struct kiocb *iocb, const struct iovec *iov,
> unsigned long nr_segs, loff_t pos)
>{
> struct sock_iocb siocb, *x;
>
> if (pos != 0)
> return -ESPIPE;
>
> if (iocb->ki_left == 0) /* Match SYS5 behaviour */
> return 0;
>
> x = alloc_sock_iocb(iocb, &siocb);
> if (!x)
> return -ENOMEM;
> return do_sock_read(&x->async_msg, iocb, iocb->ki_filp, iov, nr_segs);
>}
>
>So it directly return before calling aes-gcm decrypt.
>
>How can we deal with that?
You cannot. Currently, the interface is not intended to handle such specific
CAVS conditions (zero CT and AAD). Note, this test effectively only validates
GHASH.
In any case, if you need to perform CAVS testing, you will only be able to do
that with a kernel module for all obscure operations CAVS requests (not only
for AEAD, but also for RNGs).
Or you restrict your usage (and thus the CAVS testing) to CT/AAD lengths > 0.
Ciao
Stephan
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
