Tag Info

We call a primitive broken, if there is any attack faster than bruteforce/what we expect of an ideal primitive. Broken does not mean that there are practical attacks. There are no known collisions in SHA-1. Still we call collision resistance of SHA-1 is broken, because there is a theoretical attack that can find collisions using fewer than $2^{80}$ calls to ...

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

I would recommend phasing out SHA-1 in any scenario where collision-resistance of a hash is required, for there is a wide consensus that an attack with $2^{69}$ complexity would work, it would already be feasible by a resourceful entity, and attacks only get better. I'm still confident that SHA-1 is preimage and second-preimage resistant for all practical ...

No, theoretically a SHA1 hash can be any 160-bit value, including the string of 160 zeroes. As for your second question, if we fudge a little bit and consider SHA1 a truly random function this becomes the same question as the following: If we flip 160 coins, what is the probability that at least 128 of them will be heads? Solution is left as an exercise ...

The echo command will include a newline at the end. So when you use echo 'Rosetta Code' | sha1sum you are actually hashing the string Rosetta Code\n. Do the test using echo -n, the -n flag prevents the trailing newline character. Doing echo -n 'Rosetta Code' | sha1sum gives the same 48c98f7e5a6e736d790ab740dfc3f51a61abe2b5 hash that you were seeing ...

Well, the entire point of a cryptographical hash function is that no one can practically devise two messages that hash to the same value. Now, the SHA family of hashes use the Merkle–Damgård construction; that is, they have an iterated hash function, and each invocation of the hash function takes as input a fixed block size (either 512 or 1024 bits in the ...

echo -n "06b2f82fd81b2c20" | sha1sum e42d65afd2bc126a2e8e609257287084c43fc06a echo -n "02c60cb75083ceef" | sha1sum e42d65afd277988908c01bc539c9d71aff728322 Notice the first ten characters of the SHA1 hash match, indicating a 40-bit match. Other pairs are 0534164decf1166c, 06670357183cba13 and 0addd115537e4b39, 09a3cbdd0d00773b. Note that I am ...

SHA1 is fully described (including complete test vectors) in this FIPS publication, if you wanted to do it properly. But I think checking against the final digests of a couple inputs should be enough to point you to the correct version. I extracted them for you (inputs in ASCII, quotation marks excluded): "abc" (3 bytes) ...

In many existing padding schemes, without padding always being added there is a trivial second preimage attack. For simplicity let's assume a 10 bit hash function $h_{10}$ (extending this to other size hash functions is trivial). Let $m_1=101$ and $m_2=1011000000$. I claim that $h_{10}(m_1)=h_{10}(m_2)$. Since $m_2$ is 10 bits, no padding is needed. Since ...

First off, hashing is not encryption. Those are two very different concepts. You should read those links, they'll help you understand: Encryption Hash function As for your original question: What happens to the security of SHA-1 when truncated? Here is an answer that's true for all hash functions: In general using a hash function ...

SHA-1 is only academically broken. So, it is still secure for all uses. The problem is, attacks only get better. So, migrating to SHA-2 (or at least planning for a SHA-2 migration) would be a good move. That said, of interesting note is that even if SHA-1 were practically broken it might still be okay for use in HMAC.

Base64 provides a 1:1 transform from input to output (and back again if desired). So if you take a set of unique items and base64 encode all of them they will all be unique. So the question becomes if you run a GUID through SHA1, will the resulting hash have the same uniqueness as the GUID? The answer is practically - yes; theoretically not quite. Multiple ...

GUIDs are not guaranteed to be unique. GUIDs are Microsoft's take on UUIDs. Collisions can occur, depending on which type of GUID generator is used. (Though collisions are extremely rare in all cases.) GUIDs as they are defined have a size of 128 bits. SHA1 is a cryptographic hash function with an output size of 160 bits, larger than the GUID size, and SHA1 ...

Is there any mathematical result that gives us the minimum number of 1's in a 160-bit SHA-1 hash output? A good (secure) hash function has output that is uniformly and evenly distributed and shouldn't be distinguishable from random value. Chi-squared tests of several hash functions So the minimum number of possible ones is $0$ and the maximum ...

No, it's not possible. RSA based signatures can only be generated if you know the private key. At the RSA primitive level, signing is the same as decrypting a message (where the data being decrypted in this instance is a hash of the message). If you change the hash, then verification of that signature would fail. Without knowledge of the corresponding ...

Yes, but unless there is a significant break through in the crypto-analysis of SHA-1, the only way to retrieve the constant value is by brute forcing it. In other words, trying all the values, calculating the SHA-1 over the plaintext and the constant and comparing it with the given hash value.

Strictly speaking, it's not. But you wind up with either very complex or very ugly padding algorithms. For example, say you were designing a padding algorithm such that there exists one string of length M that is "padded" by adding no padding at all. Clearly, it would be a disaster if any string of length less than M could be padded so as to produce a ...