Tag Info

Hot answers tagged

47

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


21

SHA-512 truncated to 256 bits is as safe as SHA-256 as far as we know. The NIST did basically that with SHA-512/256 introduced March 2012 in FIPS 180-4 (because it is faster than SHA-256 when implemented in software on many 64-bit CPUs). SHA-224 is just as safe as using 224 bits of SHA-256, because that's basically how SHA-224 is constructed. What bits are ...


17

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


8

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$ ...


7

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


7

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 $ ...


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


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

Uniformity is a tricky one. SHA-256 (as well as SHA-3 for that matter) follows a heuristic approach. That is, the design is not based on a hardness assumption (for example, the factoring or discrete-log assumption) but on criteria that have only been verified empirically. As such, also the study of uniformity is an empirical study. The development of ...


7

Would you use HMAC-SHA1 or HMAC-SHA256 for message authentication? Yes. That is a semi-serious answer; both are very good choices, assuming, of course, that a Message Authentication Code is the appropriate solution (that is, both sides share a secret key), and you don't need extreme speed. How much HMAC-SHA256 is slower than HMAC-SHA1? Those ...


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

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

The Bitcoin mining algorithm can not be simplified by exploiting any weakness in the SHA-2 hashing algorithm with the current state of the art. The problem is manyfold. From the SHA-256 point of view, there is no (partial) preimage search algorithm that applies to the full hash function. Even worse, the attacks that penetrate a fewer number of rounds have ...


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


6

Some brief thoughts: Shared secret Generation: $$s=E_a(B)=E_b(A)$$ The shared secret is generated by encrypting the other users public key with your private key. This is effectively an ECDH step, which is very reasonable, and one of the key aims of C25519$^{[1]}$. Key Generation: $$s_0=\mathrm{SHA256}(s); s_i=\mathrm{SHA256}(s_{i-1})$$ First, using the ...


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

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

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


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

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


5

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, ...


5

Yes, you should be able to handle this situation readily. There are many optimizations available. One key observation is that if you're going to go to disk, then you might as well read lots of data: it takes just as long to read an entire block of data as to read 1 byte. So, I suggest you store the data on disk in 4096-byte blocks, and do a Merkle tree ...


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

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



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