hash BLAKE3

From: Date: Wed, 21 Oct 2020 19:34:03 +0000
Subject: hash BLAKE3
Groups: php.internals 
Request: Send a blank email to internals+get-112093@lists.php.net to get a copy of this message
i want BLAKE3 hash support in php, some justifications can be found here https://bugs.php.net/bug.php?id=79492 primary reasons being that it's a "cryptographically secure hash", predecessor BLAKE was nearly crowned "SHA3" (SHA3 finalist), and it's very fast in software, when i run it against php-src/ext/hash/bench.php , on a cpu without the most beneficial instruction-set available, it was still over 4 times faster than sha3-224, outperforming even several non-crypto-hashes, exact numbers here: https://github.com/php/php-src/pull/6358#issuecomment-713506971 ) i have a PR here: https://github.com/php/php-src/pull/6358 initially had several issues, but i think most of them are resolved now, - SSE/AVX optimizations are added for "gcc+(unix|windows)+x86_64" targets, and i have asked the php-windows mailing list for help in adding SSE/AVX optimizations to the MSVC builds, but for the time being, MSVC builds are just using a portable generic C implementation. it would also be possible to add an optimized implementation for ARM+Neon targets, i haven't looked into that at all. - currently the code is rolling it's own cpu feature detection, instead of asking Zend/zend_cpuinfo.c (specifically ext/hash/blake3/blake3_dispatch.c ), is that something that "must be fixed" before upstream merging can be considered? or is it ok-ish? - frankly, there's just *a lot* of code in there, is it possible that it will be rejected just because "it's too much code" ? (there's a reason there's so much code though, it contains cpu-specific implementations for a lot of different environments, compilers, OS's, and CPU's, from SSE2 to AVX512 to ARM+Neon, also a much smaller implementation using just the "portable generic C implementation" would be possible, at the cost of performance)

« previous php.internals (#112093) next »