# Tag Info

0

Yes. The output of SHA-256 is a 32-byte lone hex string or 256-bit long binary. It is technically possible to have 0xaaaaaaaaaaaaaaaa... over again, but the likelihood of finding the message which hashes to this value is still 1 in 2256. If the function checks it explicitly, it would at least have the following outputs ruled out: 0xaaaaaaaa... -16 ...

1

In theory, there are infinite inputs, that you can hash with SHA-256. So theoretically it would be possible that one hash string would read 0xaaaaaaaa... But would that also be possible practically, or do the algorithms check that this is not happening? The algorithm has 2256 possible outputs. Let us assume that you don't want the algorithm to output a hash ...

-1

It is possible. However, hashes are suppose to be random and 0xaaaaaa... doesn't seem random at all. Ensure that the algorithm, software, code, etc. is working properly because it looks like a security bug.

1

But would that be possible practically Is it possible that the SHA-256 of some input would be a repetition of the same hex digit? Yes, most definitely. In theory, any of the values in the output space is possible (though I don't think there's any proof that ALL values are actually possible). Is it possible to find an input, which, once hashed with SHA-256, ...

15

Yes, it's possible. Given the size of the input space (not actually infinite, but still very, very large), it's also likely, for any given 256-bit value, that several inputs that hash to that value exist. No, there's nothing special in the construction of the algorithm that prevents it (restricting the output space would probably be bad for security). ...

20

First of all, the output of SHA-256 is binary and consists of 32 bytes (256 denotes the output size in bits). What you are talking about is apparently the hexadecimal encoding of these bytes. The possibility that you are talking about is called (1st) pre-image resistance (Wikipedia): Given a hash value $h$, it should be difficult to find any message $m$ ...

5

But would that also be possible practically, or do the algorithms check that this is not happening? This is practically beyond anybody to find a 32-$a$'s for SHA-256 without pure luck or one need breaking the pre-image resistance of SHA-256, that is not possible. Is it possible that a SHA256 hash has the same character 64 times? Yes, and No. We don't know ...

1

You should use a cryptographic salt. This is a single use number generated for each hash. The salt should be prepended to the file to be hashed before hashing. The salt and hash value can then be stored together. Now if you want to compare a file against a given hash you prepend the salt, hash and check against the stored value. Provided that the salt values ...

0

If you have client side efficient verification and a small space of possibilities it can be brute forced. You must change at least one of these: no client side verification. much larger possibility space Inefficient client side verification (e.g by using a deliberately slow hash) You could potentially break up the verification so some of it happens client ...

0

Poncho points out that it is important to understand what constitutes a proof of knowing the password. So that answer is important. Beyond that, you're specifically concerned with the ability to find a pre-image for SHA256 given that you know the pre-image comes from a low-entropy source run through PBKDF2. If you think about it, the case you are worried ...

1

Let consider $h = H(A\mathbin\|B\mathbin\|C)$ for SHA-256 or SHA-512 where both are MD-based cryptographic hash functions of NIST with $A$ is 1000 bits $B$ 16 bits, and $C$ 283 bits and we further assume that the attacker knows $h$ and $C$ Brute-force search Definitely, the attacker cannot test the 1016-bit of unknown data to match the $h$. Bitcoin miners, ...

5

Then I would like to have a proof that the user has/knows the key K. The key will be hashed once with a SHA256 function and the result H will be stored in a database (SHA256(key)). So, whenever I will need to verify that the user has the key K, it will be hashed on frontend and only the H value will be sent to the server, so I can compare it with the value ...

1

SHA-256 is commonly used for fingerprinting or for calculation of key check values (KCV's) even in Hardware Security Modules (HSM's). As the hash is a one way function it should be secure. However, that's only used to identify keys, not to proof that you have the key. One thing to worry about is if the key is used for other purposes that include hashing. In ...

2

Would it not be possible to have a collision-resistant 128-bit slow-hashing function to replace MD5? That's possible. We could use Argon2 parameterized for 128-bit output and (say) 10 ms computation on a Raspberry Pi 3. If something could speed this up a hundredfold, and we parallelize on 1 million units, there's <40% chance of finding a collision with $... 2 Bcrypt is a password hashing function likes PBKDf2, Scrypt, and, Argon, where in the password hashing the collision is not important, pre-images are important. If you just iterate the$\operatorname{MD5^n}(x)=\operatorname{MD5}(\operatorname{MD5}(...(\operatorname{MD5}(x)...))\$ n-times then we will have an already well-known problem. A collision in the inner ...

1

So the answer was to remove the entire <ds:Signature> node from the saml:Assertion node before hashing the block, as opposed to removing the <ds:SignatureValue> node.

Top 50 recent answers are included