forked from Minki/linux
1862eb0073
Add a NEON-accelerated implementation of BLAKE2b. On Cortex-A7 (which these days is the most common ARM processor that doesn't have the ARMv8 Crypto Extensions), this is over twice as fast as SHA-256, and slightly faster than SHA-1. It is also almost three times as fast as the generic implementation of BLAKE2b: Algorithm Cycles per byte (on 4096-byte messages) =================== ======================================= blake2b-256-neon 14.0 sha1-neon 16.3 blake2s-256-arm 18.8 sha1-asm 20.8 blake2s-256-generic 26.0 sha256-neon 28.9 sha256-asm 32.0 blake2b-256-generic 38.9 This implementation isn't directly based on any other implementation, but it borrows some ideas from previous NEON code I've written as well as from chacha-neon-core.S. At least on Cortex-A7, it is faster than the other NEON implementations of BLAKE2b I'm aware of (the implementation in the BLAKE2 official repository using intrinsics, and Andrew Moon's implementation which can be found in SUPERCOP). It does only one block at a time, so it performs well on short messages too. NEON-accelerated BLAKE2b is useful because there is interest in using BLAKE2b-256 for dm-verity on low-end Android devices (specifically, devices that lack the ARMv8 Crypto Extensions) to replace SHA-1. On these devices, the performance cost of upgrading to SHA-256 may be unacceptable, whereas BLAKE2b-256 would actually improve performance. Although BLAKE2b is intended for 64-bit platforms (unlike BLAKE2s which is intended for 32-bit platforms), on 32-bit ARM processors with NEON, BLAKE2b is actually faster than BLAKE2s. This is because NEON supports 64-bit operations, and because BLAKE2s's block size is too small for NEON to be helpful for it. The best I've been able to do with BLAKE2s on Cortex-A7 is 18.8 cpb with an optimized scalar implementation. (I didn't try BLAKE2sp and BLAKE3, which in theory would be faster, but they're more complex as they require running multiple hashes at once. Note that BLAKE2b already uses all the NEON bandwidth on the Cortex-A7, so I expect that any speedup from BLAKE2sp or BLAKE3 would come only from the smaller number of rounds, not from the extra parallelism.) For now this BLAKE2b implementation is only wired up to the shash API, since there is no library API for BLAKE2b yet. However, I've tried to keep things consistent with BLAKE2s, e.g. by defining blake2b_compress_arch() which is analogous to blake2s_compress_arch() and could be exported for use by the library API later if needed. Acked-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Eric Biggers <ebiggers@google.com> Tested-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> |
||
|---|---|---|
| .. | ||
| .gitignore | ||
| aes-ce-core.S | ||
| aes-ce-glue.c | ||
| aes-cipher-core.S | ||
| aes-cipher-glue.c | ||
| aes-neonbs-core.S | ||
| aes-neonbs-glue.c | ||
| blake2b-neon-core.S | ||
| blake2b-neon-glue.c | ||
| blake2s-core.S | ||
| blake2s-glue.c | ||
| chacha-glue.c | ||
| chacha-neon-core.S | ||
| chacha-scalar-core.S | ||
| crc32-ce-core.S | ||
| crc32-ce-glue.c | ||
| crct10dif-ce-core.S | ||
| crct10dif-ce-glue.c | ||
| curve25519-core.S | ||
| curve25519-glue.c | ||
| ghash-ce-core.S | ||
| ghash-ce-glue.c | ||
| Kconfig | ||
| Makefile | ||
| nh-neon-core.S | ||
| nhpoly1305-neon-glue.c | ||
| poly1305-armv4.pl | ||
| poly1305-core.S_shipped | ||
| poly1305-glue.c | ||
| sha1_glue.c | ||
| sha1_neon_glue.c | ||
| sha1-armv4-large.S | ||
| sha1-armv7-neon.S | ||
| sha1-ce-core.S | ||
| sha1-ce-glue.c | ||
| sha1.h | ||
| sha2-ce-core.S | ||
| sha2-ce-glue.c | ||
| sha256_glue.c | ||
| sha256_glue.h | ||
| sha256_neon_glue.c | ||
| sha256-armv4.pl | ||
| sha256-core.S_shipped | ||
| sha512-armv4.pl | ||
| sha512-core.S_shipped | ||
| sha512-glue.c | ||
| sha512-neon-glue.c | ||
| sha512.h | ||