For those who are unfamiliar with the Blake family of hash functions, Blake3 is essentially an updated version of Blake2s that unifies the other Blake2* variants into a single API to make things easier for developers and users. Blake2 has several variants, 2b and 2s being the most commonly used (blake2b is the default hash used in libsodium, a popular C crypto library). Some links:
https://github.com/BLAKE3-team/BLAKE3 https://www.blake2.net/ Specs: https://github.com/BLAKE3-team/BLAKE3-specs/blob/master/blake3.pdf On Sun, 28 Feb 2021 at 14:14, Matt Sicker <boa...@gmail.com> wrote: > > I'd also be interested in benchmarking comparisons as I've been > working on a proof of concept using Blake3 to do similarly (I have a > pure Java implementation and a JNI version that ultimately invokes the > reference C implementation, though I've also wondered about linking > the reference Rust implementation). The potential advantage to linking > in the native implementations here would be in taking advantage of > CPU-specific extensions like SSE, AVX, NEON, etc., which aren't > accessible from the JVM without JNI or other patches to the JDK > itself. If the overhead turns out to be non-negligible, then we should > probably keep the native code bindings to commons-crypto while porting > pure Java implementations to commons-codec. > > On Sun, 28 Feb 2021 at 09:25, Bernd Eckenfels <e...@zusammenkunft.net> wrote: > > > > ... and also do benchmarking early, the native interface overhead might be > > a problem so that pure java (intrinsic) code is much faster > > > > > > -- > > http://bernd.eckenfels.net > > ________________________________ > > Von: Gary Gregory <garydgreg...@gmail.com> > > Gesendet: Sunday, February 28, 2021 2:45:26 PM > > An: Commons Developers List <dev@commons.apache.org> > > Betreff: Re: [crypto] Interest in adding support for cryptographic hash > > function? > > > > That sounds reasonable to me. I think once we see a PR, we'll get a better > > idea. Start small IMO. > > > > Gary > > > > > > On Sat, Feb 27, 2021, 13:51 Alex Remily <alex.rem...@gmail.com> wrote: > > > > > I'd be exposing additional elements of the OpenSSL API via additions to > > > the > > > commons crypto API. Since I wouldn't be adding any additional > > > dependencies, I would expect that licensing and portability would remain > > > unchanged. Would it not? > > > > > > Thanks, > > > > > > Alex > > > > > > On Sat, Feb 27, 2021 at 1:08 PM Gilles Sadowski <gillese...@gmail.com> > > > wrote: > > > > > > > Le sam. 27 févr. 2021 à 19:00, Bernd Eckenfels > > > > <e...@zusammenkunft.net> a écrit : > > > > > > > > > > Hello, > > > > > > > > > > I don’t think it’s a Good idea to introduce native dependencies to > > > > formerly pure Java projects. > > > > > > > > +1 > > > > [I thought that the idea was a (pure) Java implementation.] > > > > > > > > > So i think native optimized hash implementations would fit better in > > > > commons-crypto. So I would say go for it, keep in mind license clearance > > > > and portability. > > > > > > > > > > Gruß > > > > > Bernd > > > > > > > > > > > [...] > > > > > > > > --------------------------------------------------------------------- > > > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > > > > > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org