All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Elliott, Robert (Servers)" <elliott@hpe.com>
To: Ard Biesheuvel <ardb@kernel.org>,
	"linux-crypto@vger.kernel.org" <linux-crypto@vger.kernel.org>
Cc: "herbert@gondor.apana.org.au" <herbert@gondor.apana.org.au>,
	"keescook@chromium.org" <keescook@chromium.org>,
	Eric Biggers <ebiggers@kernel.org>,
	"Jason A . Donenfeld" <Jason@zx2c4.com>,
	"Nikunj A Dadhania" <nikunj@amd.com>
Subject: RE: [PATCH v5 3/3] crypto: aesgcm - Provide minimal library implementation
Date: Thu, 3 Nov 2022 21:16:09 +0000	[thread overview]
Message-ID: <MW5PR84MB18427E0F1886F8A0273A8553AB389@MW5PR84MB1842.NAMPRD84.PROD.OUTLOOK.COM> (raw)
In-Reply-To: <20221103192259.2229-4-ardb@kernel.org>



> -----Original Message-----
> From: Ard Biesheuvel <ardb@kernel.org>
> Sent: Thursday, November 3, 2022 2:23 PM
> Subject: [PATCH v5 3/3] crypto: aesgcm - Provide minimal library implementation
> 

Given include/crypto/aes.h:
struct crypto_aes_ctx {
        u32 key_enc[AES_MAX_KEYLENGTH_U32];
        u32 key_dec[AES_MAX_KEYLENGTH_U32];
        u32 key_length;
};

plus:
...
+struct aesgcm_ctx {
+	be128			ghash_key;
+	struct crypto_aes_ctx	aes_ctx;
+	unsigned int		authsize;
+};
...
> +static void aesgcm_encrypt_block(const struct crypto_aes_ctx *ctx, void *dst,
...
> +	local_irq_save(flags);
> +	aes_encrypt(ctx, dst, src);
> +	local_irq_restore(flags);
> +}
...
> +int aesgcm_expandkey(struct aesgcm_ctx *ctx, const u8 *key,
> +		     unsigned int keysize, unsigned int authsize)
> +{
> +	u8 kin[AES_BLOCK_SIZE] = {};
> +	int ret;
> +
> +	ret = crypto_gcm_check_authsize(authsize) ?:
> +	      aes_expandkey(&ctx->aes_ctx, key, keysize);

Since GCM uses the underlying cipher's encrypt algorithm for both
encryption and decryption, is there any need for the 240-byte
aesctx->key_dec decryption key schedule that aes_expandkey
also prepares?

For modes like this, it might be worth creating a specialized
struct that only holds the encryption key schedule (key_enc),
with a derivative of aes_expandkey() that only updates it.


  reply	other threads:[~2022-11-03 21:16 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-03 19:22 [PATCH v5 0/3] crypto: Add AES-GCM implementation to lib/crypto Ard Biesheuvel
2022-11-03 19:22 ` [PATCH v5 1/3] crypto: move gf128mul library into lib/crypto Ard Biesheuvel
2022-11-03 19:22 ` [PATCH v5 2/3] crypto: gf128mul - make gf128mul_lle time invariant Ard Biesheuvel
2022-11-03 19:22 ` [PATCH v5 3/3] crypto: aesgcm - Provide minimal library implementation Ard Biesheuvel
2022-11-03 21:16   ` Elliott, Robert (Servers) [this message]
2022-11-04 10:40     ` Ard Biesheuvel
2022-11-11 10:17 ` [PATCH v5 0/3] crypto: Add AES-GCM implementation to lib/crypto Herbert Xu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=MW5PR84MB18427E0F1886F8A0273A8553AB389@MW5PR84MB1842.NAMPRD84.PROD.OUTLOOK.COM \
    --to=elliott@hpe.com \
    --cc=Jason@zx2c4.com \
    --cc=ardb@kernel.org \
    --cc=ebiggers@kernel.org \
    --cc=herbert@gondor.apana.org.au \
    --cc=keescook@chromium.org \
    --cc=linux-crypto@vger.kernel.org \
    --cc=nikunj@amd.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.