Re: IV generation

[Gilad Ben-Yossef]

On Mon, May 7, 2018 at 2:29 PM, Stephan Mueller  wrote:
> Am Montag, 7. Mai 2018, 13:19:47 CEST schrieb Gilad Ben-Yossef:
>
> Hi Gilad,
>
>> ah... so if I have hardware that can implement say, seqiv, I can
>> register "seqiv(rfc4106(gcm(aes)))" and, assuming priorities are
>> right, it will be used?
>
> That is the question I cannot fully answer. Seqiv is a template and thus not
> subjet to prios by itself. So, you hardware however could register the full
> seqiv(rfc) cipher. I am not fully sure that such registered cipher is then
> picked up by the IPSec stack.
>
> Look into net/xfrm/xfrm_algos.c -- there you see the individual cipher names
> and the IV generator added separately. What I have not traced yet is whether
> the code assembles the IV generator name and the cipher name before making the
> call to crypto_alloc_aead.
>
> What I can say for sure is that the kernel crypto API knows of the
> seqiv(rfc...) cipher name and generates the IV for your (the invocation field
> that is).

I see.

I think the code does the assembly in esp4.c esp_init_aead() and
esp_init_authenc()

So it should all Just Work(TM).

Many thanks for the clarification.

Gilad



-- 
Gilad Ben-Yossef
Chief Coffee Drinker

"If you take a class in large-scale robotics, can you end up in a
situation where the homework eats your dog?"
 -- Jean-Baptiste Queru

Re: IV generation

[Stephan Mueller]

Am Montag, 7. Mai 2018, 13:19:47 CEST schrieb Gilad Ben-Yossef:

Hi Gilad,

> ah... so if I have hardware that can implement say, seqiv, I can
> register "seqiv(rfc4106(gcm(aes)))" and, assuming priorities are
> right, it will be used?

That is the question I cannot fully answer. Seqiv is a template and thus not 
subjet to prios by itself. So, you hardware however could register the full 
seqiv(rfc) cipher. I am not fully sure that such registered cipher is then 
picked up by the IPSec stack.

Look into net/xfrm/xfrm_algos.c -- there you see the individual cipher names 
and the IV generator added separately. What I have not traced yet is whether 
the code assembles the IV generator name and the cipher name before making the 
call to crypto_alloc_aead.

What I can say for sure is that the kernel crypto API knows of the 
seqiv(rfc...) cipher name and generates the IV for your (the invocation field 
that is).


Ciao
Stephan

Re: IV generation

[Gilad Ben-Yossef]

On Mon, May 7, 2018 at 2:02 PM, Stephan Mueller  wrote:
> Am Montag, 7. Mai 2018, 08:26:08 CEST schrieb Gilad Ben-Yossef:
>
> Hi Gilad,
>
>> Hi,
>>
>> A quick question: am I correct in my understanding that there is now
>> no automatic IV generation support for either skcipher nor aead?
>> And if I'm wrong, can someone point to an example of a driver that
>> implements either, as all the ones I see are the deprecated ablkcipher
>> interface.
>>
>> BTW, I'm perfectly fine with not having one, I just want to understand
>> I am not missing something...
>
> The automated IV generation is implemented with the generators such as seqiv
> or chainiv.
>
> For example, AES-GCM as used for IPSec compliant with RFC4106 generates the IV
> (the invocation field part of the IV) with the seqiv. This is handled by the
> IPSec stack to initialize the cipher of, say, seqiv(rfc4106(gcm(aes))).
>
> The CTR mode uses the chainiv implementation to manage the IV.

ah... so if I have hardware that can implement say, seqiv, I can
register "seqiv(rfc4106(gcm(aes)))" and, assuming priorities are
right, it will be used?

Thanks,
Gilad



-- 
Gilad Ben-Yossef
Chief Coffee Drinker

"If you take a class in large-scale robotics, can you end up in a
situation where the homework eats your dog?"
 -- Jean-Baptiste Queru

Re: IV generation

[Stephan Mueller]

Am Montag, 7. Mai 2018, 08:26:08 CEST schrieb Gilad Ben-Yossef:

Hi Gilad,

> Hi,
> 
> A quick question: am I correct in my understanding that there is now
> no automatic IV generation support for either skcipher nor aead?
> And if I'm wrong, can someone point to an example of a driver that
> implements either, as all the ones I see are the deprecated ablkcipher
> interface.
> 
> BTW, I'm perfectly fine with not having one, I just want to understand
> I am not missing something...

The automated IV generation is implemented with the generators such as seqiv 
or chainiv. 

For example, AES-GCM as used for IPSec compliant with RFC4106 generates the IV 
(the invocation field part of the IV) with the seqiv. This is handled by the 
IPSec stack to initialize the cipher of, say, seqiv(rfc4106(gcm(aes))).

The CTR mode uses the chainiv implementation to manage the IV.
> 
> Thanks in advance,
> Gilad



Ciao
Stephan

Re: IV generation in cryptographic driver in AEAD

[Gary R Hook]

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.)
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: IV generation in cryptographic driver in AEAD

[Herbert Xu]

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 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: IV generation in cryptographic driver in AEAD

[Gary R Hook]

On 05/19/2016 11:19 PM, Herbert Xu wrote:

Denis B  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 = _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

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

Re: IV generation in cryptographic driver in AEAD

[Herbert Xu]

Denis B  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 = _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 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: IV generation in cryptographic driver in AEAD

[Denis B]

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 = _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 = _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.vas...@nxp.com> wrote:
> Inline comments
>
> 
> From: Denis B <begun.de...@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 = _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.vas...@nxp.com> wrote:
>> Inline comments.
>>
>> 
>> From: linux-crypto-ow...@vger.kernel.org 
>> <linux-crypto-ow...@vger.kernel.org> on behalf of Denis B 
>> <begun.de...@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 majord...@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: IV generation in cryptographic driver in AEAD

[Catalin Vasile]

Inline comments


From: Denis B <begun.de...@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 = _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.vas...@nxp.com> wrote:
> Inline comments.
>
> 
> From: linux-crypto-ow...@vger.kernel.org <linux-crypto-ow...@vger.kernel.org> 
> on behalf of Denis B <begun.de...@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 majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: IV generation in cryptographic driver in AEAD

[Herbert Xu]

Denis B  wrote:
> Forgive my dumbness, but in:
> 
>  .cra_type = _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 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: IV generation in cryptographic driver in AEAD

[Stephan Mueller]

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 majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


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

Re: IV generation in cryptographic driver in AEAD

[Denis B]

Forgive my dumbness, but in:

  .cra_type = _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  wrote:
> Inline comments.
>
> 
> From: linux-crypto-ow...@vger.kernel.org  
> on behalf of Denis B 
> 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 majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: IV generation in cryptographic driver in AEAD

[Catalin Vasile]

Inline comments.


From: linux-crypto-ow...@vger.kernel.org  
on behalf of Denis B 
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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: IV generation in geode-aes

[Hamid Nassiby]

Hi,

In geode-aes, there is not any IV generation mechanism. In fact IV is
delivered to geode-aes's
registered algorithms, from upper layers.For example in case of
cbc-aes-geode algorithm,
from cbc wrapper (cbc.c) via walk-iv:

blkcipher_walk_init(walk, dst, src, nbytes);
err = blkcipher_walk_virt(desc, walk);
op-iv = walk.iv;
...

Regards.

On Thu, Sep 19, 2013 at 4:34 PM, Sohail sohailtari...@gmail.com wrote:
 Hi all,
 I could'nt understand the mechanism of IV generation in geode-aes. Can
 someone explain it in easy to understand manner?

 Thanks a lot.

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