# Tag Info

## Hot answers tagged sha256

44

The risk of collision is only theoretical; it will not happen in practice. Time spent worrying about such a risk of collision is time wasted. Consider that even if you have $2^{90}$ 1MB blocks (that's a billion of billions of billions of blocks -- stored on 1TB hard disks, the disks would make a pile as large of the USA and several kilometers high), risks of ...

16

If taking the first or last bits of a SHA-256 output made any difference, it would be viewed as a serious blow against the security of SHA-256. Right now, no such weakness is known in SHA-256. So, as far as we know, you can use whatever bits you want. If you need a more "administrative" answer, have a look at SHA-224 (also specified in FIPS 180-3). This is ...

9

Yes, SHA-256 is currently the de facto standard. The "why" is that MD5 and SHA-1 are unsafe and the only algorithm left which has been extensively studied and deployed and which nobody has found a significant attack against is SHA-256. (There is also SHA-512, but people seem to regard it as being overkill.) There is widespread uncertainty about whether ...

7

The definitions given in FIPS 180-4 are $$\mathtt{Maj}(x, y, z)=(x∧y)⊕(x∧z)⊕(y∧z)$$ $$\mathtt{Ch}(x,y,z)=(x∧y)⊕(¬x∧z)$$ where $∧$ is bitwise AND, $⊕$ is bitwise exclusive-OR, and $¬$ is bitwise negation. The functions are defined for bit vectors (of 32 bits in case fo SHA-256). I'm positive $\mathtt{Maj}$ stands for majority: the result is set according to ...

7

With the message padding scheme of SHA-2/SHA-256 as it stands (add one 1 bit, a minimal number of 0 bits so that the overall padded message will end on a block boundary, then the original message length over some fixed number of bits), I know no attack enabled by allowing a different IV. However, allowing an arbitrary IV renders ineffective one of the two ...

6

Your cipher looks a bit like the output feedback mode of operation for block ciphers. While OFB for block ciphers is considered safe (as long as it is used right), OFB for a hash function like you are using it has the problem that the key is only used at the start, to generate the "initialization vector", not at each step of the algorithm. Thus, as ...

6

First of all, this no block cypher at all. It's a stream cypher. Thus you can use every key only once, and you can't use any cypher modes built on block cyphers. Your scheme is vulnerable to a known plaintext attack. If the attacker knows 32 aligned(or 63 unaligned) bytes of plaintext, he can calculate the state of your cypher: $S_i = P_i \oplus C_i$ ...

6

If you want to use Skein (one of the SHA-3 candidates) anyway: it has a "mode of operation" (configuration variant) for tree hashing, which works just like your method 2. It does this internally of the operation, as multiple calls of UBI on the individual blocks. This is described in section 3.5.6 of the Skein specification paper (version 1.3). You will ...

6

Actually a tree-based hashing as you describe it (your method 2) somewhat lowers resistance to second preimages. For a hash function with a n-bit output, we expect resistance to: collisions up to 2n/2 effort, second preimages up to 2n, preimages up to 2n. "Effort" is here measured in number of invocations of the hash function on a short, "elementary" ...

6

To add to @poncho's answer: SHA-256 is a Merkle-Damgård construction, quite similar to SHA-1 and MD5, only with many more internal operations. When the attacks on MD5 were first published, there was some fear that they could be extended to similar hash functions, and they were indeed applied to SHA-1, but with much less success (the attack is still ...

6

The only thing that immediately comes to mind is that if you know the SHA-256d of some string X, you can compute the SHA-256d of the string SHA256(X), even without knowing anything else about X. In some sense, this is similar to the "length extension" attack, in that it allows you, given Hash(X), compute Hash(F(X)), for some function F. Whether this is a ...

6

First let's take care of your encoding related issues: You can't simply say one byte equals one char. You need an encoding to transform between these, where the properties depend on that encoding. When transforming between normal text and bytes, UTF-8 is a good choice. One character will correspond to a variable amount of bytes that way. You'd use this to ...

6

Is it possible that hashing "foobar" recursively an infinite amount of times will eventually yield any arbitrary hash value? I very much doubt it. A simple demonstration of this logic can be done through the birthday paradox. Suppose we log each successive recursive SHA-256 on "foobar" in a table. We can ask ourselves what the probability is that our ...

5

The proper way to do things in this case would be to feed the password to a key derivation function such as PBKDF2. PBKDF2 (and other KDFs) is designed specifically for what you describe. Since you are using AES-128, you would want a 128-bit output from PBKDF2, then feed that into AES. Now, stepping back a little, the best advice I can give you is to not ...

5

Yes, currently SHA256 is pretty much de facto standard strong cryptographical hash (with about the only real competition being SHA384/SHA512). The reason for that, as far as I can tell, it the perceived lack of alternatives. When Ms. Wang published her attack, she managed to break the great majority of hash functions out there. A number of hash functions ...

5

To have approximately a 50% chance of a collision, you'd need $2^{128}$ data blocks. This comes from the birthday problem. Are you anticipating your list to be that large? I would doubt it as that would be an astronomical amount of data (much, much more than a petabyte). That said, it is very, very unlikely that a collision for MD5 would also be a collision ...

5

The risk of collision is only theoretical; it will not happen in practice. Except in one particular instance. The description given implies that this system is going to be some form of de-duplicating filesystem or backup system. For most users, the collision risk is tiny. But, for one particular class of users, there is a much larger risk. Those ...

5

SHA-256 uses an internal compression function $f$ which takes two inputs, of size 512 and 256 bits respectively, and outputs 256 bits. Hashing works like this: Input message $M$ is first padded by appending between 129 and 640 bits (inclusive), resulting into a padded message $M'$ whose length (in bits) is a multiple of 512. $M'$ is split into $n$ ...

5

Yes, your MAC is secure. It's probably not quite as secure as you're expecting it to be, and it's not a construction I would recommend to anyone, but it should be secure. Let's start with a simpler variant: $F_K(M) = E_K(H(M))$ where $H(\cdot)$ is a 128-bit collision-resistant hash (say, the first 128 bits of SHA1) and where $E_K(\cdot)$ is a 128-bit ...

5

I remember this document -- it is the draft which circulated among cryptographers when NIST (or NSA) was preparing some new standard hash functions and was asking for comments about their proposed scheme. This document is obviously a rather hastily thrown together specification which is not, in any way, official (it has no attribution, no name, no 15-page ...

4

The SHA-256 algorithm works by applying an encryption function in Davies-Meyer mode and Merkle-Damgård chaining. Merkle-Damgård works by first dividing the message to-be-hashed into chunks. In the case of SHA-256 these chunks are 64 octets long. Because Merkle-Damgård chaining is used, the internal state after processing the first 64 octet chunk depends only ...

4

Summary: I don't know of any good reason why it has to be this way. In practice, I don't think it is necessary to inject the password into every iteration. As far as I know, I think the construction would still be secure (in practice) if you used the salt and password only in the input to the first iteration, and then just repeatedly hashed the result many ...

4

Distinguishing $H^2$ from a random oracle (essentially an ideal hash) is much cheaper that it should, namely $2^{64}$ for $\operatorname{SHA-256d}$. This doesn't lead to any practical attacks, but it hurts security proofs relying on indistinguishably. It is easy to avoid this problem by using distinct prefixes for the inner and outer hash, so I see little ...

4

This started as a comment to CodeinChaos's answer, but did not fit. I'm trying to regurgitate, in layman's terms, my understanding of the consequences on $\operatorname{SHA-256d}$ of the paper he quotes: Dodis, Y., Ristenpart, T., Steinberger, J., & Tessaro, S. (2012). To Hash or Not to Hash Again? (In) differentiability Results for H2 and HMAC. This ...

4

I'll assume that "sha256hmac" designates HMAC using SHA-256 as the underlying hash function. HMAC is used for its intended usage: the first parameter privatekey is a key, I assume random and secret, of fair length (128-bit); the second parameter word is a (possibly public) message; output is a (possibly public) cryptogram. Observing any number of (word, ...

4

Instead of that home-grown scheme, I would use PBKDF2 instead if you simply are sold on the idea of iterated hash schemes. It uses an such a scheme, although not exactly the one you have described, and is well-studied and considered secure. However, PBKDF2 doesn't offer many advantages over bcrypt, as PBKDF2 is still vulnerable to GPU and FPGA/ASIC ...

3

Somewhat simplified, if that were possible, you would have found a vulnerability in SHA-256. The kind of attack you're talking about is called a preimage attack, ie figuring out information on the original message from the hash. There have been some attacks of that kind against a weakened version of SHA-256 but no successful ones against the standard ...

3

To the best of our knowledge, SHA256 does not leak any additional information from related hashes. On the other hand, the state of "our knowledge" might not be that comprehensive; this security property of SHA256 cannot be derived from the base security assumptions of a hash function (preimage resistance, second preimage resistance and collision ...

3

The two proposals in the question have their advantages and disadvantages. Using MD5 There are three major types of attacks to worry about. Preimage attacks: given $h$ find $m$ such that $H(m)=h$ Second preimage attacks: given $m$ find $m'\neq m$ such that $H(m)=H(m')$ Collision resistance: find any $m$ and $m'$ such that $H(m)=H(m')$ ...

3

In step 4.1 of the algorithm: Counter is expected to be a 1 byte binary value no_of_bits_to_return is a 4 byte bigendian binary value input_string is a variable length binary value $||$ is concatination (just like you guessed) So, Hash(&bytearray) would be appropriate. The trickiest part is the 'no_of_bits_to_return' -- that's bigendian (and so a ...

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