linux-crypto.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* IV generation in cryptographic driver in AEAD
@ 2016-05-18 12:06 Denis B
  2016-05-18 13:56 ` Catalin Vasile
  2016-05-18 17:58 ` Stephan Mueller
  0 siblings, 2 replies; 11+ messages in thread
From: Denis B @ 2016-05-18 12:06 UTC (permalink / raw)
  To: linux-crypto

Hello,

In AEAD mode (or in any case, in IPSec ESP IPv4 – esp4.c), in kernel
versions prior to 4.2 the cryptographic driver is expected to generate
an IV.

What if my driver is unable to generate an IV?

Thanks,
Dennis.

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: IV generation in cryptographic driver in AEAD
  2016-05-18 12:06 IV generation in cryptographic driver in AEAD Denis B
@ 2016-05-18 13:56 ` Catalin Vasile
  2016-05-18 14:21   ` Denis B
  2016-05-18 17:58 ` Stephan Mueller
  1 sibling, 1 reply; 11+ messages in thread
From: Catalin Vasile @ 2016-05-18 13:56 UTC (permalink / raw)
  To: Denis B, linux-crypto@vger.kernel.org

Inline comments.

________________________________________
From: linux-crypto-owner@vger.kernel.org <linux-crypto-owner@vger.kernel.org> on behalf of Denis B <begun.denis@gmail.com>
Sent: Wednesday, May 18, 2016 3:06 PM
To: linux-crypto@vger.kernel.org
Subject: IV generation in cryptographic driver in AEAD

Hello,

In AEAD mode (or in any case, in IPSec ESP IPv4 – esp4.c), in kernel
versions prior to 4.2 the cryptographic driver is expected to generate
an IV.

What if my driver is unable to generate an IV?
[Catalin Vasile]
Simple: You do not implement the givcrypt() primitive. The kernel will generate the IV in software and then call your encrypt() primitive.

Thanks,
Dennis.
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: IV generation in cryptographic driver in AEAD
  2016-05-18 13:56 ` Catalin Vasile
@ 2016-05-18 14:21   ` Denis B
  2016-05-19  2:43     ` Herbert Xu
  2016-05-19  6:44     ` Catalin Vasile
  0 siblings, 2 replies; 11+ messages in thread
From: Denis B @ 2016-05-18 14:21 UTC (permalink / raw)
  To: Catalin Vasile; +Cc: linux-crypto@vger.kernel.org

Forgive my dumbness, but in:

      .cra_type = &crypto_aead_type,
      .cra_u = {
            .aead = {
                .setkey = pp_crypto_aead_setkey,
                .setauthsize = pp_crypto_aead_setauthsize,
                .decrypt = pp_crypto_aead_dec,
                .encrypt = pp_crypto_aead_enc,
                .givencrypt = pp_crypto_aead_genivencrypt,
                .givdecrypt = pp_crypto_aead_genivdecrypt,
                .ivsize = AES_BLOCK_SIZE,
                .maxauthsize = SHA256_DIGEST_SIZE,
            },
      },

Just delete the givencrypt and givdecrypt lines (or set to NULL)?

On Wed, May 18, 2016 at 4:56 PM, Catalin Vasile <cata.vasile@nxp.com> wrote:
> Inline comments.
>
> ________________________________________
> From: linux-crypto-owner@vger.kernel.org <linux-crypto-owner@vger.kernel.org> on behalf of Denis B <begun.denis@gmail.com>
> Sent: Wednesday, May 18, 2016 3:06 PM
> To: linux-crypto@vger.kernel.org
> Subject: IV generation in cryptographic driver in AEAD
>
> Hello,
>
> In AEAD mode (or in any case, in IPSec ESP IPv4 – esp4.c), in kernel
> versions prior to 4.2 the cryptographic driver is expected to generate
> an IV.
>
> What if my driver is unable to generate an IV?
> [Catalin Vasile]
> Simple: You do not implement the givcrypt() primitive. The kernel will generate the IV in software and then call your encrypt() primitive.
>
> Thanks,
> Dennis.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: IV generation in cryptographic driver in AEAD
  2016-05-18 12:06 IV generation in cryptographic driver in AEAD Denis B
  2016-05-18 13:56 ` Catalin Vasile
@ 2016-05-18 17:58 ` Stephan Mueller
  1 sibling, 0 replies; 11+ messages in thread
From: Stephan Mueller @ 2016-05-18 17:58 UTC (permalink / raw)
  To: Denis B; +Cc: linux-crypto

Am Mittwoch, 18. Mai 2016, 15:06:19 schrieb Denis B:

Hi Denis,

> Hello,
> 
> In AEAD mode (or in any case, in IPSec ESP IPv4 – esp4.c), in kernel
> versions prior to 4.2 the cryptographic driver is expected to generate
> an IV.

The driver is not expected to generate the IV. Please see the ASCII art at 
[1]. The IV generation is done with the seqiv component. So, you driver can 
implement all of the logic of GCM, but pull the IV generation from the C 
implementation provided by the kernel crypto API.

[1] http://www.chronox.de/crypto-API/ch02s07.html
> 
> What if my driver is unable to generate an IV?
> 
> Thanks,
> Dennis.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


Ciao
Stephan

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: IV generation in cryptographic driver in AEAD
  2016-05-18 14:21   ` Denis B
@ 2016-05-19  2:43     ` Herbert Xu
  2016-05-19  6:44     ` Catalin Vasile
  1 sibling, 0 replies; 11+ messages in thread
From: Herbert Xu @ 2016-05-19  2:43 UTC (permalink / raw)
  To: Denis B; +Cc: cata.vasile, linux-crypto

Denis B <begun.denis@gmail.com> wrote:
> Forgive my dumbness, but in:
> 
>      .cra_type = &crypto_aead_type,
>      .cra_u = {
>            .aead = {
>                .setkey = pp_crypto_aead_setkey,
>                .setauthsize = pp_crypto_aead_setauthsize,
>                .decrypt = pp_crypto_aead_dec,
>                .encrypt = pp_crypto_aead_enc,
>                .givencrypt = pp_crypto_aead_genivencrypt,
>                .givdecrypt = pp_crypto_aead_genivdecrypt,
>                .ivsize = AES_BLOCK_SIZE,
>                .maxauthsize = SHA256_DIGEST_SIZE,
>            },
>      },
> 
> Just delete the givencrypt and givdecrypt lines (or set to NULL)?

You also need to set your cra_type to nivaead.

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

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: IV generation in cryptographic driver in AEAD
  2016-05-18 14:21   ` Denis B
  2016-05-19  2:43     ` Herbert Xu
@ 2016-05-19  6:44     ` Catalin Vasile
  2016-05-19 11:05       ` Denis B
  1 sibling, 1 reply; 11+ messages in thread
From: Catalin Vasile @ 2016-05-19  6:44 UTC (permalink / raw)
  To: Denis B; +Cc: linux-crypto@vger.kernel.org

Inline comments

________________________________________
From: Denis B <begun.denis@gmail.com>
Sent: Wednesday, May 18, 2016 5:21 PM
To: Catalin Vasile
Cc: linux-crypto@vger.kernel.org
Subject: Re: IV generation in cryptographic driver in AEAD

Forgive my dumbness, but in:

      .cra_type = &crypto_aead_type,
      .cra_u = {
            .aead = {
                .setkey = pp_crypto_aead_setkey,
                .setauthsize = pp_crypto_aead_setauthsize,
                .decrypt = pp_crypto_aead_dec,
                .encrypt = pp_crypto_aead_enc,
                .givencrypt = pp_crypto_aead_genivencrypt,
                .givdecrypt = pp_crypto_aead_genivdecrypt,
                .ivsize = AES_BLOCK_SIZE,
                .maxauthsize = SHA256_DIGEST_SIZE,
            },
      },

Just delete the givencrypt and givdecrypt lines (or set to NULL)?
[Catalin Vasile]
You need to set it to NULL. If your struct is declared globally, the parts
that load your code will be set any uninitialized struct elements to NULL.

On Wed, May 18, 2016 at 4:56 PM, Catalin Vasile <cata.vasile@nxp.com> wrote:
> Inline comments.
>
> ________________________________________
> From: linux-crypto-owner@vger.kernel.org <linux-crypto-owner@vger.kernel.org> on behalf of Denis B <begun.denis@gmail.com>
> Sent: Wednesday, May 18, 2016 3:06 PM
> To: linux-crypto@vger.kernel.org
> Subject: IV generation in cryptographic driver in AEAD
>
> Hello,
>
> In AEAD mode (or in any case, in IPSec ESP IPv4 – esp4.c), in kernel
> versions prior to 4.2 the cryptographic driver is expected to generate
> an IV.
>
> What if my driver is unable to generate an IV?
> [Catalin Vasile]
> Simple: You do not implement the givcrypt() primitive. The kernel will generate the IV in software and then call your encrypt() primitive.
>
> Thanks,
> Dennis.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: IV generation in cryptographic driver in AEAD
  2016-05-19  6:44     ` Catalin Vasile
@ 2016-05-19 11:05       ` Denis B
  2016-05-20  4:19         ` Herbert Xu
  0 siblings, 1 reply; 11+ messages in thread
From: Denis B @ 2016-05-19 11:05 UTC (permalink / raw)
  Cc: linux-crypto@vger.kernel.org

My algs struct now looks like this:

static struct crypto_alg pp_crypto_algs[] = {
   {
      .cra_name = "authenc(hmac(sha256),cbc(aes))",
      .cra_driver_name = "pp_crypto_cbc_hmac_sha256",
      .cra_priority = 1, /**TODO set to highest values after
implementing encrypt decrypt functions */
      .cra_flags = CRYPTO_ALG_TYPE_AEAD | CRYPTO_ALG_ASYNC,
      .cra_blocksize = AES_BLOCK_SIZE,
      .cra_ctxsize = sizeof(struct pp_crypto_aead_ctx),
      .cra_type = &crypto_nivaead_type,
      .cra_u = {
            .aead = {
                .setkey = pp_crypto_aead_setkey,
                .setauthsize = pp_crypto_aead_setauthsize,
                .decrypt = pp_crypto_aead_dec,
                .encrypt = pp_crypto_aead_enc,
                .givencrypt = NULL,
                .givdecrypt = NULL,
                .ivsize = AES_BLOCK_SIZE,
                .maxauthsize = SHA256_DIGEST_SIZE,
            },
      },
      .cra_init = pp_crypto_aead_sha256_init,
      .cra_exit = pp_crypto_aead_exit,
      .cra_module = THIS_MODULE,
   },
   {
      .cra_name = "authenc(hmac(sha512),cbc(aes))",
      .cra_driver_name = "pp_crypto_cbc_hmac_sha512",
      .cra_priority = 1, /**TODO set to highest values after
implementing encrypt decrypt functions */
      .cra_flags = CRYPTO_ALG_TYPE_AEAD | CRYPTO_ALG_ASYNC,
      .cra_blocksize = AES_BLOCK_SIZE,
      .cra_ctxsize = sizeof(struct pp_crypto_aead_ctx),
      .cra_type = &crypto_nivaead_type,
      .cra_u = {
            .aead = {
                .setkey = pp_crypto_aead_setkey,
                .decrypt = pp_crypto_aead_dec,
                .encrypt = pp_crypto_aead_enc,
                .givencrypt = NULL,
                .givdecrypt = NULL,
                .ivsize = AES_BLOCK_SIZE,
                .maxauthsize = SHA512_DIGEST_SIZE,
            },
      },
      .cra_init = pp_crypto_aead_sha512_init,
      .cra_exit = pp_crypto_aead_exit,
      .cra_module = THIS_MODULE,
   }
};

I issue a ping and see esp_output() getting called. After that, I'm
used to seeing pp_crypto_givaead_enc() in my driver called. Now I see:

ping: sendto: Function not implemented


Please note that I am working with kernel 3.12, where in esp4.c line
266 we have:

err = crypto_aead_givencrypt(req);

On Thu, May 19, 2016 at 9:44 AM, Catalin Vasile <cata.vasile@nxp.com> wrote:
> Inline comments
>
> ________________________________________
> From: Denis B <begun.denis@gmail.com>
> Sent: Wednesday, May 18, 2016 5:21 PM
> To: Catalin Vasile
> Cc: linux-crypto@vger.kernel.org
> Subject: Re: IV generation in cryptographic driver in AEAD
>
> Forgive my dumbness, but in:
>
>       .cra_type = &crypto_aead_type,
>       .cra_u = {
>             .aead = {
>                 .setkey = pp_crypto_aead_setkey,
>                 .setauthsize = pp_crypto_aead_setauthsize,
>                 .decrypt = pp_crypto_aead_dec,
>                 .encrypt = pp_crypto_aead_enc,
>                 .givencrypt = pp_crypto_aead_genivencrypt,
>                 .givdecrypt = pp_crypto_aead_genivdecrypt,
>                 .ivsize = AES_BLOCK_SIZE,
>                 .maxauthsize = SHA256_DIGEST_SIZE,
>             },
>       },
>
> Just delete the givencrypt and givdecrypt lines (or set to NULL)?
> [Catalin Vasile]
> You need to set it to NULL. If your struct is declared globally, the parts
> that load your code will be set any uninitialized struct elements to NULL.
>
> On Wed, May 18, 2016 at 4:56 PM, Catalin Vasile <cata.vasile@nxp.com> wrote:
>> Inline comments.
>>
>> ________________________________________
>> From: linux-crypto-owner@vger.kernel.org <linux-crypto-owner@vger.kernel.org> on behalf of Denis B <begun.denis@gmail.com>
>> Sent: Wednesday, May 18, 2016 3:06 PM
>> To: linux-crypto@vger.kernel.org
>> Subject: IV generation in cryptographic driver in AEAD
>>
>> Hello,
>>
>> In AEAD mode (or in any case, in IPSec ESP IPv4 – esp4.c), in kernel
>> versions prior to 4.2 the cryptographic driver is expected to generate
>> an IV.
>>
>> What if my driver is unable to generate an IV?
>> [Catalin Vasile]
>> Simple: You do not implement the givcrypt() primitive. The kernel will generate the IV in software and then call your encrypt() primitive.
>>
>> Thanks,
>> Dennis.
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: IV generation in cryptographic driver in AEAD
  2016-05-19 11:05       ` Denis B
@ 2016-05-20  4:19         ` Herbert Xu
  2016-05-20 15:50           ` Gary R Hook
  0 siblings, 1 reply; 11+ messages in thread
From: Herbert Xu @ 2016-05-20  4:19 UTC (permalink / raw)
  To: Denis B; +Cc: linux-crypto

Denis B <begun.denis@gmail.com> wrote:
> My algs struct now looks like this:
> 
> static struct crypto_alg pp_crypto_algs[] = {
>   {
>      .cra_name = "authenc(hmac(sha256),cbc(aes))",
>      .cra_driver_name = "pp_crypto_cbc_hmac_sha256",
>      .cra_priority = 1, /**TODO set to highest values after
> implementing encrypt decrypt functions */
>      .cra_flags = CRYPTO_ALG_TYPE_AEAD | CRYPTO_ALG_ASYNC,
>      .cra_blocksize = AES_BLOCK_SIZE,
>      .cra_ctxsize = sizeof(struct pp_crypto_aead_ctx),
>      .cra_type = &crypto_nivaead_type,
>      .cra_u = {
>            .aead = {
>                .setkey = pp_crypto_aead_setkey,
>                .setauthsize = pp_crypto_aead_setauthsize,
>                .decrypt = pp_crypto_aead_dec,
>                .encrypt = pp_crypto_aead_enc,
>                .givencrypt = NULL,
>                .givdecrypt = NULL,
>                .ivsize = AES_BLOCK_SIZE,
>                .maxauthsize = SHA256_DIGEST_SIZE,

You also need to set geniv to "eseqiv".

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

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: IV generation in cryptographic driver in AEAD
  2016-05-20  4:19         ` Herbert Xu
@ 2016-05-20 15:50           ` Gary R Hook
  2016-05-20 23:31             ` Herbert Xu
  0 siblings, 1 reply; 11+ messages in thread
From: Gary R Hook @ 2016-05-20 15:50 UTC (permalink / raw)
  To: Herbert Xu, Denis B; +Cc: linux-crypto

On 05/19/2016 11:19 PM, Herbert Xu wrote:
> Denis B <begun.denis@gmail.com> wrote:
>> My algs struct now looks like this:
>>
>> static struct crypto_alg pp_crypto_algs[] = {
>>    {
>>       .cra_name = "authenc(hmac(sha256),cbc(aes))",
>>       .cra_driver_name = "pp_crypto_cbc_hmac_sha256",
>>       .cra_priority = 1, /**TODO set to highest values after
>> implementing encrypt decrypt functions */
>>       .cra_flags = CRYPTO_ALG_TYPE_AEAD | CRYPTO_ALG_ASYNC,
>>       .cra_blocksize = AES_BLOCK_SIZE,
>>       .cra_ctxsize = sizeof(struct pp_crypto_aead_ctx),
>>       .cra_type = &crypto_nivaead_type,
>>       .cra_u = {
>>             .aead = {
>>                 .setkey = pp_crypto_aead_setkey,
>>                 .setauthsize = pp_crypto_aead_setauthsize,
>>                 .decrypt = pp_crypto_aead_dec,
>>                 .encrypt = pp_crypto_aead_enc,
>>                 .givencrypt = NULL,
>>                 .givdecrypt = NULL,
>>                 .ivsize = AES_BLOCK_SIZE,
>>                 .maxauthsize = SHA256_DIGEST_SIZE,
>
> You also need to set geniv to "eseqiv".

I just gotta ask. Forgive my ignorance.

Why is (or should) setting geniv (be) required?

crypto_givcipher_default() appears to call crypto_default_geniv() if the 
geniv member
is NULL. That function returns "eseqiv" or "chainiv" (under certain 
conditions). If an
implementation isn't generating its own IVs, shouldn't the default 
happen anyway? Or is
this more a matter of populating the structure with known, intentional 
values?

Thank you for any illumination provided.

Gary

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: IV generation in cryptographic driver in AEAD
  2016-05-20 15:50           ` Gary R Hook
@ 2016-05-20 23:31             ` Herbert Xu
  2016-05-23 13:27               ` Gary R Hook
  0 siblings, 1 reply; 11+ messages in thread
From: Herbert Xu @ 2016-05-20 23:31 UTC (permalink / raw)
  To: Gary R Hook; +Cc: Denis B, linux-crypto

On Fri, May 20, 2016 at 10:50:38AM -0500, Gary R Hook wrote:
>
> Why is (or should) setting geniv (be) required?
> 
> crypto_givcipher_default() appears to call crypto_default_geniv() if
> the geniv member
> is NULL. That function returns "eseqiv" or "chainiv" (under certain
> conditions). If an
> implementation isn't generating its own IVs, shouldn't the default
> happen anyway? Or is
> this more a matter of populating the structure with known,
> intentional values?
> 
> Thank you for any illumination provided.

In the upstream kernel AEAD geniv has been completely phased out
and no longer exists.  Denis is working on an old kernel that still
has it.

We haven't yet phased it out for skcipher but I'm working on it.

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

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: IV generation in cryptographic driver in AEAD
  2016-05-20 23:31             ` Herbert Xu
@ 2016-05-23 13:27               ` Gary R Hook
  0 siblings, 0 replies; 11+ messages in thread
From: Gary R Hook @ 2016-05-23 13:27 UTC (permalink / raw)
  To: Herbert Xu; +Cc: Denis B, linux-crypto

On 05/20/2016 06:31 PM, Herbert Xu wrote:
> On Fri, May 20, 2016 at 10:50:38AM -0500, Gary R Hook wrote:
>>
>> Why is (or should) setting geniv (be) required?
>>
>> crypto_givcipher_default() appears to call crypto_default_geniv() if
>> the geniv member
>> is NULL. That function returns "eseqiv" or "chainiv" (under certain
>> conditions). If an
>> implementation isn't generating its own IVs, shouldn't the default
>> happen anyway? Or is
>> this more a matter of populating the structure with known,
>> intentional values?
>>
>> Thank you for any illumination provided.
>
> In the upstream kernel AEAD geniv has been completely phased out
> and no longer exists.  Denis is working on an old kernel that still
> has it.
>
> We haven't yet phased it out for skcipher but I'm working on it.

...and there was light.

Thank you; very helpful.

(I'll work harder on my line wraps... If someone knows how to get 
Thunderbird
to do it for me, I'd love to know.)

^ permalink raw reply	[flat|nested] 11+ messages in thread

end of thread, other threads:[~2016-05-23 15:01 UTC | newest]

Thread overview: 11+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2016-05-18 12:06 IV generation in cryptographic driver in AEAD Denis B
2016-05-18 13:56 ` Catalin Vasile
2016-05-18 14:21   ` Denis B
2016-05-19  2:43     ` Herbert Xu
2016-05-19  6:44     ` Catalin Vasile
2016-05-19 11:05       ` Denis B
2016-05-20  4:19         ` Herbert Xu
2016-05-20 15:50           ` Gary R Hook
2016-05-20 23:31             ` Herbert Xu
2016-05-23 13:27               ` Gary R Hook
2016-05-18 17:58 ` Stephan Mueller

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).