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?
--
Kind regards,
Yao Dongdong
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
On 2015/5/7 19:28, Stephan Mueller wrote:
> 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.
Thanks for your replay and we will modify our treatment based on your suggestions.
>
> Ciao
> Stephan
>
> .
>
--
Kind regards,
Yao Dongdong
On Thu, May 07, 2015 at 05:44:53PM +0800, Yao Dongdong wrote:
> 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?
Does this still happen if you use recvmsg?
Cheers,
--
Email: Herbert Xu <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
On Thu, May 07, 2015 at 01:28:14PM +0200, Stephan Mueller wrote:
>
> 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.
No we should definitely be able to support this case. However,
we don't have to do it through read(2).
Cheers,
--
Email: Herbert Xu <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Am Montag, 11. Mai 2015, 14:35:09 schrieb Herbert Xu:
Hi Herbert,
>On Thu, May 07, 2015 at 05:44:53PM +0800, Yao Dongdong wrote:
>> 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?
>
>Does this still happen if you use recvmsg?
Indeed, this works.
>
>Cheers,
Ciao
Stephan
On 2015/5/11 14:35, Herbert Xu wrote:
> On Thu, May 07, 2015 at 05:44:53PM +0800, Yao Dongdong wrote:
>> 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?
> Does this still happen if you use recvmsg?
Yes, it works.
> Cheers,
--
Kind regards,
Yao Dongdong