Hot answers tagged sha256
40
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 ...
14
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 ...
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
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 ...
5
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 ...
5
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 ...
5
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 ...
5
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 ...
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
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 ...
5
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" ...
5
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 ...
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 ...
4
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$ ...
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
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 ...
4
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 ...
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
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 ...
3
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 ...
3
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 ...
3
Yes, authenticate the IV. If an attacker changes the IV while keeping the rest of the ciphertext intact, they'll change the message. Just because they can't change the message to an arbitrary value doesn't mean they can't cause harm (if nothing else, they can send random junk until they hit a valid command or a bug in your parser, or feed you invalid data).
...
3
This seems like it may be an unnecessary complication. Why not encrypt the whole file at once, and HMAC the entire result? Or alternatively, use an encryption mode that has this built in, like AES-GCM?
But to answer your original question, no, it does not introduce any weaknesses. If it did, knowing the value to within 16 bytes wouldn't be much of a ...
3
Yes, feasibility to guess the plain text size might be a serious vulnerability in real life scenarios. For instance, in traffic analysis the approximate length of the messages in a communication, might reveal enough information about what is communicated, for it to be possible to deduce the gist of it. If such threats exist in your case, however, you will ...
Only top voted, non community-wiki answers of a minimum length are eligible
