[
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
generic commons API here might be easiest to deal with (previous idea of SHO
API is a higher level feature).
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.
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.
> 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 generic commons API here might be easiest to deal with (previous idea
> of SHO API is a higher level feature).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
