Upgrade or replace BLAKE3 package which is returning nonstandard BlockSize()

[fxamacker]

Issue To Be Solved

IMPORTANT: Atree doesn't use blake3.BlockSize() or use BLAKE3 with HMAC or PBKDF2, etc., but we should evaluate replacing zeebo/blake3 with lukechampine/blake3.

zeebo/blake3 v0.2.1 (and all earlier versions) returns 8192 from BlockSize() (in api.go). However, BLAKE3 specification uses 64 (not 8192) bytes as the block size.

In api.go in zeebo/blake3 (all versions 0.2.1 and earlier).

// BlockSize implements part of the hash.Hash interface. It returns the most
// natural size to write to the Hasher.
func (h *Hasher) BlockSize() int {
    // TODO: is there a downside to picking this large size?
    return 8192
}

In zeebo/blake3 (api.go) v0.2.2 (Jan 27, 2022), BlockSize() correctly returns 64, BlockSize() isn't called by zeebo/blake3 itself, and none of the other hardcoded occurrences of 8192 in the code were changed to 64.

// BlockSize implements part of the hash.Hash interface. It returns the most
// natural size to write to the Hasher.
func (h *Hasher) BlockSize() int {
    return 64
}

BLAKE3 Package Selection

• One of the 3 maintainers of multi-party-sig is the co-inventor of BLAKE2 and BLAKE3. And that project uses zeebo/blake3 v0.2.0. https://github.com/taurusgroup/multi-party-sig/blob/main/go.mod

• GitHub search filters out a viable alternative to zeebo/blake3 when Go is selected as the language.

Suggested Solution

Two possible solutions:

• upgrade from zeebo/blake3 v0.2.1 to v0.2.2 (released 19 days ago), or
• replace zeebo/blake3 with lukechampine/blake3 v1.1.7

Some reasons make me lean toward replacing zeebo/blake3 with lukechampine/blake3:

• Compatibility and testing effort would be the same (in this case) whether we upgrade zeebo/blake3 or replace it.
• In zeebo/blake3 v0.2.2, only `BlockSize() was changed to use 64 instead of 8192, and there's a lot of hardcoded 8192 in other places that may or may not be relevant.
• Even if Atree is not affected by the block size issue (because it doesn't use blake3.BlockSize() or constructs like PBKDF2 or HMAC), this comment in zeebo/blake3 makes me lean toward replacing it:

  // TODO: is there a downside to picking this large size?

The default answer should be "Yes, there are probably unanticipated downsides" deviating from a cryptographic standard.

[fxamacker]

Unfortunately, the alternative to zeebo/blake3 is much slower for short inputs and is hosted on a personal domain. So we'll just upgrade to latest zeebo/blake3 instead of switching.

Also, PR #248 testing 131107 digests for compatibility with BLAKE3 reduces risks.