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

31–40 of 126 posts

Re: BLAKE3 1.0

#31

Post by cornstalks »

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!

is used in Rust similar to how C++ uses them in templates.

ArrayVec::new() is a generic function that takes two generic arguments: a type (&[u8; CHUNK_LEN]) and a value (NUM_INPUTS). So ArrayVec is the structure, are the generic arguments (I replaced stuff with ellipses for brevity), and new() is the function call. :: is used as a "path" separator to syntactically differentiate between all these different parts.

Re: BLAKE3 1.0

#32

Post by stusmall »

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!

It is the opening of a generic type parameter. In this case ArrayVec[1] takes two, a type T for the element type and a const for the maximum size of the ArrayVec. The use of :: is affectionately known as "the turbofish" and is a way to give the compiler type information when it can't infer it.

1. https://docs.rs/arrayvec/0.7.1/arrayvec/struct.ArrayVec.html

Re: BLAKE3 1.0

#33

Post by [deleted] »

maqp wrote: post #22
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…

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 m…

[deleted]

Re: BLAKE3 1.0

#34

Post by kbumsik »

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.

Re: BLAKE3 1.0

#35

Post by ptomato »

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…

single-threaded blake3 is about 1.9x faster than (hardware) sha256 on my Zen 2 CPU.

Re: BLAKE3 1.0

#36

Post by SAI_Peregrinus »

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!

Generic type. Just like C++ or Java, really.

So `ArrayVec::` is an ArrayVec of items of type T, with capacity CAPACITY (of type usize, think size_t). An ArrayVec is a vector backed by a fixed-size array. Basically an array with convenience methods on it.[1]

In this case, T is `&[u8; CHUNK_LEN]` and `CAPACITY` is `NUM_INPUTS`. `&[u8; CHUNK_LEN]` is roughly equivalent to a `uint8_t* array[CHUNK_LEN]`.

So to simplify even more it's a fixed-size vector of byte arrays. The details of why it's not quite equivalent to that C code (how Rust checks the safety) are beyond the scope of this comment.

[1] https://docs.rs/arrayvec/0.7.1/arrayvec/struct.ArrayVec.html

Re: BLAKE3 1.0

#37

Post by magila »

nonagono wrote: post #24
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…

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

I'd like to see the benchmarks, including power draw. I suspect it is similar to soft ChaCha vs hard AES. A ChaCha software implementation can achieve similar speed as the AES hardware at the cost of significantly higher power draw due to pushing the AVX units at near maximum utilization.

Re: BLAKE3 1.0

#38

Post by SAI_Peregrinus »

maqp wrote: post #23
pbsd wrote: post #15

Earlier quoted context omitted.

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.

SHA224, SHA384, and SHA512/256 (yes, that's NOT the same as SHA512/SHA256, it's SHA512 truncated to 256 bits) are the truncated versions of SHA2. Rarely used. Confusingly named (in the case of SHA512/256).

Re: BLAKE3 1.0

#39

Post by api »

maqp wrote: post #22
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…

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 m…

Good point. Misuse resistance is also why I am a fan of SIV constructions for stream ciphers, since "repeat a nonce = instant death" is a footgun.

Repeating a nonce is easier than you might think if you are using threads and accessing a nonce counter non-atomically, have a bad RNG, are on an embedded platform with bad RNG seeding, have a bug that overwrites some memory used to generate nonces, or just transfer a ton of data with the same key (birthday attack). SIV makes nonce reuse fairly benign. The only consequence is that if you happen to reuse a nonce with two identical messages, an attacker could tell that you sent the same message twice. That's generally not catastrophic and statistically is far less likely than repeating a nonce with different messages. Repeating a nonce with different messages generally does nothing in SIV.

You could theoretically use SIV with no nonce, with the only consequence being that an attacker could always tell if you sent duplicate messages. Not sure why you'd do that though.

IMHO since we now have ciphers that are probably "unbreakable for the foreseeable future" (e.g. AES and ChaCha) we should probably concentrate on creating and popularizing misuse-resistant constructions as much as possible. It's good to remove footguns.

Re: BLAKE3 1.0

#40

Post by tialaramex »

maqp wrote: post #23
pbsd wrote: post #15

Earlier quoted context omitted.

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.

Importantly SHA-512/256 does not mean "Either of these two different functions" but instead another function, which is similar to (but slightly different from) performing SHA-512 and then throwing away all but 256 bits.

This prevents length extension because you've thrown away 256 bits the attacker needs to perform their attack.

Post reply on HN