[jira] [Updated] (CODEC-296) Add support for Blake3 family of hashes

["Matt Sicker (Jira)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/CODEC-296?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Matt Sicker updated CODEC-296:
------------------------------
    Description: 
Brief historical context: the original Blake hash algorithm was a finalist in the SHA-3 competition. The second version, [Blake2|https://www.blake2.net/], has several variants, the most popular seem to be Blake2b and Blake2s, though there are a few others that are tuned and tweaked for different use cases. This brings us to [Blake3|https://github.com/BLAKE3-team/BLAKE3], the third version of the hash algorithm which unifies the variants into a single interface along with further tuned security parameters for increased performance with negligible impact on security.

Blake3 is extremely versatile and offers interfaces to use it as a message digest (hash) function, pseudorandom function (PRF), a message authentication code (MAC), a key derivation function (KDF), and an extensible output function (XOF). It is also faster than MD5 and SHA-1 (and SHA-2 and SHA-3) while remaining secure which makes it handy for less security-intensive contexts, too, like file hashing.

While implementing a MessageDigestSpi is fairly straightforward, a MacSpi needs to be loaded from a signed jar which would complicate things a bit here. A more appropriate cryptographic API that encompasses all the above functionality would be an interface like the [stateful hash object (SHO)|https://github.com/noiseprotocol/sho_spec/blob/master/output/sho.pdf] from the noise protocol.

  was:
Brief historical context: the original Blake hash algorithm was a finalist in the SHA-3 competition. The second version, [Blake2|https://www.blake2.net/], has several variants, the most popular seem to be Blake2b and Blake2s, though there are a few others that are tuned and tweaked for different use cases. This brings us to [Blake3|https://github.com/BLAKE3-team/BLAKE3], the third version of the hash algorithm which unifies the variants into a single interface along with further tuned security parameters for increased performance with negligible impact on security.

Blake3 is extremely versatile and offers interfaces to use it as a message digest (hash) function, pseudorandom function (PRF), a message authentication code (MAC), a key derivation function (KDF), and an extensible output function (XOF). It is also faster than MD5 and SHA-1 (and SHA-2 and SHA-3) while remaining secure which makes it handy for less security-intensive contexts, too, like file hashing.

I've previously ported the reference public domain Rust implementation to Java for another use case, so the algorithm itself is pretty simple to add here. This library doesn't define any interfaces for these concerns, though the Java crypto API does have some equivalents for most of those use cases, but they might be overkill for this.


> Add support for Blake3 family of hashes
> ---------------------------------------
>
>                 Key: CODEC-296
>                 URL: https://issues.apache.org/jira/browse/CODEC-296
>             Project: Commons Codec
>          Issue Type: New Feature
>            Reporter: Matt Sicker
>            Assignee: Matt Sicker
>            Priority: Major
>
> Brief historical context: the original Blake hash algorithm was a finalist in the SHA-3 competition. The second version, [Blake2|https://www.blake2.net/], has several variants, the most popular seem to be Blake2b and Blake2s, though there are a few others that are tuned and tweaked for different use cases. This brings us to [Blake3|https://github.com/BLAKE3-team/BLAKE3], the third version of the hash algorithm which unifies the variants into a single interface along with further tuned security parameters for increased performance with negligible impact on security.
> Blake3 is extremely versatile and offers interfaces to use it as a message digest (hash) function, pseudorandom function (PRF), a message authentication code (MAC), a key derivation function (KDF), and an extensible output function (XOF). It is also faster than MD5 and SHA-1 (and SHA-2 and SHA-3) while remaining secure which makes it handy for less security-intensive contexts, too, like file hashing.
> While implementing a MessageDigestSpi is fairly straightforward, a MacSpi needs to be loaded from a signed jar which would complicate things a bit here. A more appropriate cryptographic API that encompasses all the above functionality would be an interface like the [stateful hash object (SHO)|https://github.com/noiseprotocol/sho_spec/blob/master/output/sho.pdf] from the noise protocol.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)