Tag Info

It would be very freakish if it turned out to be true. It is not an expected property of SHA-512 to have such bijectivity. It would be worrisome, even, because that's a kind of structure that should not appear in a proper cryptographic hash function. Actually proving that SHA-512, for 512-bit blocks, is not bijective, would already be a kind of a problem. ...

No. The wikipedia article is in my honest opinion misrepresenting this article on a reduced round attack on the SHA-2 family of hashes. Although these attacks improve upon the existing reduced round SHA-2 attacks, they do not threaten the security of the full SHA-2 family. In other words, no collisions have been found in any of the SHA-2 hashes. The ...

Well, as far as we know, the mode you suggest should be secure. Now, to be honest, AES256 versus your mode isn't quite a fair comparison; your mode gives somewhat less theoretical security; if you encrypt a known $2^n$ block message, the key can be recovered with $2^{256-n}$ effort; however, this observation doesn't really affect the practical security. ...

The initial hash values for SHA-512 are the 64-bit binary expansion of the fractional part of the square root of the 9th through 16th primes (23, 29, 31, ..., 53). That is: $$I_0 = \left \lfloor \mathrm{frac} \left (\sqrt{23} \right ) · 2^{64} \right \rfloor$$ $$I_1 = \left \lfloor \mathrm{frac} \left (\sqrt{29} \right ) · 2^{64} \right \rfloor$$ $$\cdots$$ ...

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

No. Cryptographic hash functions model a random function, not a random permutation. A significant fraction of output hash values are expected to be unreachable and another fraction have multiple preimages. While bijectivity in general does not mean that the inverse is easy to calculate, for the types of constructs which are used in hash functions in ...

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

If the hash function is any good, then it should behave as a "random function" (i.e. a function chosen randomly and uniformly among all possible functions). For a random function with output size $n$ bits, it is expected that nested application will follow a "rho" pattern: the sequence of successive values ultimately enters a cycle with an expected size of ...

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

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

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

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

Essentially yes, they do. Depending on the exact hash function you choose depends on the length of output you'd expect. For example, SHA256 produces 256 bits of output. This does then beg the question "but the length of the hash is fixed and there are infinite possible inputs??!!". That's correct, except that $2^{256}$ is ...

In short, no. So, what is the current state of cryptanalysis with SHA-1 (for reference only as this question relates to SHA-2) and SHA-2? Bruce Schneier has declared SHA-1 broken. That is because researchers found a way to break full SHA-1 in $2^{69}$ operations. Much less than the $2^{80}$ operations it should take to find a collision due to the birthday ...

The CTR mode of encryption is defined in general for any cryptographically strong pseudo-random function (PRF). You can build such a PRF from a hash function. For CTR, you produce a key stream by concatenating: $$F(k,0) || F(k,1) || ... || F(k,m)$$ where $F$ is your secure PRF, $k$ is your key, and $m$ is the the length of your plaintext divided by the ...

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

If I understood your code correctly, what you are doing is encrypting a message $m$ with a key $k$ by: $c=m\oplus h(k)$, in an ECB mode where $h$ is some hash function. Take two encrypted blocks $c_1$ and $c_2$ and add them: $c_1\oplus c_2 = m_1 \oplus h(k) \oplus m_2 \oplus h(k)=m_1\oplus m_2$. Moreover, you may loose entropy if the initial secret is ...

What you explain in the question resembles SHACAL-2 cipher's forward cipher function, see http://en.wikipedia.org/wiki/SHACAL#Security_of_SHACAL-2. SHACAL-2 is NESSIE accepted way of using SHA-256 as cipher, therefore it has appeared somewhat secure.

Given just h1 and h2, if the salts are of any significant length then it will be impossible to uniquely determine "root" even if the hash function is very weak so long as it performs enough "compression". If both salts are known as well as h1 and h2 then the value of root is impractical to determine as long as the hash function is secure. Recovery of root ...

There are 94 printable ascii characters. Not all of which are valid for file names, however. There should be $64=2^6$ that are valid for file names, so read $6$ bits at a time and map those to one of the $64$ characters that are valid for file names. That would give you $256/6\approx 43$ characters. It will be hard to get much smaller than that. That ...

By the definition in FIPS 180-4, published March 2012, there are 160 bits in the output of SHA-1 224 bits in the output of SHA-224 256 bits in the output of SHA-256 384 bits in the output of SHA-384 512 bits in the output of SHA-512 224 bits in the output of SHA-512/224 256 bits in the output of SHA-512/256

The answer depends on assumptions on plaintext. If an adversary can enumerate the possible plaintext (e.g. if plaintext is a password, mediocre passphrase, or a published file) then yes: knowledge of h1 or h2 allows finding what plaintext is, by verifying beyond reasonable doubt an hypothesis made. For some level of protection against that, use a ...

Presuming root contains enough entropy to make a brute force search infeasible given only $h1$ and $salt1$, the (presumed) preimage resistance of SHA256 means that finding root would still be infeasible even if the attacker also knows the value $h2$ and $salt2$. Update: First order preimage resistance is usually defined as, for a random value $h$, it is ...

To sum up other contributions, the proposed construction: is at least as secure as SHA-256 against collision attacks, that is the ability for an adversary to contruct two files with the same hash; if SHA-256 was perfect, difficulty would be in the orider of 2128 hashes. is slightly less secure than SHA-256 against second-preimage attacks, that is the ...

If a hash function is suitable for general use, it will be suitable for this use. So long as an attacker cannot find two binary strings that hash to the same value, your method is secure. If you aren't confident that's true of the hash algorithm you are using, you picked a bad algorithm. Saying that an attacker has 32,768 opportunities to find a collision ...

Method 2 is no less secure than method 1. Here's why: the cryptographical property that a hash function possesses is that it is supposed to be computationally infeasible to find any two distinct preimages that hash to the same value. Method 1 relies on this directly. However, if we were to have an example of a collision with method 2, this implies that ...