Re: IV generation in cryptographic driver in AEAD

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 05/19/2016 11:19 PM, Herbert Xu wrote:
Denis B <begun.denis@xxxxxxxxx> 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

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



[Index of Archives]     [Kernel]     [Gnu Classpath]     [Gnu Crypto]     [DM Crypt]     [Netfilter]     [Bugtraq]

  Powered by Linux