[
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)
