# Tag Info

6

Yes. Let $H$ be a collision resistant hash function and assume that one can find a collision $(x,y)$ for $H\circ H$, that is $x,y$ with $x\neq y$ and $H(H(x))=H(H(y))$. Consider the results $H(x)$ and $H(y)$ of applying $H$ once to both inputs. Then either $H(x)=H(y)$, hence $(x,y)$ is a collision for $H$; or $H(x)\neq H(y)$, hence $(H(x),H(y))$ is a ...

5

If the first application of H results in a collision then, so long as H is deterministic, any subsequent applications will collide. Thus iterated applications of hash functions will increase your collisions and is likely to degrade your security depending on what properties you need. For demonstration purposes only lets pretend we have SHA2-8, that is ...

5

The question asks how a collision in a hash such as SHA-1 could become a practical concern, with focus on the case of a public-key certificate à la X.509. I'll first give an example involving executable code signing. I'll assume an attacker in a position to write bootstrap code (like, the supplier of a development toolchain, or someone who compromised ...

5

is $T^{1-1/n}$ Proof: Suppose we have a sample set $M$, with $|M| = m$. We choose a set $N$ with $|N| = n$ among the set $M$, which is $O(m^n)$ (you know $O(m^n)=m\cdot(m-1)\cdot...\cdot(m-n+2)\cdot(m-n+1)$). In particular, we suppose $A_1, A_2, ...., A_n$ make a $n$-collision $H(A_1)=H(A_2) , H(A_2)=H(A_3) , ... , H(A_{n-1})=H(A_n)$ just as you want. ...

3

The premise that people cannot make a memory intensive password hashing function is incorrect. scrypt does approximately what is described in the question. Of course you still want to limit the amount of memory, especially if many of these hashes are to be calculated in parallel. Furthermore, you could have a look at the password hashing competition where ...

3

The question asks if $\operatorname{SHA-1}(M)\bmod n$ is random, giving the example of $n=2^{80}$. I'll consider arbitrary $M$ (that is, determined without knowledge of SHA-1, or just of SHA-1's 160-bit initialization constant), and that it makes $\operatorname{SHA-1}(M)$ indistinguishable from $160$ random bits (which is true from a computational ...

3

My understanding of the term 'pepper' is that it more matches your definition 2, in that a pepper is an unknown salt, which makes it a cryptographic secret, but not a key. However, in use it is not as limited by either of your definitions: The pepper can be different (or random) for all users (like a salt). The pepper can be the same for all users (like a ...

2

Comparing the security of different algorithms isn't easy. But I think the following algorithms would all be fine choices: SHA-3 / Keccak especially with large capacity (say 1024 bits) The biggest problem with this suggestion is that NIST hasn't finalized the SHA-3 specification yet. BLAKE A SHA-3 finalist, which some people (including myself) preferred ...

2

Yes in a sense in terms of the Hamming weight/Hamming distance. This relates to how the changes of one bit or series of bits affect others. While there is also an avalanche effect counteracting many n string bits attacks, Hamming dictates some attacks to be more successful on certain n bit strings and thus certain n bit strings more vulnerable to exploits: ...

2

From the Catena paper, version 2. A salt refers to an additional random input value for the password scrambler, stored together with the password hash. It enables a password scrambler to derive lots of different password hashes from a single password like an initialization vector enables an encryption scheme to derive lots of different ciphertexts from a ...

2

It depends on the exact Merkle-Damgaard hash. MD5 will literally take an arbitrary length; that's because the value placed in the padding is actually computed modulo $2^{64}$. For SHA-1 and the SHA-2 hashes, yes, you are correct; there is an upper bound on the length of the preimages that could potentially be hashed; for SHA-1, SHA-224 and SHA-256, it's ...

2

The randomness still holds in your example but it is not true for any value of N. For example, if the original key space was {0,1,2} and you wanted to restrict it to {0,1}, doing mod 2 would give the following results: 0 mod 2 = 0 1 mod 2 = 1 2 mod 2 = 0 Clearly, 0 will occur more often than 1 (not uniformly random). I believe the more general rule ...

1

As indicated, SHA-1 is not broken in the sense that practical attacks apply (as of 2014-12-06). So until practical attacks become feasible it is unclear against what scenarios they can be mounted. Probably the best thing to do is to have a look at what is happening with MD5. It is likely - but not certain - that attacks on SHA-1 would have largely the same ...

1

To quote from the paper you linked: The above particular values of $\mathrm{opad}$ and $\mathrm{ipad}$ were chosen to have a very simple representation (to simplify the function’s specification and minimize the potential of implementation errors), and to provide a high Hamming distance between the pads. The latter is intended to exploit the mixing ...

1

Mathematically speaking it should be, but don't forget the weakest chain here : Diffie-Hellman is vulnerable to MitM attacks... So something in addition must be used to ensure your security.

1

Passwords should use a password hashing function. Password hashing functions are different from basic cryptographic hashes, though they use cryptographic hashes as part of their construction. Password hashing functions must use salt. (Password hashing functions can also tune their time and/or memory usage, cryptographic hashes generally can't.) So for your ...

1

Normally, questions like this are considered off-topic; however, in this case, I can give a quick answer -- it's RC4

1

Your bad hash computes each byte of digest from only two bytes of message, resulting in very few small equations which can be solved by many automated tools. I've made the assumption that digest[0] = (129*msg[0]) XOR msg[15]. Expressing this hash in Cryptol we get: badHash : [16][8] -> [16][8] badHash msg = [ x ^ y | x <- mul | y <- (msg @@ ...

1

Ciphers don't use signature schemes. They do use MACs, which are different (and employ HMAC variants of hash functions, e.g. HMAC-SHA1). There is no danger in using SHA1 in this manner (or MD5 either, but I wouldn't advise doing that if you can avoid it). TLS 1.0 and TLS 1.1 also use SHA1 and MD5 internally, but this is still considered secure because they ...

1

There are two parts to this proposal: the use of a code book and a scheme to send short confidential and authenticated messages utilising an existing shared symmetric key. A code book can be used alone to provide a degree of confidentiality, or can be used to ascribe specific pre-agreed meanings to short messages, in combination with any scheme for sending ...

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