Skip to contentSkip to conversation

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

Question Yao Dongdong 3 participants 7 messages May 7, 2015 – May 11, 2015 Crypto API

lore
Share & tools
lore

Yao Dongdong

author
#0 lore raw

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?

Signature · 2 lines
Kind regards,
Yao Dongdong
#1 lore raw

Am Donnerstag, 7. Mai 2015, 17:44:53 schrieb Yao Dongdong:

Hi Yao,

Quoted 38 lines

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);
}
Quoted 3 lines

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

author
#2 lore raw
Quoted 49 lines · Stephan Mueller

Am Donnerstag, 7. Mai 2015, 17:44:53 schrieb Yao Dongdong:

Hi Yao,

Quoted 38 lines

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);
}
Quoted 3 lines

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.

Quoted 5 lines

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.

Quoted 6 lines

Ciao
Stephan

.

Signature · 2 lines
Kind regards,
Yao Dongdong
maintainer
#3 lore raw
In reply to Stephan Mueller
Quoted 4 lines · Stephan Mueller

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,

Signature · 3 lines
Email: Herbert Xu <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
maintainer
#4 lore raw
In reply to Yao Dongdong
Quoted 38 lines · 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);
}
Quoted 3 lines

So it directly return before calling aes-gcm decrypt.

How can we deal with that?

Does this still happen if you use recvmsg?

Cheers,

Signature · 3 lines
Email: Herbert Xu <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
#5 lore raw

Am Montag, 11. Mai 2015, 14:35:09 schrieb Herbert Xu:

Hi Herbert,

Quoted 47 lines · Yao Dongdong
Quoted 46 lines

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);
Quoted 7 lines
Quoted 5 lines

}

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.

Quoted 2 lines

Cheers,

Ciao
Stephan

author
#6 lore raw
In reply to Herbert Xu
Quoted 39 lines · Herbert Xu
Quoted 38 lines · 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);
}
Quoted 4 lines
Quoted 3 lines

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.

Quoted 1 line

Cheers,

Signature · 2 lines
Kind regards,
Yao Dongdong