diff options
| author | Daniele Alessandrelli <daniele.alessandrelli@intel.com> | 2021-02-03 15:42:10 +0000 |
|---|---|---|
| committer | Herbert Xu <herbert@gondor.apana.org.au> | 2021-02-10 17:55:59 +1100 |
| commit | 0db5bc85c5d871188b6f66ee26bc712a309a4a3d (patch) | |
| tree | 66a1a3c0561a72d86e6a4b96d5e86b5210e9fa63 /MAINTAINERS | |
| parent | cfb28fde083761bfb839bc53059068bab5634b6a (diff) | |
| download | linux-0db5bc85c5d871188b6f66ee26bc712a309a4a3d.tar.gz linux-0db5bc85c5d871188b6f66ee26bc712a309a4a3d.tar.bz2 linux-0db5bc85c5d871188b6f66ee26bc712a309a4a3d.zip | |
crypto: keembay-ocs-aes - Fix 'q' assignment during CCM B0 generation
In ocs_aes_ccm_write_b0(), 'q' (the octet length of the binary
representation of the octet length of the payload) is set to 'iv[0]',
while it should be set to 'iv[0] & 0x7' (i.e., only the last 3
bits of iv[0] should be used), as documented in NIST Special Publication
800-38C:
https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-38c.pdf
In practice, this is not an issue, since 'iv[0]' is checked to be in the
range [1-7] by ocs_aes_validate_inputs(), but let's fix the assignment
anyway, in order to make the code more robust.
Signed-off-by: Daniele Alessandrelli <daniele.alessandrelli@intel.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Diffstat (limited to 'MAINTAINERS')
0 files changed, 0 insertions, 0 deletions