mirror of
https://github.com/wolfSSL/wolfssl.git
synced 2026-10-24 04:09:07 +03:00
a5ee666332
When a SETKEY device claimed a new key through wc_AesSetKey(), wc_AesCcmSetKey() or wc_AesSetKeyDirect(), the set-key wiped the old key schedule and devKey but left gcm.H and the GHASH table M0 of an earlier software GCM key in the context. Only wc_AesGcmSetKey() wiped them. gcmKeySet is already cleared on that path, so the stale H could not be used, but it is key material derived from the old key and goes with the rest of it. The pre-claim wipe in the generic, ARM32 and PPC set-key now clears H and M0 too, through a WC_AES_GCM_WIPE_H() macro that wc_AesGcmSetKey() uses as well. The CryptoCb AES set-key tests in test_aes.c took buffer sizes with sizeof, which is the size of a pointer under WOLFSSL_SMALL_STACK. In such builds test_wc_CryptoCb_AesSetKey and test_wc_CryptoCb_AesGcm_EncryptDecrypt failed at their first set-key with an 8-byte key, and the declined re-key check passed an 8-byte tag that wc_AesGcmEncrypt() rejects before it asks the device. Both tests now use the allocation sizes.
Before creating any new configure files (.conf) read the CONF_FILES_README.md