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

21–30 of 126 posts

Re: BLAKE3 1.0

#21

Post by chronogram »

doovd wrote: post #13

How does it compare against xxhash?

xxHash is not cryptographic, whereas BLAKE3 is. You can use the former for things such as file integrity from errors checking, and the latter for file integrity from malicious intent checking. Or, one is for the file system and the other is for the internet. You should use something altogether slower like bcrypt for passwords though, because then you don't want to have speed in case someone has a copy of your database with a million passwords and tries to dictionary attack those million.

Re: BLAKE3 1.0

#22

Post by maqp »

api wrote: post #5
leo_bloom wrote: post #3

If I had a BLAKE3 implementation available in the programming language of choice, is there any reason to still prefer the SHA family over it (for integrity checks, not for password hashing, as mentioned in the readme)?

Security-wise they are roughly equivalent. While SHA has had more eyes on it I doubt either construction will ever be practically broken at hash sizes like 384 or 512 bits. Someone may find an "academic break" at some point. BLAKE3 is faster, sometimes a lot faster, on hardware without SHA instructions. On hardware with SHA instructions SHA may be faster. Same as the AES story where AES is faster than ChaCha on CPUs…

One aspect of security is also the misuse resistance. You can of course create a secure MAC with SHA256 in the HMAC configuration, but it usually takes a masters level course on cryptography to know what is Merkle-Damgård construction, and why it's design is imperfect:

You can't just do SHA256(key + message) to generate a safe MAC. With BLAKE (and all SHA3 finalists) you can do that safely.

It's true every time you make the algorithm more misuse resistant, the universe will come up with a more dunning Kruger, but despite that, it's something that can actually improve, the security is already more than adequate: Like Schneier so eloquently put it, "we're building a fence for sheep, it doesn't matter if the fence pole is a mile or two miles high".

Re: BLAKE3 1.0

#23

Post by maqp »

pbsd wrote: post #15
aidenn0 wrote: post #12

> Secure, unlike MD5 and SHA-1. And secure against length extension, unlike SHA-2. Aren't some variants of SHA-2 secure against length extension (like SHA512/256)?

Correct, the truncated versions of SHA2 are secure against length extension.

So SHA224 and SHA384? They're not exactly common. SHA256 is pretty much the standard and SHA512 is usually used for hashing larger files due to the larger block size and thus faster speed. I don't think I've ever seen 224/384 used anywhere.

Re: BLAKE3 1.0

#24

Post by nonagono »

api wrote: post #5
leo_bloom wrote: post #3

If I had a BLAKE3 implementation available in the programming language of choice, is there any reason to still prefer the SHA family over it (for integrity checks, not for password hashing, as mentioned in the readme)?

Security-wise they are roughly equivalent. While SHA has had more eyes on it I doubt either construction will ever be practically broken at hash sizes like 384 or 512 bits. Someone may find an "academic break" at some point. BLAKE3 is faster, sometimes a lot faster, on hardware without SHA instructions. On hardware with SHA instructions SHA may be faster. Same as the AES story where AES is faster than ChaCha on CPUs…

According to zooko, one of the authors, in new-ish cpus blake3 beats sha256 even with hardware acceleration: https://twitter.com/zooko/status/1419403567320821760

Re: BLAKE3 1.0

#25

Post by SAI_Peregrinus »

api wrote: post #5
leo_bloom wrote: post #3

If I had a BLAKE3 implementation available in the programming language of choice, is there any reason to still prefer the SHA family over it (for integrity checks, not for password hashing, as mentioned in the readme)?

Security-wise they are roughly equivalent. While SHA has had more eyes on it I doubt either construction will ever be practically broken at hash sizes like 384 or 512 bits. Someone may find an "academic break" at some point. BLAKE3 is faster, sometimes a lot faster, on hardware without SHA instructions. On hardware with SHA instructions SHA may be faster. Same as the AES story where AES is faster than ChaCha on CPUs…

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.

Re: BLAKE3 1.0

#27

Post by chipsa »

johnisgood wrote: post #19
loeg wrote: post #17

Earlier quoted context omitted.

Reference (“&”) to a slice (“[]”) of CHUNK_LEN bytes (“u8”, unsigned 8-bit integers).

Thank you! What is " let mut chunks = ArrayVec:: ::new(); Edit: I probably should not comment to everyone one-by-one, so thank you all for the answers!

That looks like a template instantiation to me. It's "" So the angle brackets are wrapping two arguments to the template.

Re: BLAKE3 1.0

#28

Post by Tehnix »

johnisgood wrote: post #19
loeg wrote: post #17

Earlier quoted context omitted.

Reference (“&”) to a slice (“[]”) of CHUNK_LEN bytes (“u8”, unsigned 8-bit integers).

Thank you! What is " let mut chunks = ArrayVec:: ::new(); Edit: I probably should not comment to everyone one-by-one, so thank you all for the answers!

In Rust, are used for type arguments. E.g. if you make a function with a generic type, it would be `fn my_func(arg1: T) { ... }`

Now, what we have here is commonly referred to as the Turbo Fish[0] operator (the `::` syntax). In this case it's there to help let the compiler know which concrete type you want to create your new `ArrayVec` with :)

[0]: https://doc.rust-lang.org/1.30.0/book/first-edition/generics...

Re: BLAKE3 1.0

#29

Post by api »

SAI_Peregrinus wrote: post #25
api wrote: post #5

Earlier quoted context omitted.

Security-wise they are roughly equivalent. While SHA has had more eyes on it I doubt either construction will ever be practically broken at hash sizes like 384 or 512 bits. Someone may find an "academic break" at some point. BLAKE3 is faster, sometimes a lot faster, on hardware without SHA instructions. On hardware with SHA instructions SHA may be faster. Same as the AES story where AES is faster than ChaCha on CPUs…

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?

Re: BLAKE3 1.0

#30

Post by tlamponi »

johnisgood wrote: post #19
loeg wrote: post #17

Earlier quoted context omitted.

Reference (“&”) to a slice (“[]”) of CHUNK_LEN bytes (“u8”, unsigned 8-bit integers).

Thank you! What is " let mut chunks = ArrayVec:: ::new(); Edit: I probably should not comment to everyone one-by-one, so thank you all for the answers!

Those are used for generic in that case.

Foo supports more types, often limited with certain traits they must support.

Here it's passing the actual type on instantiation, in that case there are two types: an u8 slice and a number of inputs, just guestimating the latter as I did not check the original definition in the source.

See https://doc.rust-lang.org/book/ch10-01-syntax.html for a better explanation.

Post reply on HN