Hot answers tagged

44

(Disclosure: I'm one of the authors of BLAKE2, but not BLAKE.) Here are the slides from a presentation I gave at Applied Cryptography and Network Security 2013 about this. (Note: the performance numbers in those slides are obsolete — BLAKE2 is even faster now than it was then.) The slides include quotes from NIST's 3rd-round Report on the SHA-3 Competition ...


36

Blake-2 was not part of the SHA-3 competition, Blake, its predecessor was. Blake-2 is approx 1.3 to 1.7 times faster than Blake in software, with the advantage best for the 512-bit digests. Performance A software performance comparison between the two SHA-3 finalists shows that Blake is about 3 times faster than Keccak on a modern CPU for a 512-bit hash, and ...


13

If you take a look at the Password Hashing Competiton, you can see, that most of the schemes use Blake2b, some of them uses SHA-512, none of them uses SHA-256. Blake2b is optimized for 64-bit platforms and this property fits exactly the requirement of a password hashing scheme. SHA-512 would also be OK, but SHA-256 would be much slower in software and the ...


12

I'm answering the following which was asked in the original question: Why is stock chacha20 not good as a cryptographic hash? Why create BLAKE? Why not simply apply the one-way compression function concept on raw chacha20, specifically its quarterround() function, unaltered. TL;DR: Chacha was meant as a stream cipher, it needs a different kind of security ...


11

Yes, you should choose BLAKE2 instead of MD5. Any of the BLAKE2 variants—BLAKE2s, BLAKE2b, BLAKE2sp, BLAKE2bp—is an improvement over MD5, even if you just use them for 128-bit digest sizes like MD5, although it is generally better to use at least 256-bit digests. BLAKE2b is a good default; BLAKE2s is slower on 64-bit systems but friendlier to 32-bit ...


9

Note that Blake2's security goals are a superset of those of SHA-256: SHA-256 is conjectured to be collision resistant, preimage resistant and second preimage resistant. Blake2 is conjectured to be random oracle indifferentiable, a stronger property that SHA-256 doesn't have, and which implies the three classic hash function properties. So yes, this ...


7

OK, so the core ChaCha primitive (for any fixed number of rounds) is a function $\operatorname{ChaCha}: \{0,1\}^{256}\times \{0,1\}^{64}\times\{0,1\}^{64}\to \{0,1\}^{512}$ which is believed to be a secure PRF when the first input is the key. So now that we know what ChaCha is, for the desired functionality of hashing: At a fundamental level it's unclear ...


6

Actually, what you want is possible with plain Blake2b - if your implementation supports the full specification (PDF) (which is marked as optional by RFC 7693). If this is the case, you'd do the following mappings: Feed the info data into the personalization -part of the parameter block. Feed the salt data into the salt -part of the parameter block. Feed ...


5

Why is stock chacha20 not good as a cryptographic hash? You haven't specified what kind of ‘cryptographic hash’ you mean, but since you're comparing it to BLAKE, it sounds like you're looking for collision resistance, which was the central motivation for the whole SHA-3 competition in the first place after MD5 and SHA-1 fell to collision attacks in 2004/...


5

BLAKE2 is not open-source. BLAKE2 is a specification. The state is shuffled one last time after having set the final bit, ensuring that a small change, even a single bit, yields a completely different output, that cannot be reverted. A length extension attack means that knowing M and Hk(M), you may be able to compute Hk(M||E) without knowing the key k. ...


5

The answer is (as always): It depends. If you want pseudorandomness, then XOR is a good combiner (actually even optimal). However, if you want collision resistance then XOR is a really bad combiner because afaik you cannot show that collision resistance of the two hash functions implies collision resistance of the combiner. If you think about it, a collision ...


5

Sponge Construction In sponge construction, the block size $b$ has two parts, $r$ is the rate and it is the written part and $c$ capacity is the untouched part by the input/output, $b= c+r$ The output is taken from $r$ in the squeezing stage. Therefore not all of the $b$ is the output. This prevents the length extension attack like in the truncations of ...


4

You should always use config options to select the output size of a hash function. If you need a standard output size (e.g. 224, 256, 384, 512 bit) use the recommended parameter set. This mainly applies to standards like SHA-3, where if you use SHA-3-256 you'll get a different (more standard output) than with "Keccak-256", SHA-3-512/256 and SHAKE128-256, ...


4

Shortening the definition of HKDF (for sufficiently short output) it is just: HMAC(HMAC(XTS, SKM), CTXinfo || 0) (format: HMAC(key, msg)) Since this is barely more complicated than your example of Blake2B(input: (Salt || Info), key: IKM) I would recommend doing that instead. I know you explicitly stated you don't have access to HKDF but I don't see the ...


4

The Analysis of BLAKE2's Modes of Operation paper gives a PRF bound for keyed BLAKE2b with a key of size $k$, under the assumption that the underlying block cipher is ideal (Corollary 3): $$ \text{Adv}^{\mathrm{PRF}}_{\text{BLAKE2b}}(\mathcal{D}) \le \frac{q^2}{2^{1024}} + \frac{2q^2}{2^{512}} + \frac{q}{2^{256}} + \frac{q}{2^k}\,. $$ Here, $q$ is the ...


4

I guess that reducing the rounds is indeed the main reason to call it less secure. Generally attacks are over a specific number of rounds. If better attacks are found then the reduction of rounds could mean that Blake2 gets broken while Blake is not. How secure something is is up for discussion for the simple reason that we cannot predict the future. I ...


4

I am struggling to understand why blake2b is faster than blake2s, despite that blake2b is 512 bits hashing. Comparing is not easy. They designed BLAKE2b for 64-bit platforms including NEON enabled ARMs. That can produce between 1 and 64-byte digest BLAKE2s for 8- to 32-bit platforms. That can produce between 1 and 32-byte digest They are fast on their ...


3

If in doubt, use BLAKE2, not MD5. If security is necessary, then you should avoid MD5. It has a weakness where someone can create two files which differ, but which have the same MD5 digest. This is called a collision attack. If you simply want to check for duplicate files or files that are accidentally corrupted, then MD5 is still acceptable. BLAKE2 is a ...


3

This is already covered by Ella's response, but in short the added nonlinearity at the start buys you very little in terms of security, compared to its cost in number of operations. It would be more effective, and make for a simpler design, for example, to trade all these constant xors by an extra round. Since that part of BLAKE was not pulling its own ...


3

The approach is not so much ‘compromising security in the name of speed’, but rather engineering something the world is confident provides at least a prescribed security level, and then tweaking it to be faster without compromising confidence in that security level. After years of cryptanalysis during the SHA-3 competition, the best attacks on BLAKE were ...


3

From reading the Argon2 paper, it would be safe, but not wise, to use SHA-256 instead of Blake2: We allow to choose another compression function G, hash function H, block size b, and number of slices ℓ. However, we do not provide this flexibility in a reference implementation as we guess that the vast majority of the users would prefer as few parameters ...


3

You are right that the padded message by itself is ambiguous. But the Blake2 compression function does not just take the message block and the chaining value as input. It also takes a finalization flag (to mark the last block and prevent length extensions) and the message size in bytes. Passing the size to the non final blocks mainly serves to prevent ...


3

Let us see an example of how cryptographic hash functions are used in Zero-Knowledge Proof Systems. Following code written in Zokrates DSL Toolbox is an example of computing a Hash using Zero-Knowledge Proof systems. The programming instructions are compiled first. Then we will proceed to the setup of the arithmetic circuit through the setup. Then we export ...


3

All from the BLAKE2 paper BLAKE2: simpler, smaller, fast as MD5 First of all BLAKE2b is optimized for 64-bit platforms — including NEON-enabled ARMs — and produces digests of any size between 1 and 64 bytes. and from the abstract of the article BLAKE2 is often faster than MD5, yet provides security similar to that of SHA-3: up to 256-bit collision ...


3

HAsh Iterative FrAmework (HAIFA) proposed by Biham and Dunkelman, in 2005-2007. The main idea of the work is to fix the flaws of Merkle and Damgård (MD) construction. Interestingly, Invented by Ralph Merkle and Ivan Damgård working independently and presented in the main Cryptography Conference. R. Merkle. A certified digital signature, CRYPTO '89. I. ...


2

4 rounds of Blake2b is essentially equivalent to 8 rounds of ChaCha in terms of complexity (a Blake2 round is close to a ChaCha double-round), and that has not yet been broken. Like Richie Frame wrote in a comment, NORX also claims to get away with 4 Blake2 rounds. One reason ciphers get away with less is that in hash functions all inputs are known and (...


2

256-bit confidentiality Let's assume that we're using AES256-CTR and a 256-bit hash. A new 256-bit key $S$ is derived for each message. Since AES256 requires a 256-bit key, there are no extra bits in $S$ available for use in the nonce, suggesting that a constant nonce is used. I believe this is vulnerable to a multi-target attack. The first block of ...


2

I want to run each of these unique integers through a hash function, with the objective of 1) maintaining the uniqueness, 2) obscuring the underlying integer value and 3) having a hash output with a length of <= 34. You need to be very clear about what you mean by "obscuring." The basic problem here is that your values look like they're likely to be ...


2

BLAKE2b is an excellent option for a fast, modern hash function. BLAKE2b is optimized for 64-bit platforms, while BLAKE2s is optimized for 32-bits and lower. The p versions are optimized for parallel cpus. Most applications using BLAKE use the BLAKE2b variant, but either will be secure, far more so than MD5.


Only top voted, non community-wiki answers of a minimum length are eligible