[Question] AEAD crypto api for userspace can't deal with a PTlen=0 vector

[Question] AEAD crypto api for userspace can't deal with a PTlen=0 vector

[Yao Dongdong]

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

Re: [Question] AEAD crypto api for userspace can't deal with a PTlen=0 vector

[Stephan Mueller]

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

Re: [Question] AEAD crypto api for userspace can't deal with a PTlen=0 vector

[Yao Dongdong]

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

Re: [Question] AEAD crypto api for userspace can't deal with a PTlen=0 vector

[Herbert Xu]

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 <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: [Question] AEAD crypto api for userspace can't deal with a PTlen=0 vector

[Herbert Xu]

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 <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: [Question] AEAD crypto api for userspace can't deal with a PTlen=0 vector

[Stephan Mueller]

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

Re: [Question] AEAD crypto api for userspace can't deal with a PTlen=0 vector

[Yao Dongdong]

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