13 ms·
BLAKE3 1.0
- ta988 5y agoBLAKE3 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.
- tomcam 5y agoThank you for the concise explanation and context.
- codetrotter 5y agoWould 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?
- tptacek 5y agoIt'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.
- leo_bloom 5y agoIf 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)?
- garmaine 5y agoHardware implementation.
- api 5y agoSecurity-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 with dedicated hardware but slower otherwise.
- maqp 5y agoOne 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".
- deleted 5y ago[deleted]
- api 5y agoGood 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.
- loeg 5y agoFederal government (FIPS) compliance.
- nmadden 5y agoAside from the various technical reasons others have given, I would like to say please have a look at the underlying design of SHA-3 - it’s really elegant, with so many applications beyond just hash functions. Ironically, I feel like SHA-3 should obsolete block ciphers like AES more than it obsoletes SHA-2. https://keccak.team/sponge_duplex.html https://keccak.team/sponge_duplex.html
- stouset 5y agoSHA-3 is extremely slow compared to common ciphers like AES and ChaCha20. Sponge functions might someday become the building blocks of symmetric ciphers, but it's unlikely that SHA-3 will (without hardware acceleration).
- nmadden 5y agoWell SHA-3 is a hash function, and indeed somewhat slow in software. But the team have since enormously expanded the primitives based on the same core design, with much better performance: https://keccak.team/sw_performance.html https://keccak.team/sw_performance.html You can also look at things like the Strobe framework, which builds essentially all of its symmetric crypto out of the SHA-3 core permutation: https://strobe.sourceforge.io/ https://strobe.sourceforge.io/
- oconnor663 5y agoFor historical reasons the SHA-3 standard made extremely conservative choices with its security parameters, particularly the number of rounds. The result is that SHA-3 is slower than SHA-2 in a lot of cases, but it didn't have to be that way. The same team of cryptographers published the KangarooTwelve hash in 2016, with half the number of rounds. I think that implies that SHA-3 could've been twice as fast with no loss in security. KangarooTwelve also introduces a tree structure, which enables a lot of the same optimizations that you see in BLAKE3, and the two designs are interesting to compare. (See section 7.6 of the BLAKE3 paper.)
- rstuart4133 5y ago> look at the underlying design of SHA-3 - it’s really elegant Yes, I imlemented a whole pile of hash functions, and I agree wholeheartedly. Whereas md5/sha seem to be have been designed by pouring a hodgepodge of complexity into a algorithm until something indecipherable turned up sha3 is simple. It's just a small number of easily understood operations, each with a clear purpose. Actually, it looked to me like it's been an evolution. md5 is insanely complex and the sha2 family got simpler, then then we get t sha3. Symmetric algorithms look to be going the same way. DES is insanely complex, AES less so, and Speck in almost unbelievably simple (look at the source code on Wikipedia https://en.wikipedia.org/wiki/Speck_(cipher) https://en.wikipedia.org/wiki/Speck_(cipher)). It seems to be an unfashionable viewpoint, but in my mind that simplicity makes Speck seem more worthy of trust that a lot of it's rivals. Mind you,
- GoblinSlayer 5y agoBLAKE3 has a large state, it's a tree hash, so you need to keep the tree of hashes, which is proportional to logarithm of the message size. SHA has fixed state for any message.
- ReactiveJelly 5y agoHuh, I didn't know that. https://github.com/BLAKE3-team/BLAKE3/blob/b404c851c284ed01f51a4606e1e13f51a89c2584/reference_impl/reference_impl.rs#L279 https://github.com/BLAKE3-team/BLAKE3/blob/b404c851c284ed01f... I peeked at the reference impl (380 lines of safe Rust) and found this. It has a 1,728-byte array for tree state, which is enough for 2 ^ 64 bytes. So in practice it's also fixed.
- Foobar8568 5y agoAnd I thought that JPA was slacking all this time drinking beers :o
- fsiefken 5y agoHopefully, like BLAKE2 it makes it into OpenSSL. One thing I was wondering about, OpenSSL 1.3 dropped support for SSL compression. Would that mean the compression function in BLAKE2 and future BLAKE3 integration couldn't be used or is this a different layer? https://en.wikipedia.org/wiki/BLAKE_(hash_function) https://en.wikipedia.org/wiki/BLAKE_(hash_function)
- pbsd 5y agoThe compression function in a hash function has nothing to do with the general data compression that TLS got rid of; it's a component of the hash that takes n bits and outputs less than n bits in an as unstructured manner as possible.
- AlotOfReading 5y agoIt won't be added to OpenSSL until it's standardized (see [1]). However there's an external provider available of somewhat dubious quality that adds support for it ([2]). [1] https://github.com/openssl/openssl/issues/11613#issuecomment-886790366 https://github.com/openssl/openssl/issues/11613#issuecomment... [2] https://github.com/J-Montgomery/blake3-prov https://github.com/J-Montgomery/blake3-prov
- Croftengea 5y agoIs this 1.0 ready indeed? a comment in blake3_neon.c: // TODO: This is probably incorrect for big-endian ARM. How should that work?
- kbumsik 5y agoI know ARM in principal supports BE, but never heard real BE ARM products yet. Is there one? I am just curious.
- tyingq 5y agoThe 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.html 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.
- howinteresting 5y agoWhy would anyone want to use BE mode at all?
- tyingq 5y agoHandy for testing that your code doesn't have any endian bugs that might crop up if someone tried compiling it on older RISC hardware? Or perhaps very slightly more efficient networking code, since big endian is the default order for many operations there?
- gsnedders 5y agoIt 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.
- chronogram 5y agoCould someone explain how these versions in hash algorithms work please? As I understand it version 0.3.7 from last year would produce the same hashes as version 1.0, so is the algorithm itself finished long ago and it's just the tooling that got updated over time?
- maqp 5y agoPlatform support is one aspect, another is re-implementing the algorithm in constant time to prevent side channel leaks. Also perhaps the code was edited to be stable under different fuzzers. Note: this is all speculation and generalization; I haven't looked at BLAKE3 commits at all.
- cesarb 5y agoIt's not the version of the BLAKE3 hash algorithm (which has been finished a long time ago and won't change anymore), it's the version of the reference implementation. The changes from 0.3.7 were just fixing a build issue on MSVC (this was release 0.3.8), and breaking changes to the API of the reference implementation, mostly removing parts of the API of the reference implementation which weren't stable enough for a 1.0 release.
- aidenn0 5y ago> 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)?
- pbsd 5y agoCorrect, the truncated versions of SHA2 are secure against length extension.
- maqp 5y agoSo 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.
- SAI_Peregrinus 5y agoSHA224, 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).
- tialaramex 5y agoImportantly 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.
- aidenn0 5y agoSHA-512/256 is what I default to since it is faster than SHA-256 but doesn't have the ridiculously long hash length of SHA-512
- adrian_b 5y ago
- doovd 5y agoHow does it compare against xxhash?
- unsigner 5y agoxxhash is not suitable for cryptographic purposes, but much faster.
- kebman 5y agoI assume MD5 is in there too now. Just out of curiosity, what are the most common use cases for non-cryptographic hash functions?
- adkadskhj 5y agoHash Map/Set keys is a common one, for example.
- Dylan16807 5y agoMD5 isn't particularly fast. Basic non-vector BLAKE3 beats it, and SHA1 beats it by even more.
- kebman 5y agoYes, I'm already aware of that, thank you. Could you please expand upon what the main use cases are for non-cryptographic hashes?
- Dylan16807 5y ago> Yes, I'm already aware of that, thank you. Oh. Well you said "in there too now" so I thought you were saying it was like xxhash in being insecure and fast. Even if that wasn't your intent, I wanted to make it clear to other people. > Could you please expand upon what the main use cases are for non-cryptographic hashes? Very fast hashes are good for hash maps, or even critical for them. That covers a huge amount of uses. And judging by the list on xxhash's website, a bunch of file transfer programs use it as well as bloom filter implementations, along with the databases that are probably using it for various maps.
- johnisgood 5y agoCan someone who knows Rust tell me what "<&[u8; CHUNK_LEN]" is exactly?
- loeg 5y agoReference (“&”) to a slice (“[]”) of CHUNK_LEN bytes (“u8”, unsigned 8-bit integers).
- johnisgood 5y agoThank you! What is "<"? Full line is: let mut chunks = ArrayVec::<&[u8; CHUNK_LEN], NUM_INPUTS>::new(); Edit: I probably should not comment to everyone one-by-one, so thank you all for the answers!
- chipsa 5y agoThat looks like a template instantiation to me. It's "<&[u8; CHUNK_LEN], NUM_INPUTS>" So the angle brackets are wrapping two arguments to the template.
- Tehnix 5y agoIn Rust, <> are used for type arguments. E.g. if you make a function with a generic type, it would be `fn my_func<T>(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.html#resolving-ambiguities https://doc.rust-lang.org/1.30.0/book/first-edition/generics...
- tlamponi 5y agoThose are used for generic in that case. Foo<T> 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 https://doc.rust-lang.org/book/ch10-01-syntax.html for a better explanation.
- staticassertion 5y agoSo 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?
- ogogmad 5y agoNot an expert, but it would be nice to provide security proofs. Not a must-have thing, perhaps, but certainly nice to have. One such example of a "provably secure" hash function is this one: https://en.wikipedia.org/wiki/SWIFFT#:~:text=In%20cryptography%2C%20SWIFFT%20is%20a,the%20LLL%20basis%20reduction%20algorithm https://en.wikipedia.org/wiki/SWIFFT#:~:text=In%20cryptograp.... Unfortunately, it's quite slow, and can't be used as a "random oracle". A lot of security proofs assume the random oracle model (but not for hash functions though, which are supposed to implement the "random oracle"). Strictly speaking, the model is incorrect, because a hash function is never a random oracle. I don't know if a suitable substitute has been found.
- tptacek 5y agoVariants 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 "misuse-resistance". SHA2 isn't broken; it remains quite strong. But it's a classic Merkle Damgard design, which means you can take the output of SHA2 and hash more data into it, which breaks simple keyed hash constructions like H(k, m) (this is why we have HMAC!). SHA3 and other modern hashes don't have this property; you can safely build simple keyed hash constructions out of them. You can see the same thing with AEADs (the SIVs vs. GCM) and with curves (Curve25519, for instance, where keys are --- don't @ me --- just simple random byte strings).
- cesarb 5y ago> 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.
- peepeepoopoo69 5y agoIn b4 blakecoin
- syrusakbary 5y agoThis is awesome. We have been using BLAKE3 in Wasmer for more than a year [1] and has been working great for us. We were trying to find a hash function for WebAssembly files that is crypto-safe. The only alternatives that were fast enough (>1Gbps) were not crypto-safe (ahash, murmur, crc32), so BLAKE3 was the obvious choice to not sacrifice on speed while getting a cryptographic hash function. [1] https://github.com/wasmerio/wasmer/pull/1140 https://github.com/wasmerio/wasmer/pull/1140
- comagoosie 5y agoYeah it's a bummer that a highwayhash is only cryptographically strong (but not cryptographically secure) as it can be significantly faster (3x). But BLAKE3 does seem to offer the best compromise when a cryptographically secure hash is required.
- 22c 5y ago> a highwayhash is only cryptographically strong (but not cryptographically secure) Can you let me know what you mean by strong vs. secure? When would you use one vs. the other? I've heard both of these terms used but they seem almost interchangeable[1]. I've also heard things like "this would be suitable for encrypting a password which is stored at rest" vs. "this could be suitable for a short lived one-time key", but I don't know what the correct terminology is there. [1] https://en.wikipedia.org/wiki/Strong_cryptography https://en.wikipedia.org/wiki/Strong_cryptography
- tptacek 5y agoIt's weird terminology. highwayhash aims to be cryptographically secure for its problem domain. But it's designed by (afaik) non-cryptographers, has weird security claims (they gauge security from statistical tests) and hasn't (afaik) received any formal peer review; it can also be instantiated in sub-secure hash sizes. You shouldn't use it to protect secrets, beyond the kind of incident secrecy you'd ask from something like SipHash. It would be better if people would be clear about this stuff; you see the same thing from the PCG RNG people, who say that their generator isn't a CSPRNG, but is somehow more secure than other non-CSPRNGs.
- Klasiaster 5y agoOne of my favorite aspects of the b3sum utility is that it has a --no-names flag: $ echo hi | b3sum --no-names 0b8b60248fad7ac6dfac221b7e01a8b91c772421a15b387dd1fb2d6a94aee438
- forty 5y agoSometimes genius is in the little things :)
- lbotos 5y agoI've noticed in my shells that when I do this I get the newline, so be wary of that if you are passing this hash around. I think echo -n should fix that on most platforms. I just tried your "hi" against https://connor4312.github.io/blake3/index.html https://connor4312.github.io/blake3/index.html and get hi/n - 0b8b60248fad7ac6dfac221b7e01a8b91c772421a15b387dd1fb2d6a94aee438 hi - 85052e9aab1b67b6622d94a08441b09fd5b7aca61ee360416d70de5da67d86ca
- anthk 5y agoUse printf.
- deleted 5y ago[deleted]
- PostThisTooFast 5y agoBy this time you should know better than to post titles without any descriptive information.
- xucheng 5y agoPerformance aside, I am wondering what is the current state-of-the-art cryptography analysis over BLAKE3?
- encryptluks2 5y agoWonder if they'll ever get this added to Alpine/Busybox as a default package? Even b2sum is missing.