diff options
author | Alexey Dobriyan <adobriyan@gmail.com> | 2012-01-14 21:27:37 +0300 |
---|---|---|
committer | Herbert Xu <herbert@gondor.apana.org.au> | 2012-01-15 12:39:17 +1100 |
commit | ea9e0a77d32ed6cddefd34d68ae6db4cd103783d (patch) | |
tree | 28d9c84fd9240d7e7d9012b54990b276b7eb8b91 /crypto/crypto_null.c | |
parent | 1fd4c89c9b0a55d89b9a9752ea66127172d47497 (diff) | |
download | linux-crypto-ea9e0a77d32ed6cddefd34d68ae6db4cd103783d.tar.gz linux-crypto-ea9e0a77d32ed6cddefd34d68ae6db4cd103783d.zip |
crypto: sha512 - make it work, undo percpu message schedule
commit d2188b3bbf2448b4b3f7082e5cffb1c2eb166799
aka "crypto: sha512 - Move message schedule W[80] to static percpu area"
created global message schedule area.
If sha512_update will ever be entered twice, hash will be silently
calculated incorrectly.
Probably the easiest way to notice incorrect hashes being calculated is
to run 2 ping floods over AH with hmac(sha512):
#!/usr/sbin/setkey -f
flush;
spdflush;
add IP1 IP2 ah 25 -A hmac-sha512 0x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000025;
add IP2 IP1 ah 52 -A hmac-sha512 0x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000052;
spdadd IP1 IP2 any -P out ipsec ah/transport//require;
spdadd IP2 IP1 any -P in ipsec ah/transport//require;
XfrmInStateProtoError will start ticking with -EBADMSG being returned
from ah_input(). This never happens with, say, hmac(sha1).
With patch applied (on BOTH sides), XfrmInStateProtoError does not tick
with multiple bidirectional ping flood streams like it doesn't tick
with SHA-1.
After this patch sha512_transform() will start using ~750 bytes of stack on x86_64.
This is OK for simple loads, for something more heavy, stack reduction will be done
separatedly.
Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
Cc: stable@vger.kernel.org
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Diffstat (limited to 'crypto/crypto_null.c')
0 files changed, 0 insertions, 0 deletions