51–60 of 61 posts
So there's a lot of talk about how encryption algorithms relying on the difficulty of factoring primes could be weakened by quantum computers in the near future. Are there any technological advances or scenarios where the security of hash algorithms could be weakened (other than computers just getting fasters via ~Moore's Law).
Surely you mean factoring numbers into primes as primes cannot be factored.
Earlier quoted context omitted.
> Hash functions strive for uniqueness No hash function strives for uniqueness. As long as the digest length is shorter than the input length, you can logically guarantee that there will be collisions. And since all general purpose hash functions allow arbitrary length input data, this is always the case. But what cryptographic hash functions strive for is the difficulty in finding a collision. It's mathematically gu…
> No hash function strives for uniqueness. As long as the digest length is shorter than the input length, you can logically guarantee that there will be collisions. Nope! For a known set of N inputs of length K, I can devise a hash function that maps then to a log2(N) bit result with zero collisions regardless of K. > And since all general purpose hash functions allow arbitrary length input data, this is always the c…
Would someone be able to ELI5 step 6 for me? I don't understand the math needed in order to determine that 399 zeros needed to be added.
49 + 399 = 448 448 mod 512 = 448, because 512 goes into 448 zero times with a remainder of 448.
The first section is wrong (emphasis mine): > A hash function is simply an algorithm that takes a string of any length and reduces it to a unique fixed length string. Hash functions strive for uniqueness but unless it's precalculated to ensure that it's true (by hashing every combination or deriving the parameters of the hash function accordingly), it's not guaranteed. A cryptographic hash function gives a high proba…
When I read that sentence, I assumed that the author meant that the computed hash for an input must be deterministic. But she doubles-down on the uniqueness claim later: Each hash is unique but always repeatable The word 'cat' will hash to something that no other word hashes too, but it will always hash to the same thing. This is such a large misunderstanding of hashing (as well as being obviously impossible) that it…
Earlier quoted context omitted.
> Hash functions strive for uniqueness No hash function strives for uniqueness. As long as the digest length is shorter than the input length, you can logically guarantee that there will be collisions. And since all general purpose hash functions allow arbitrary length input data, this is always the case. But what cryptographic hash functions strive for is the difficulty in finding a collision. It's mathematically gu…
> No hash function strives for uniqueness. As long as the digest length is shorter than the input length, you can logically guarantee that there will be collisions. Nope! For a known set of N inputs of length K, I can devise a hash function that maps then to a log2(N) bit result with zero collisions regardless of K. > And since all general purpose hash functions allow arbitrary length input data, this is always the c…
Earlier quoted context omitted.
> No hash function strives for uniqueness. As long as the digest length is shorter than the input length, you can logically guarantee that there will be collisions. Nope! For a known set of N inputs of length K, I can devise a hash function that maps then to a log2(N) bit result with zero collisions regardless of K. > And since all general purpose hash functions allow arbitrary length input data, this is always the c…
But then you have to cache the input strings, I don't see how the hash could work any other way independently of the input lengths. And thats rather called an index list compared to the common use of the word, which the GPs might have thought of differently, too..
It's definitely possible. Here's a simplistic example. Say I have two strings:
A really long string that goes on for [truncated] ...
Some other really long string goes on for [truncated] ...
It's a very simplistic example but the same concept can be used to identify the minimum components of the inputs that would need to be looked at to create a unique hash function. It won't be a general hash function though; it's specific to that data set.
Note that this isn't useless either. It's common to have a fixed/known lists of strings that you want to do lookups upon.
Earlier quoted context omitted.
> No hash function strives for uniqueness. As long as the digest length is shorter than the input length, you can logically guarantee that there will be collisions. Nope! For a known set of N inputs of length K, I can devise a hash function that maps then to a log2(N) bit result with zero collisions regardless of K. > And since all general purpose hash functions allow arbitrary length input data, this is always the c…
It's the arbitrary length that causes you to have more pigeons than pigeonholes.
No you can have a fixed length and arbitrary text. Say the input could be 32 hex characters representing a UUID. The key distinction is whether there is a finite / known list of the possible inputs. If so, then it's possible to create a hash function the perfectly hashes them.
Earlier quoted context omitted.
You can't retrieve the original text because information is lost in the process and many inputs hash to the same value. However, if the range of inputs is relatively limited, you can try hashing inputs until you find the right hash (see rainbow tables for discovering user passwords from the hash value).
>many inputs hash to the same value ? The chances of a sha256 collision is essentially zero barring a vulnerability being found in sha2. Far more likely for a comet to wipe out earth in your lifetime.
Yes, but to answer the question if you can find the input from the hash, the answer is no because it's impossible to be 100% certain as many input can hash to the same value.
Earlier quoted context omitted.
It's the arbitrary length that causes you to have more pigeons than pigeonholes.
> It's the arbitrary length that causes you to have more pigeons than pigeonholes. No you can have a fixed length and arbitrary text. Say the input could be 32 hex characters representing a UUID. The key distinction is whether there is a finite / known list of the possible inputs. If so, then it's possible to create a hash function the perfectly hashes them.
The point is that a function cannot bijectively compress arbitrary input into fixed output. Of course if you make the function itself depend on the input itself, then you can pull all sorts of tricks, but normally we do not call a simple lookup table a 'hash function', because they are very different things.
The first section is wrong (emphasis mine): > A hash function is simply an algorithm that takes a string of any length and reduces it to a unique fixed length string. Hash functions strive for uniqueness but unless it's precalculated to ensure that it's true (by hashing every combination or deriving the parameters of the hash function accordingly), it's not guaranteed. A cryptographic hash function gives a high proba…
Surely no guide to hash algorithms is complete without mentioning the pigeonhole principle at least once.