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

Reply via email to