Re: Add BLAKE3 hash to ISO checksums

> On first run, BLAKE3 runs at the same speed as SHA-512.
> On my system, the second run is 17x faster.

> for hash in b3sum sha256sum sha512sum
> Executed in    5.05 secs
> Executed in    7.46 secs
> Executed in    4.84 secs

> for hash in b3sum sha256sum sha512sum
> Executed in  280.16 millis
> Executed in    7.39 secs
> Executed in    4.84 secs

Any given hash function will take the same time for the same data.
Something in the system or test setup is likely returning any "17x"
difference or lack thereof... ie caching.
Until that outlier difference is investigated and identified, any speed
differences between hash functions wouldn't necessarily be reason
to add or drop any of them. Use ramdisk on dedicated or non-busy
testbeds, specify exact cpu model if testing cpu features or desiring
others to scale results to their own cpu's, average results across
multiple runs, don't publish outliers unless exploring degenerate edge
cases, etc.

> I recommend using https://crates.io/crates/b3sum

The actual reference implementation source code is here...
https://github.com/BLAKE3-team/BLAKE3

> Can we please add BLAKE3 hashes to
> https://www.freebsd.org/releases/13.1R/signatures ?

Two well chosen hash functions should be enough to cover a break in one,
and a third seems a bit overkill. FreeBSD doesn't really use or embed
them much and it can swap out broken algos faster than entities in
the world that may have hardcoded them in non-modular things.

https://en.wikipedia.org/wiki/Cryptographic_hash_function
https://en.wikipedia.org/wiki/Cryptography

If choosing crypto algos, the obvious will be one that are recognized by
crypto standards bodies, competitions, and communities worldwide,
and are in wide growing adopted use as a result of those processes.
Some of them may be listed starting from the above links.
Then whatever alternative competitors based on reviewed security
estimates, speed, family isolation by both authorship and algorithm
approach, cross platform, multi-thread, simplicity, programmability,
arbitrage of threat model/actor/geopolitic, Post-Quantum, etc
chosen from among the different algos.

FreeBSD's current choice of sha-256 and sha-512 do fail some of those
differentiators, thus it is probably reasonable to consider swapping
one of them out.

More of the leading competitors reference crypto implementations could
be added to FreeBSD ports and packages for people to play with.
There are also some dedicated all-in-one multi-hashing apps
that volunteers could also make ports of.

Tools like 'openssl dgst' already do include some,
and there are crypto libraries for Python, etc.