Received-SPF: pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
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
Thread-Topic: [PATCH v5 3/3] crypto: aesgcm - Provide minimal library
 implementation
Thread-Index: AQHY77nKA3y20aUl4ES9+3z1a5mG0K4tqzEg
Date:   Thu, 3 Nov 2022 21:16:09 +0000
Message-ID: <MW5PR84MB18427E0F1886F8A0273A8553AB389@MW5PR84MB1842.NAMPRD84.PROD.OUTLOOK.COM>
References: <20221103192259.2229-1-ardb@kernel.org>
 <20221103192259.2229-4-ardb@kernel.org>
In-Reply-To: <20221103192259.2229-4-ardb@kernel.org>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?z6BVPxw7GfiBISP8asCK1lmr+9B7aIOC6U3N0IsaUZ2zhNdASTX5ib1BSvfH?=
 =?us-ascii?Q?3QhzDMLWB+NmjT3kezhaxHenfTJ7c78zzLz7dJ8HyFGb/ATaTnK0ByAECbpf?=
 =?us-ascii?Q?9gNZBN48q/FuxAUNrZk9yMibasY/WKosFThciCCgyXpxN5wMElatf1PdBaO7?=
 =?us-ascii?Q?nVjNTfHsQLxGpwPRl/Mwq0U752VxPwl1YVrg3LtzIOF3g/ZOaTgDBkP7LhV/?=
 =?us-ascii?Q?eUz4duH7bDKpFKDvptJfG2e50oGNxIRNJXQDOuBpl0SSvWx/B+KSjcltbDPT?=
 =?us-ascii?Q?kbrUBLJdSSYSMDGiP+qKF/o5eimx6c4xrXvNuh6wcZuKMO8D+m1QWWJ32Qt4?=
 =?us-ascii?Q?xwepYz9aaLZ8olG046kget9K+mP5Mwyb/ywvsVDOmjrzr82sIpllI3/y6SAy?=
 =?us-ascii?Q?iAzsiOSVIpBSC2CyUV/6fhd6Anuadfu6AU7sFveNolUwiqezrBhzVNtvoX/h?=
 =?us-ascii?Q?gtghZdZyvabpIfCDm926DOTTJ7zu/YvJqTnuwv3IULy1PeBab7kGHaIjb91z?=
 =?us-ascii?Q?cIWzY3WYjdcZ5/RndnybVlVsDyV6gWpKS+/PBza1BWYHw0kAlRRTldp4Tr8n?=
 =?us-ascii?Q?ZBK9KoqN5GidYsYMCS+GD9F+B2dWQcoS8AZZd+/VMYxMqWgvE7vFthikmOhf?=
 =?us-ascii?Q?NoT5PqCu4Tgye6eDCAoAxUOoHRzEzmYWAFS9cfbmTF84pBvOSgdEhTmOAP3v?=
 =?us-ascii?Q?xiZ7C/rvheSg8w/rCeNrboJ41uk3CxEBO/mE2iIz/zNbYnMbIcibbG5dElK6?=
 =?us-ascii?Q?MtIXW31UsfZWbMB+toUEuGHLKDhthdUiIp4ttyV8cvMTQkuH8HvixoTTRW7W?=
 =?us-ascii?Q?FFbpTSJQKwq+zecpWWRkiYxgMdkacR5TJhP8KT4GEehVpVZ6f7Lc0bl6DL+/?=
 =?us-ascii?Q?SjqbcjJVyWGrzfqvzAXVIZ+O6Gzta7VhgLunmyR3YxBPBFbpD3zZ+RI8hH7q?=
 =?us-ascii?Q?qWBKzyTBEOn8QqPkDV/CGKDFRsN0kocyYZT8XnIkHFDGDOd2hIfTCwjaQwHw?=
 =?us-ascii?Q?CyEO4BpTHF/oxPqfaaztmHQZ2FgAcTeT4Ek+wK3LP44I4BDzrMdK+8d83Kxx?=
 =?us-ascii?Q?h+4hljwoV9WKS1y3ELds31emxRmzaPSgTV9JYkzx0o4H0RzRuIANtHdpxgjt?=
 =?us-ascii?Q?ZAuLle2ivCGMfCSIAqnghHsNFDm2995Re/0UMd6PsMv00QNcvWrkBIU+xZH8?=
 =?us-ascii?Q?tArvcEBefugYlbbWelwbsocusnTit+uoQJVKitt8mbk5xZPSMNVYva6NJGMu?=
 =?us-ascii?Q?o3gnKcgoYPbVjI7EtxAMj9+JJP350fWme4rckYTamVkhwceHD2yntJkuouFM?=
 =?us-ascii?Q?rtHueitC/CKa66qip5ulJXk94kfSIjyQkmOrBqS6mzmUT0ANx7/SZZv9rieh?=
 =?us-ascii?Q?9EBFZ6Myi/raFytDbafTvsLtVyCjLD+sQiAuM4mSjdnwjzmYqB8qUTmSCP9B?=
 =?us-ascii?Q?GW+zRhjMoAngdH0RxdL177pzJP+RnTfr9gyhQ7DksmiuiEEhVytqA/h/EEUa?=
 =?us-ascii?Q?UXA9uHhPavCULvvNmNKyQpI6Zakg1MPhfikbc61eG1rMeL6v+FJVh4gA1HE2?=
 =?us-ascii?Q?twQHsuLVltkFYhGKAnA=3D?=
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: MW5PR84MB1842.NAMPRD84.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-Network-Message-Id: 2bbcbe0c-f516-4c8f-9930-08dabde0a0fd
X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Nov 2022 21:16:09.7332
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 105b2061-b669-4b31-92ac-24d304d195dc
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: km3phGTxtrQ5HCVYr5BrWnmBfANgLkPfbagKQEQcbMl9bRDgsa3qfHP4vsxo58ii
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ0PR84MB1800
X-OriginatorOrg: hpe.com
X-Proofpoint-ORIG-GUID: otwPW50GKhIs92V5jx7jtnDSnXRsBDL7
X-Proofpoint-GUID: otwPW50GKhIs92V5jx7jtnDSnXRsBDL7
X-HPE-SCL: -1
X-Proofpoint-Virus-Version: vendor=baseguard
 engine=ICAP:2.0.205,Aquarius:18.0.895,Hydra:6.0.545,FMLib:17.11.122.1
 definitions=2022-11-03_04,2022-11-03_01,2022-06-22_01
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 mlxscore=0 phishscore=0
 spamscore=0 clxscore=1015 lowpriorityscore=0 suspectscore=0
 mlxlogscore=999 impostorscore=0 bulkscore=0 priorityscore=1501
 adultscore=0 malwarescore=0 classifier=spam adjust=0 reason=mlx
 scancount=1 engine=8.12.0-2210170000 definitions=main-2211030146
X-Spam-Status: No, score=-3.8 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,
        DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_LOW,
        SPF_HELO_NONE,SPF_NONE autolearn=ham autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
        lindbergh.monkeyblade.net
Precedence: bulk
List-ID: <linux-crypto.vger.kernel.org>
X-Mailing-List: linux-crypto@vger.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 implemen=
tation
>=20

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] =3D {};
> +	int ret;
> +
> +	ret =3D 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.