# Tag Info

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

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

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

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

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

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

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

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

3

It's probably a really bad idea to try and roll-your-own here. If you have to ask a question like this, you would probably just be better off using shrink-wrapped solution like SSL rather than trying to make your own protocol. There are a lot of tricky problems around getting these kinds of things right. However, if you insist on doing this yourself, there ...

3

The security concern is that the result of that operation will be guessable without the secret number, since the later part of that answer explains why it also applies to SHA-256. (Also, $\:$ SHA256(A+"") = SHA256(A)$\:$.) The random number should be long enough to make brute-force highly infeasible. If it is and you publish HMAC(A,"") and present them ...

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

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

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

SHA-1, SHA-224 and SHA-256 append the bit “1” to the end of the message, followed by k zero bits, where k is the smallest, non-negative solution to the equation l+1+k ≡ 448 mod 512, where l - message length. In second step they use 32-bit words. SHA-384, SHA-512, SHA-512/224 and SHA-512/256 use different equation: l+1+k ≡ 896 mod 1024 and in 2. step ...

3

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

2

Merkle trees allow several time-memory-tradeoffs: Using larger leaves or store only hashes at a certain level above then leaves. Now you need to hash a bigger leaf for update, but you need to keep fewer intermediate hashes in memory. Using a higher fanout. With fanout=2 you need to keep 2*n hashes in memory. With fanout=4 you only need 1.33*n hashes. But ...

1

In the CBC-MAC scheme, your attack is included as well. However, it also states, that CBC-MAC unlike encryption in CBC mode, does not use an IV (due to that attack), but is initialized with 0 (although any predefined constant would work). For the security of your scheme: In a model with random oracle for the hash function would be secure: An attacker who ...

1

There's been similar questions before but the answer is probably no with very high probability. You can imagine a hash as being a little box with a dwarf in it. You give him a message and the first thing he does is looks for the message in his book. If he finds it, he gives you the n-bit string he wrote in his book. If it's not in his book, he rolls some ...

1

Ideally, you'd implement both versions of the SHA-256 algorithm on some common platform, benchmark them and compare their performance. This would give you a measure of their actual real-world performance, or at least something close to it. If that's not practical, the next option would be to map each operation to some nominal number of CPU cycles typically ...

1

Yes, HOTP can include a PIN/Password also. If you check RFC 4226, it says Composite Shared Secrets It may be desirable to include additional authentication factors in the shared secret K. These additional factors can consist of any data known at the token but not easily obtained by others. Examples of such data include: * PIN or Password ...

1

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

1

You are looking at the SHA-1 specification, not the SHA-256 one. You are quoting pages 15,16 in the PDF you linked to. The remarks Thomas made also apply to SHA-256 though: the message block of 16 32-bit words is expanded to an auxiliary array of 64 (because we have 64 rounds, and we use one of the $W[t]$ in each round) 32-bit words. Then page 19 has the ...

1

What this does is expand the 16-word (512-bit) input message block (to the compression function, i.e. one "chunk" of the complete message) into an 64-word array W[t]. The definition of this array is recursive. What it tells you is that the first 16 words of this 64-word array are just the words of the input chunk: W[t] = M[t] for 0 <= t <= 15 In ...

1

The scheme you described above has some flaws. Because you aren't seeding the hash input each iteration, you are really increasing your chance of getting collisions. This is a great example of why you should try to avoid implementing these things yourself. It's really easy to overlook something subtle that undermines your system's security. As previously ...

1

The output length of the F step of PBKDF, i.e. the T_i each are of the size of your hash function's (or actually: your PRF's) output. So yes, when the desired output size is as large (or smaller) as the hash function output, we have l = 1 and thus only one call to F(P, S, c, 1). I suppose this is also the most common way to use PBKDF-2, the extension to ...

1

I believe scrypt is designed to be scaled to be both memory hard and cpu hard by explicit design. As a result, most implementations of scrypt will require you to input a desired cpu difficulty as well as a desired memory difficulty. On a gpu, where each core has very little memory, it would be trivial to see that, unless gpus gain a great deal of memory in ...

1

For counter mode, the only condition for your IV (i.e. initial counter value) is, that it doesn't repeat over messages, and more, that it doesn't collide with any of the counter values in use for all the messages using the same key. One way to do this would be to simply count forward from the last message, e.g. first message uses 1, 2, 3, second message ...

1

A problem with your proposed solution is that the digest of the password is now "password equivalent". So, what does hashing it before sending it gain you? That said, I don't think either of your concerns are concerning (or should be concerning). For the first, see this. If anything, most passwords will have less than 256 bits of entropy anyways. For ...

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