BLAKE3 hash support "portable" #6393
Conversation
this time i'm only importing the portable version.. this will result in decreased performance, obiously.. if i'm importing the assembly optimized versions, it will be some ~30,000 lines ( see php#6358 )
this is a significantly smaller alternative to the PR at php#6358 , now blake3 "portable c" version is bundled (specifically version 0.3.7 plus a few patches that will be part of the 0.3.8 release..), and ./configure supports a new optional --with-blake3-upstream-c-source-dir=DIR argument for specifying the location of the upstream BLAKE3 C implementation, if invoked, the SSE2/SSE4.1/AVX2/AVX512 optimized versions of BLAKE3 will be compiled in when applicable (this has not been added to MSVC, i don't know how to do it on MSVC, and i don't have a MSVC system to figure it out out on, if someone think getting those optimizations available on MSVC is important, take it up with the windows php mailing list.. just getting the portable version to compile on MSVC was good enough for me.) also userland scripts can detect at runtime if the portable version or the upstream version, of BLAKE was compiled by consulting phpinfo(), it will either say "blake3 implementation: portable 0.3.7" or "blake3 implementation: upstream X.X.X"
|
@testAccountDeltas you're making no sense.. |
I announced how to get rid of crashes, with the impossibility of freeing the pointer for a hash table. Which led to |
do you mean that on windows, it crash when trying to free the hash ram? Line 377 in 72e91e9 and it's supposed to be freed on line 397 here Line 397 in 72e91e9 if that is crashing or leaking memory, it probably means i got this wrong: in ext/hash/php_hash_blake3.h at hmm, maybe |
Crash happens even under Linux if you run the debugger. And you are trying to execute a large script that operates on strings. Crash occurs for the CG hash table (interned_strings) Sorry, but I am not good at reporting errors. |
|
I like the idea of having Blake3 hashing implemented. Maybe think about file hashing, too. md5_file() and sha1_file() are really outdated. Better than the need to call b3sum on the command line: |
|
What would be necessary to have support for the BLAKE3 keyed hash function ( For context: The BLAKE3 keyed hash function is generally used as a replacement for HMAC or similar, and the BLAKE3 key derivation function is generally used as a replacement for HKDF or similar. |
|
@k0001 for this patch already supports HMAC with blake3 like
and sure HMAC is slower than just using blake3's native keyed mode, but.. i imagine that using HMAC with blake3 is close enough for most projects, i won't bother trying to get native blake3 keyed mode supported as for |
|
@divinity76 thank you for your quick reply. Notice that while HMAC and HKDF are similar in purpose to BLAKE3's functions, these are not compatible algorithms. Their outputs are different. If a particular algorithm or third party project expects the BLAKE3 keyed hash of some input, or maybe it expects us to perform a BLAKE3 key derivation, then that's what one needs to do. Having HMAC or HKDF support just won't be enough. This is unrelated to performance matters, it's a matter of compatibility. For some context: I'm unfamiliar with PHP, but at the moment I'm looking at implement some code that would need to perform these BLAKE3 functions. After searching online for BLAKE3 support in PHP, I came across this issue. HMAC and HKDF are not enough for my needs, since the third party project I'm trying to integrate doesn't use those algorithms. Regarding Regarding a potential Notice that whether BLAKE3 hashes in normal mode, keyed mode or key derivation mode, are all BLAKE3 initialization parameters. So, presumably, all of this could be handled by I'm happy to implement this myself. |
|
Closing as stale |
this PR is an alternative to #6358
with some notable differences,
the idea here is that just having BLAKE3 supported in PHP, even if it's not the most performant implementation, is better than no support at all,
unsurprisingly, the portable version of BLAKE3 isn't nearly as fast as in #6358 , being beaten by MD4 (still beats MD5 though), but it still does a pretty good job in /ext/hash/bech.php, being roughly 1.9 times faster than sha3-224 on my laptop (compared to 4.2 times faster in #6358 ), and being the fastest secure hash on the list,
now my idea was that users who want the SSE/AVX/neon optimized hashes compiled in can compile php with
./configure --with-blake3-upstream-c-source-dir=DIR, where the SSE/AVX/etc optimized implementations can be found, .. but i have been unable to figure out how to tell /ext/hash/config.m4 "these paths are ABSOLUTE paths, not relative paths", so when i currently tryit ends with:
if anyone has any idea how to make
./configure --with-blake3-upstream-c-source-dir=DIRactually work, please let me know