summaryrefslogtreecommitdiff
path: root/crypto/sha256_generic.c
diff options
context:
space:
mode:
authorMathias Krause <minipli@googlemail.com>2014-12-30 22:50:54 +0100
committerHerbert Xu <herbert@gondor.apana.org.au>2015-01-05 21:35:02 +1100
commit0b1e95b2fa0934c3a08db483979c70d3b287f50e (patch)
tree3494012be5e6e4911c9069e1dcaccdf2203ab2f9 /crypto/sha256_generic.c
parent7e77bdebff5cb1e9876c561f69710b9ab8fa1f7e (diff)
downloadlwn-0b1e95b2fa0934c3a08db483979c70d3b287f50e.tar.gz
lwn-0b1e95b2fa0934c3a08db483979c70d3b287f50e.zip
crypto: aesni - fix "by8" variant for 128 bit keys
The "by8" counter mode optimization is broken for 128 bit keys with input data longer than 128 bytes. It uses the wrong key material for en- and decryption. The key registers xkey0, xkey4, xkey8 and xkey12 need to be preserved in case we're handling more than 128 bytes of input data -- they won't get reloaded after the initial load. They must therefore be (a) loaded on the first iteration and (b) be preserved for the latter ones. The implementation for 128 bit keys does not comply with (a) nor (b). Fix this by bringing the implementation back to its original source and correctly load the key registers and preserve their values by *not* re-using the registers for other purposes. Kudos to James for reporting the issue and providing a test case showing the discrepancies. Reported-by: James Yonan <james@openvpn.net> Cc: Chandramouli Narayanan <mouli@linux.intel.com> Cc: <stable@vger.kernel.org> # v3.18 Signed-off-by: Mathias Krause <minipli@googlemail.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Diffstat (limited to 'crypto/sha256_generic.c')
0 files changed, 0 insertions, 0 deletions