Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

BLAKE3 1.0

github.com

Post reply on HN
Print view View original

41–50 of 126 posts

Re: BLAKE3 1.0

#41

Post by SAI_Peregrinus »

api wrote: post #29
SAI_Peregrinus wrote: post #25

Earlier quoted context omitted.

And if you're designing hardware (or on an FPGA) ChaCha (and BLAKE2/3) are actually really freakin' fast for the die area they take. IIRC ChaCha20 beats AES in hardware. It's just extremely rare (FPGA only) to find it in hardware, since there's not enough demand. I expect that to eventually change.

Given that all these are ARX cores, I wonder if a fused ARX instruction could cover a wide range of them?

Probably. With a barrel shifter easily. Barrel shifters are a bit slower than wired shifts though, so for ultimate speed you'd end up with hardware shift amounts.

Re: BLAKE3 1.0

#42

Post by pornel »

Croftengea wrote: post #9

Is this 1.0 ready indeed? a comment in blake3_neon.c: // TODO: This is probably incorrect for big-endian ARM. How should that work?

1.0 is not the last and final version of a product. There can always be 1.0.1 or 1.1 or 2.0. Numbers are plentiful.

Rust ecosystem is already overthinking 1.0 releases, which results in tons of crates having 0.x versions while being depended on as de-facto stable.

Re: BLAKE3 1.0

#43

Post by api »

SAI_Peregrinus wrote: post #41
api wrote: post #29

Earlier quoted context omitted.

Given that all these are ARX cores, I wonder if a fused ARX instruction could cover a wide range of them?

Probably. With a barrel shifter easily. Barrel shifters are a bit slower than wired shifts though, so for ultimate speed you'd end up with hardware shift amounts.

The advantage would be a single instruction that implemented the core of a wide range of things including BLAKE2, BLAKE3, Salsa, ChaCha, Speck, and more.

Re: BLAKE3 1.0

#44

Post by gsnedders »

kbumsik wrote: post #34
Croftengea wrote: post #9

Is this 1.0 ready indeed? a comment in blake3_neon.c: // TODO: This is probably incorrect for big-endian ARM. How should that work?

I know ARM in principal supports BE, but never heard real BE ARM products yet. Is there one? I am just curious.

It used to be much more common than it is nowadays; commonality between desktop systems used for development and production has slowly got rid of it. I know certain TVs and set-top boxes at least used to use big-endian, but mostly them long-ago migrated to little-endian nowadays.

Re: BLAKE3 1.0

#45

Post by staticassertion »

So what are the next steps for cryptographic hash functions? Is it going to just be "make even faster" ? Or are we chasing new properties, or stronger guarantees (or hopes?) of existing properties?

Re: BLAKE3 1.0

#46

Post by jedisct1 »

Croftengea wrote: post #9

Is this 1.0 ready indeed? a comment in blake3_neon.c: // TODO: This is probably incorrect for big-endian ARM. How should that work?

Looks like the 1.0 tag is only about the Rust implementation. The Changelog only lists Rust things.

The algorithm itself hasn't changed, which is great!

Re: BLAKE3 1.0

#47

Post by tyingq »

kbumsik wrote: post #34
Croftengea wrote: post #9

Is this 1.0 ready indeed? a comment in blake3_neon.c: // TODO: This is probably incorrect for big-endian ARM. How should that work?

I know ARM in principal supports BE, but never heard real BE ARM products yet. Is there one? I am just curious.

The hardware products support setting endianness at boot time. It's just a matter of OS's supporting BE mode.

Netbsd releases big endian versions that work on various ARM boards. Here's an announcement showing it works on an Rpi3 and below, for example: https://mail-index.netbsd.org/port-arm/2020/12/03/msg007117....

They said at the time that it's not yet working on the Rpi4 because of issues getting BE mode and UEFI to work together.

I don't know that it's used often, but it does exist.

Re: BLAKE3 1.0

#48

Post by st_goliath »

pornel wrote: post #42
Croftengea wrote: post #9

Is this 1.0 ready indeed? a comment in blake3_neon.c: // TODO: This is probably incorrect for big-endian ARM. How should that work?

1.0 is not the last and final version of a product. There can always be 1.0.1 or 1.1 or 2.0. Numbers are plentiful. Rust ecosystem is already overthinking 1.0 releases, which results in tons of crates having 0.x versions while being depended on as de-facto stable.

> 1.0 is not the last and final version of a product.

Of course, but if you bother to do semantic versioning, it should strive to be a stable one and not a "we are still experimenting" release.

IMHO knowing that something doesn't work, or isn't even implemented yet and will be addressed in the next release is OK for an 0.x.y release, but you shouldn't rush towards 1.0.0, already planing to release it "unfinished" and complete it later on in 1.0.1. That IMO kind of misses the point of the versioning semantics.

Re: BLAKE3 1.0

#49

Post by kebman »

unsigner wrote: post #18
doovd wrote: post #13

How does it compare against xxhash?

xxhash is not suitable for cryptographic purposes, but much faster.

I assume MD5 is in there too now. Just out of curiosity, what are the most common use cases for non-cryptographic hash functions?

Re: BLAKE3 1.0

#50

Post by cesarb »

Croftengea wrote: post #9

Is this 1.0 ready indeed? a comment in blake3_neon.c: // TODO: This is probably incorrect for big-endian ARM. How should that work?

What it being 1.0 means is that the API is stable. There might still be bugs in the implementation (no software is perfect), but once it's reached 1.0, it's hoped that the API is good enough and will not have to change for quite some time. If you look at these release notes for 1.0.0, they were all API changes.
Post reply on HN