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

81–90 of 126 posts

Re: BLAKE3 1.0

#81

Post by tptacek »

cesarb wrote: post #75
tptacek wrote: post #65

Earlier quoted context omitted.

Variants of "make even faster" (including "making keys smaller" or "allow to run on more limited hardware") is most of what drives new core cryptographic primitives. There's a tweet from one of the BLAKE authors (@veorq) saying what I think a bunch of cryptography engineers believe, that it's unlikely that SHA2 will ever be directly broken. There are security improvements in new primitives, often based on a notion of…

> Curve25519, for instance, where keys are --- don't @ me --- just simple random byte strings IIRC, just simple random byte strings with a couple of specific bits forced to 0 and another couple of specific bits forced to 1.

Don't @ me! :)

Re: BLAKE3 1.0

#82

Post by maqp »

staticassertion wrote: post #68
maqp wrote: post #22

Earlier quoted context omitted.

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…

> You can't just do SHA256(key + message) to generate a safe MAC. Can you explain this?

What @dagenix said. See e.g. Thomas Pornin's answer here https://crypto.stackexchange.com/a/3979 for more details

Re: BLAKE3 1.0

#83

Post by pbsd »

tptacek wrote: post #65
staticassertion wrote: post #45

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?

Variants of "make even faster" (including "making keys smaller" or "allow to run on more limited hardware") is most of what drives new core cryptographic primitives. There's a tweet from one of the BLAKE authors (@veorq) saying what I think a bunch of cryptography engineers believe, that it's unlikely that SHA2 will ever be directly broken. There are security improvements in new primitives, often based on a notion of…

There is also more/different functionality (e.g., designing a permutation or a tweakable blockcipher instead of a plain blockcipher, or a hash based on those), or better analyzability---making primitives that are simpler to "prove" (or make an argument for) secure against some classes of attacks.

And these days there are also the primitives purposefully designed to run in blockchain....whatever it is, using large GF(p) or GF(2^n) field operations as components. This mostly falls under the "more limited hardware" umbrella.

Re: BLAKE3 1.0

#84

Post by st_goliath »

wongarsu wrote: post #57
st_goliath wrote: post #48

Earlier quoted context omitted.

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

By that logic, would you ever release a 1.0? Imho, just having a stable API that works on x86-64 without optimizations would be enough for a 1.0 release. Having a stable API with highly optimized implementation for x86 and common ARM systems is a lot for a 1.0 release. The limitations on ARM BE could be better documented though.

> By that logic, would you ever release a 1.0?

Of course! But you need a well defined feature set you want to have for 1.0 and stick to that. The scope of that is up to the people who run the project, I did not make any demands what this specific software should include in their 1.0 release. I did not say that it needs to be perfect, include all bells and whistles imaginable, all possible CPU optimizations and smell nice in order to merit an 1.0 release. What I'm saying is, that you should make an effort to ensure that the implementation of this feature set is somewhat stable.

So rather to the contrary, I would also suggest to keep the scope of a 1.0 release smaller than that, just like you suggested:

> Imho, just having a stable API that works on x86-64 without optimizations would be enough for a 1.0 release.

Releasing an un-optimized reference implementation as 1.0, or maybe only one optimized code path for x86_64 would IMO be perfectly fine. If they decide they really want optimizations for all kinds of CPUs in the 1.0 release, also fine with me. What the scope for 1.0 should or should not be is their choice. And it's also completely besides my point.

I'm specifically arguing against doing what pornel seems to imply: My point is, you shouldn't release an implementation you know misbehaves in some cases, because "we can fix it later".

I'm a fan of semantic versioning. And I firmly believe that in addition to API & ABI stability, for a major version release, some effort should be taken to iron out the implementation of that API as well. Of course bugs can, and will, crop up later and can be fixed with a patch level release, but IMO you shouldn't rush towards a 1.0 release with a backlog of known bugs for the next release. That's what I meant with "kind of misses the point of the versioning semantics".

Re: BLAKE3 1.0

#86

Post by maqp »

api wrote: post #39
maqp wrote: post #22

Earlier quoted context omitted.

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…

Hadn't really looked into SIV as I've only written stuff that always generates XChaCha nonces with getrandom but yeah I can totally see why the platform etc. could cause issues that lead to nonce-reuse. This was most informative post, thank you so much!

Re: BLAKE3 1.0

#87

Post by infogulch »

staticassertion wrote: post #45

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?

An associative / non-commutative hash function over lists. This would mean that the hash of a list, H(list1), could be "concatenated" with another hash, H(list2), to find the hash of the concatenation and be equivalent to H(list1+list2). I think such a construction could be huge for cryptographic verification of data in data structures while avoiding baking in incidental details about the data structure itself.

I hesitate to link to it because I already know of a potential attack, but I played around with an implementation that does this with matrix multiplication over galois field elements of reinterpreted hash digests [1]. I mean, the associative / non-commutative part works nicely, but I expect that factoring the matrix is possible which makes it utterly useless as a cryptographic primitive [2]. "don't roll your own crypto" would apply, but I'm obviously not using such an academic exercise in production.

[1]: https://blog.infogulch.com/2021/07/15/Merklist-GF.html

[2]: https://math.stackexchange.com/questions/4200988/using-rando...

Re: BLAKE3 1.0

#88

Post by tptacek »

codetrotter wrote: post #72
ta988 wrote: post #2

BLAKE3 is a successor to BLAKE2 (used by wireguard for example) a really fast crypto hash function. It uses binary trees and other approaches that allow to use SIMD and multithreading.

Would a future version of the Wireguard protocol and implementations benefit from switching to BLAKE3? Enough so that it would make sense for them to make the switch either, as the only difference between now and then, or alongside other changes they may have in mind? And if it makes sense, are they planning on doing it?

It's unlikely, since part of the design of WireGuard is not to allow negotiation of primitives. They'd version the whole protocol, and BLAKE2->BLAKE3 is not a strong incentive to do that.

Re: BLAKE3 1.0

#89

Post by api »

maqp wrote: post #86
api wrote: post #39

Earlier quoted context omitted.

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…

Hadn't really looked into SIV as I've only written stuff that always generates XChaCha nonces with getrandom but yeah I can totally see why the platform etc. could cause issues that lead to nonce-reuse. This was most informative post, thank you so much!

SIV is usually done with AES/GMAC constructions but you could do it with ChaChaPoly just fine.

The big downside is that it requires two passes on encrypt: one to create the MAC and derive the IV and another to encrypt. The overhead for this is small for message/packet based systems though since after pass one the data will be sitting hot in the processor's L0 cache. Decryption can be done in one pass.

Re: BLAKE3 1.0

#90

Post by [deleted] »

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.

[deleted]
Post reply on HN