I'm trying to solve a keygenme task. I found that there is a ulong value stored as a string. Hash is calculated using SHA512Managed and only 16 bytes of a 128 byte result matters. I need to find such a ulong value stored as a string that gives hash that has 16 specific bytes.
As I understand, SHA algorithm can't be reversed, thus the only possible solution is a brute-force approach. There are 18,446,744,073,709,551,616 possible ulong values which is quite a lot.
So, the question is "is it possible to calculate only 16 bytes oh hash in order to decrease calculation time?".
P.S. If you know another way to solve my task, please tell me. Thank you!
No, it is not. The algorithm rotates values so you cannot leave any part of it out when calculating.
Theoretically you could leave a small part out of the last round but that wouldn't have any real meaning to the time spent brute forcing.
Related
I am looking for an efficient way to reduce the set of possible messages for a CRC hash, given an arbitrary hash value and known message size. Using brute force to calculate all possible collisions is not feasible for a large messageLength. Assume that the hash length is at least 100 times smaller than the messageLength (messageLength of 100K and hash size is 1K)
Example:
List<byte[]> ComputeCollisions(byte[] hash, int messageLength){
var collisions = new List<byte[]>();
//do some magic
return collisions;
}
Given how simple the CRC hash function works, I tend to believe that there is some way to do it, similar to unzipping it backwards, I just cannot figure out how to do it. To reduce the search space further would knowing the first or last XOR applied help at all?
Look at spoof. You can use it to modify messages to give you a desired CRC.
I have a list of sha256 hashes
hash1
hash2
hash3
hash4
Each hash value is a hash from the above value(hash("sha256","hash1") = hash2). I need to brute force the one thats next in the line(hash0). Is there a way I can lower the time of bruteforcing it knowing that its value hashed equals to the net one in the chain? If so, how can it be done? Or in the worst case scenario, how much time would i take to decrypt it?
Pardon me I am a really bad explainer.
Thank You in advance.
It might take a while:
On an iPhone 6s SHA256 takes 2.5ms.
Seconds in a year: 23.82K or about 2^25.
Dividing yields 10G or 2^34 hashes per year.
Dividing again 2^256 / 2^34 = 2^222 or in decimal about
100,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000 years.
Look at the bright side, that is much less than a google years!
This is why it is said that brute forcing SHA256 is not possible.
But you might get lucky and it will take less than a seconds. Do you feel lucky?
If you take a 32-bit sequence, and perform a CRC32 on it, you get another 32-bit sequence as the result; if you do CRC32 of this, you get another, and so on. It is easy to show that if you keep doing this, you end up with a single loop of 2^32 bit sequences, before starting over.
Simple question: does anyone know if the same holds true (or not) for SHA256, starting with a 256-bit sequence? Would a similar process cycle through a loop of all 2^256 possible 256-bit sequences before starting over? Or are there known (or likely) shorter loops within this hash?
Brian
SHA256 has not been designed to meet the property of 2^256 loop. However, as far as I know, nobody has proven there is no such loop. Also, there are not known any shorter loops because if anybody found some, then he would find also a collision and from the nature of the cryptographic hash function, it muse be difficult.
So, since nobody has not proven it, yes, there is a probability the 2^256 cycle would exists. However, it's extremely unlikely an I'm willing to bet my left testicle for it. :-)
Let me also note that, IMO to design a cryptographic hash function which has 2^256 loop would be extremely difficult even for the best crypto experts.
This is more of a cryptography theory question, but is it possible that the result of a hash algorithm will ever be the same value as the source? For example, say I have a string:
baf34551fecb48acc3da868eb85e1b6dac9de356
If I get the SHA1 hash on it, the result is:
4d2f72adbafddfe49a726990a1bcb8d34d3da162
In theory, is there ever a case where these two values would match? I'm not asking about SHA1 specifically here - it's just my example. I'm just wondering if hashing algorithms are built in such a way as to prevent this.
Well, it would depend on the hashing algorithm - but I'd be surprised to see anything explicitly prevent this. After all, it really shouldn't matter.
I suspect it's very unlikely to happen, of course (for cryptographic hashes)... but even if it does, that shouldn't cause a problem.
For non-crypto hashes (used in hash tables etc) it would be perfectly reasonable to return the source value in some cases. For example, in Java, Integer.hashCode() just returns the embedded value.
Sure, the Python hashing algorithm for integers returns the value of the integer. So hash(1) == 1.
Given a good hashing algorithm, one that returns a seemingly random output, I believe there should be on average one input that gives itself as the output. Let's say the hash can give N possible outputs. That means there are N possible inputs for which this is possible. For each of those, the odds of the output matching the input is 1/N, so there the expected number of fixed points is N*1/N, or 1.
A hash function might be defined to avoid ‘fixed points’ where hash(x)==x, but your hash-quine differs a little in that you're taking the string representation in hex of the hash rather than the raw binary. It would, I think, be infeasible to design a hash that could frustrate that, and it's mathematically less interesting since it depends on the arbitrary mapping of 0-F to ASCII character codes.
See Is there an MD5 Fixed Point where md5(x) == x? for a discussion about fixed points in MD5. The probability calculation would be equally true for hex hash-quines and any other hash function with 128 bits of output.
I know that say given a md5/sha1 of a value, that reducing it from X bits (ie 128) to say Y bits (ie 64 bits) increases the possibility of birthday attacks since information has been lost. Is there any easy to use tool/formula/table that will say what the probability of a "correct" guess will be when that length reduction occurs (compared to its original guess probability)?
Crypto is hard. I would recommend against trying to do this sort of thing. It's like cooking pufferfish: Best left to experts.
So just use the full length hash. And since MD5 is broken and SHA-1 is starting to show cracks, you shouldn't use either in new applications. SHA-2 is probably your best bet right now.
I would definitely recommend against reducing the bit count of hash. There are too many issues at stake here. Firstly, how would you decide which bits to drop?
Secondly, it would be hard to predict how the dropping of those bits would affect the distribution of outputs in the new "shortened" hash function. A (well-designed) hash function is meant to distribute inputs evenly across the whole of the output space, not a subset of it.
By dropping half the bits you are effectively taking a subset of the original hash function, which might not have nearly the desirably properties of a properly-designed hash function, and may lead to further weaknesses.
Well, since every extra bit in the hash provides double the number of possible hashes, every time you shorten the hash by a bit, there are only half as many possible hashes and thus the chances of guessing that random number is doubled.
128 bits = 2^128 possibilities
thus
64 bits = 2^64
so by cutting it in half, you get
2^64 / 2^128 percent
less possibilities