No. Damn it David , are u kidding? For example, if we need to keep info in some secret space we can do the same as mfa - hacking will not help you at all ✊
@@musharafhussain2316nobody hashes evey single file, if you need to hash every single file you might be interested in encryption, since you can configure encryption on a whole disk for example and it will take care of everything. Hashing is used for other purposes, like storing passwords, or in forensics, where yes, you hash even a whole disk, in order to have a "photograph" of the disk (for example to later prove that you did not alter it during an investigation)
@@musharafhussain2316you don't hash evey single file, if you need that you maybe need encryption, or work in forensics. Hash is used for other purposes, like storing passwords for example
@@blob6591 ... no. As he said in the video, even hashing an entire book will result in a 256 bit hash, which does not contain the book's contents. Therefore it's not even similar to encryption.
Actually, I am wrong, I guess that you can have a compression a which is revertible with hight probability. For example a compressor that only removes bits
It would work if the first match while compressing and decompressing (bruteforcing) would match the inputdata. If not, you could also encode which collision iteration to use instead. Ofcourse this would be incredibly slow and unsolvable by todays computers, but Im sure it would cover a large set of Kolmogorov complexity.
@@overbored1337 suppose a compression algorithm which simply truncate to 256 bits. Now you ask to compress a data of 257 bits. You can revert with a probably of 1/2 which is high. If you give it a input data of more thar 256 bits you can say that at worse you do it with a probability of 1/2^k where k =input size - 256. However you can still make the argument, that since you know the previous bits in clear text, knowing the next ones is not 1/2 at each time, but higher than that.
@@Luca-tg2wy not sure where you're getting at, but yeah im not saying that it would work on any data, but depending on the input, how its preprocessed and verified (given unlimited computational power). Atleast thats how i view it but I could also be wrong.
Nah. Hashing is just encryption + salt. That’s why it is called one way encryption. For example: it algorithm automatically add some random data during the encryption which make it kinda impossible to decrypt without knowing what’s the additional data.
Good explanation! However, an important point was left out: two different input values can produce the same hash. This means that the password may be found, or a random value that results in the same hash.
Depending on the hash, there might be a 1:1 relationship (injective function) that repeats every time the input is the size of the hash (so every bit you add usually mutliplies by 2 the number of possibilities) So if you have a function that has an output that is 256 bit long, each hash corresponds to a single input that is 256 bit in length and a single input that is between 0 and 255 bit in length. (And 2 inputs that are 257 bit in length) Which means that if the password length is less than the size of the hash, you will exactly get the password (assuming no salt/pepper) Note that most algorithms pad inputs that are shorter than a given size, so for sha 256 1 followed by 511-the size of your password 0s and then your password is the same as your password. Due to padding the exact number of bits might be off by a bit, since a prefixed 0 is the same as not having it, but the idea is the same.
Yes called a hash collision. Given sha2 is still current and you're clearly not sure what you're talking about, who didn't understand what he said in this video, congratulations. Everyone who upvotes you shares the same braincell.
Very well explained. The only caveat not mentioned is that just because the hashes are the same, doesn't neccesarily mean that the input data is the same, as multiple pieces of data may share the same hash (these are called collisions) but, its incredibly unlikely, especially from the context of brute forcing. Edit: Wow, this blew up! Lots of good discussion and points below too!
@@Mister.BreadBoardno, it check hash values. If you hash (with salt) your password, you send the hash to the other side. There they compare the hash value with the stored hash value. If the same, you have entered the right password on your side. But you never send the password in clear, and the other side only store hash value, not the password. So the you are the only one that know the password. Not the one receiving the hash value, and not anyone then listen to the communication.
I think you should also mention that if the hashes matches it doesnt mean that you got the original input. Hash collisions are inevitable if you allow hashing of bigger data than the size of the hash. (pigeon hole principle)
@@RampageG4mer actually it should. If you find a collision, you can use that even if not the correct password to login to that one system that you were trying to get into, however, even if the user used the same password for other accounts the collision will not work there because the salt is different and the produced hash from the combination of the collision and the new salt won't match. So ideally the attacker would want to get the real password not a collision that results in the same hash.
he kinda did in the first video, this is about a specific point. he already mentioned what y'al did but also mentioned that just because the data isn't same as long as it does give the same hash then two different passwords can be used for the same account.
Its not about the size of the hash but the number that it represents. It is an unimaginably large number and with a proper collision resistant hashing algorithm you will never get a collision in your lifetime with today's compute power. The chances of it happening are just too low. Unimaginably low. Collision resistance is due to how well the hash outputs are uniformly distributed. No data that we put into a hashing algorithm has a data size anywhere near being larger than the number a 256 bit hash can represent. Even with a quantum computer that can reduce the effectiveness of a hashing algorithm from 256 bits to effectively 128 bits, its still not going to be an issue. That's why today's hashing algorithms are so secure and considered quantum resistant. With something like Sha3_256 or blake3, that is properly collision resistant, the 256 bit digest represents more unique combinations of inputs than humanity could generate before the death of the solar system.
It is a difficult position. You can’t teach somebody ignorant in the very basics, which may be the majority of the people passing by such video. At the same time, I’d you explain this to people that knows it, doesn’t make too much sense that effort. That is why such videos are difficult to settle to the correct public, that is a person ready to learn that, knowing the basics up to there.
@@John-lw7bzno you don’t. hashes aren’t some sort of magic black hole that outputs data into small sized hashes just like that. hashes are also storage so you inevitably lose some information which means you get hash clashes
technically, you could store a bluray as a 256kb hash and use that to "restore" the original image, but how powerful of a computer would you need to be able to go 0...000,0...001,0...010, 0...011, etc. to figure out the actual data that was once held? Dont forget that due to hash clashes, you also have to verify you have the correct data. So in all practicality, it is impossible. And yes, if you have even the faintest clue of what hash salting is... you should know there are "unlimited" hash clashes since a string of X with a salt of Y might produce the same hash as a string of A and a salt of B.
Exactly! Video is 100% right. Technically the hash is an outcome of a calculation over the data. Like 2 + 4 + 3 = 9. My simple hash equals 9. But I can never get 2 + 4 + 3 back only when having 9. There are dozens of sums that could lead to 9 as an outcome. That's why there are hash collisions. Getting data back from an hash is because someone has generated a table of hashes from known data (like passwords and iso files). If the hash matches we know which data is corresponds to. This is still at best 'most likely' the data. There is a theoretical chance of a collision.
@@ImDGreatWhen you encrypt normally there will be a key and you can use that key to decrypt the data sp if you know the key you can get the original data but in hashing its impossible to retrieve data from the hash, the only way to verify hashed data is comparing the hashes
For added hash security, you could salt the hash. Unsalted hashes has rainbow tables available which lets you query a hash (in etc an SQL table) to obtain first available password for that hash. Salting a hash means you append etc the account id or registration date to the password before hashing it, making it much more resistant to rainbow tables.
Even 'better' than salting is adding pepper as well (and no, I'm not joking or being sarcastic, look it up 😅). Pepper is typically (or only?) used when salt is already being used as well, it's essentially just another security 'layer/step'.
@@deshonekizer5943 essentially, by storing 'an additional salt' on a different table (or entirely different DB altogether, on a separate DC, etc.) you are protecting that data against a physical breach or a localized remote with access to that specific system. Imagine you use AWS for one and GCP for the other; if your AWS root account gets compromised, the data is still unbreached as they'd need access to the GCP credentials as well.
@@biigsmokeeyou can use a rainbow table on any hash algorithm. It’s a fundamental flaw/feature of hashing based on pigeonholes. Sha256 is not immune to rainbows. Like, literally you just saw a rainbow attack happen in front of you.
It is also worth noting that it is possible to get the same hash with 2 different inputs; Getting the same hash doesn't always mean you have the same original data
@@personalviews6950 depends on what's stored where, but maybe. Passwords have a very small risk of clashing though, because they're not usually that long.
The whole point of hashes to compare data without actually having to give up the data. Passwords, version checking, file validity, etc. If you could reverse them, then by giving the hash you'd be giving the data and that would subvert the entire point.
Nah. You could reverse engineer the recipe. You can't do that with a hash. Cooking is more like compiling a program. You can't get the original source code but you can look into the ingredients and make something similar out of it.
@@zekiz774you started good, but ended doing his same mistake. It's not even comparable to coding, you can reverse engineer a program and look at the assembly code. You can't do that with a hash, even if you look into the algorithm that was used to hash the original data. What you can do is simply keep hashing data and compare the result with a hash that you want to "crack"
The issue is when passwords have been leaked so more common phrases and their hashes are already on a list which can make it easier for hackers to get into an account. This is also why the salt and pepper concept exists where you add another random string to the password that gets stored separately but always stays the same to make the hash unrecognisable. Pepper is just adding another random character each time which means it tries 30-ish combinations on every login to further jumble the hash.
We call this injection. If there existed a bijection (surjection and injection) between each hash and all possible inputs, it would be invertible and, therefore, crackable from only the outputs. If you reversed the SHA256 for a particular output, you would receive a field of inputs since its 'many-to-one'
Reversing the hash is about collision radius. If I had 1gigabyte of a book, I hashed it to 256 bits. Now I have 8 billion quantum bits. I set them to find a book of 1gigabyte that matches the hash. It will find the book theoretically. That's quantum to the extreme
It would work because 256 bits has a unique enough collision radius that is sufficiently large to reverse engineer. If the collision radius was only 1 in a trillion or quadrillion it would be insufficient
That was a fantastic explanation. Hashing is a deterministic one way function. So if you have the same output than you can say you have the same input, that doesn't mean you can reverse the output.
I’ve been a malware analyst and cybersecurity manager since 2009… Hashing is a one way function. The people arguing clearly know absolutely nothing about the subject.
While it's in theory a one way function, in practice some hashes can be reversed to one of the possible inputs. And collisions are even possible. So if you use the md5 hash of a program to be sure that there hasn't been a mitm attack, well, the mitm could have downloaded the program, added a virus, and modified it to generate a collision, which means the md5 hash is the same but the program you downloaded has a virus. And in the case of passwords, since the password is shorter than the hash in most cases, you can usually find the original password from a hash, as it's gonna be the first string to match the hash in the majority of cases. And in most cases where a list of hashes is used for cracking, having a few passwords that are just a collision doesn't matter.
@@satibel So first of all, I started my career as a malware analyst for the NSA. I have a ton of experience in this area. Hashes cannot be reversed. The fact that you say collisions are possible supports the fact that they cannot be reversed And no, no one is "adding a 'virus' to a program and then adding code to generate a collision"... This literally has never happened. And you're saying that passwords can be obtained from hashes? What is your background? You have no idea what you are talking about.
@@stevem437if you have a hash of a password (that is in a rainbow table) that corresponds to an account, you can usually get the password, so for all intents and purposes you have gotten the password from the hash. It doesn't usually work for a targeted attack (assuming a password that isn't weak), but it works for a broad attack like a leaked db from a random website. If you get 50% of the accounts, or even 1% depending on the size of the userbase, it's quite a lot of passwords. Yes it assumes that users reuse their passwords to have any usefulness, but that's a safe assumption on a large dataset. And yes hash collisions aren't practical, in most cases it's easier to just use social engineering or a weakness in the hardware/software that does the computation (e.g. the buffer overflow in the tegra on the Nintendo switch) Like it's way easier to also change the displayed hash if you can modify the program in transit. But it's technically doable by someone with enough funds, though at this point you might as well bribe someone.
Actually I think that would be a huge jump for humanity 😂 Imagine hashing terabytes of data into a small hash and getting it back. Sure, we'll have to look for alternatives for checking passwords but that seems like a low price for storing all that data in a hash 😂
No we dont. Acutally, some obsolete hash athgorithsm can be reversed. However, it is a very time consuming process and needs a hugh amount of computing power. It also only works for a short piece of data like a password. So here is why it does not matter. If you can reverse a hash to a password but in maybe 5 years, that piece of information is irrelevant by the time it is discovered because the password has been changed many times over. Thats why in many big techs, they force password changing in about 3 months.
In short, you can't reverse it, but you can check that it hasn't changed. You "can" however use a Rainbow Table and check hashes with your own hashes to "reverse" it and get the data. But that would mean that you ALREADY have it, hence there being NO WAY to reverse it and why it's a one way function.
Collisions (same hash shared by more than one value) are possible. Which is why stronger functions are pushed to default and standard when collisions become probable to happen within a given period. If you build a hash table of your files using the same CRC as used in data CD sector encoding you'll see a lot of collisions in your own set.
Actually, comparing hashes does not mean the original inputs are the same, rather that they are very very likely to be the same. There's a chance of 1 / 10^97 with SHA-256 of what's called a hash collision, where the same 2 inputs give the same hash value
No. Hash functions, in a broad computational sense, are defined by their ability to take input of arbitrary length and produce a fixed-size output. This characteristic is fundamental to various applications, such as indexing in data structures like hash tables. The crucial point to note here is that reversibility in the context of general hash functions is a matter of design and intent rather than an inherent impossibility!!! As long as the original input data is within the constraints of the hash function's output capacity, there exists the potential for these functions to be reversible, possibly through the function itself or other means. Contrastingly, !!CRYPTOGRAPHIC HASH!!!! functions are a specialized subset of hash functions with additional properties designed explicitly to enhance security. Among these properties is the principle of irreversibility-or more technically, pre-image resistance. This means that it should be computationally infeasible to reverse the hash function, i.e., to find the original input given the hash output. The design of cryptographic hashes aims to negate the possibility of reversibility, ensuring that even if the input data fits within the fixed output length, reversing the process to retrieve the original data should be impractical. You don't seem to grasp the distinction of those: not all hash functions are created with the same objectives, and thus, they vary in properties such as reversibility. So you are wrong. Hash functions can be reversed in some cases.
A hash function in general is not injective (multiple inputs can get mapped to the same output). Thus it is also not bijective, hence it can't be reversed. No need for a multiple paragraph essay to show that he is correct...
@@horrorgurke6669Well, you generalize and come to the wrong conclusion. I tried to explain why this is wrong. I guess I failed in that, maybe due to my poor explanation or your lack of careful reading. I was a researcher in cryptographic hash implementation for five years, and I am certain he is wrong. He and you are generalizing something that cannot be generalized. Oxford definition of a hash function: "noun: COMPUTING noun: hash function; plural noun: hash functions a function whose output values are all the same number of bits in length, especially one used to encrypt or compress data or to generate indices." The devil is in the details. Be precise with your words; one of the most important thing in computer science and mathematics is precision.
Man, some people just need to be the contrarian for no reason, You're technically correct about the broader definition of hash functions. However, in the context of cybersecurity which is the main theme here, when we discuss hashes, we're exclusively referring to cryptographic hash functions. These are designed with security in mind and are intentionally one-way functions. Please, next time take a moment and consider the possibility that this person might be right. If I speak up, I could be reacting out of my own ignorance of the topic he's referring to. This way, you can avoid being contrarian when there's no need.
Hashing is a one way function for checking file integrity. Encryption is 2 way function and also two types of encryption techniques is exist.symmetric and asymmetric encryption (public key cryptography).
Yes and no - you will obviously get the same hash with the same input, but you can also get the same hash with other inputs. I'm sure you're aware, but for the uninitiated, these are called hash collisions (in hash tables, anyway) EDIT: I can't believe I'm arguing with toddlers on the internet, but here we go... To clear up the "confusion" regarding my comment, I'm not responding to the video's title like some sort of half-wit who reads a book title and thinks he's absorbed the content. (For clarity, that's definitely an insult directed at some of you commenters) Instead, I'm referring to the comment made in the video, and I quote "I'm checking if the hashes are the same which means I have the same original data as you" - That claim is BLATANTLY FALSE!!! WATCH IT AGAIN!!! What I was trying (and failing, apparently) to communicate is that YES - The same input will hash to the same value, but NO it does NOT guarantee you have the same input. Multiple values CAN RESULT IN THE SAME HASH - this is called a HASH COLLISION. To all of you arrogant children who want to puff out their chest attempting to appear intellectually superior - You should be embarrassed! You've proven that you rank somewhere between a soggy bowl of cereal and a seahorse. Congrats....
To the question of whether or not one can retrieve the original data, the answer is NO. Not Yes and No. Hash collision is a different topic, which he acknowledged with a red highlighted note at the end of the video.
@@garydunken7934 I didn't say a damn thing about retrieving data from a hash, gary, I very clearly only addressed his comment about "if you get the same hash, you know you have the same input data" which is categorically false.
Yeah and I remember several years ago where researchers discovered a method to reliably generate hash collisions for SHA-1 hashes of files. (meaning generating a different files that shares the same hash as a target file)
@@CorrosiveCitrusif you have a lookup table for hash -> plain text you're likely to find the password by looking up the hash, if there's no salt and pepper. And you have the password that corresponds to an account, which is for all intents and purposes the same as decrypting the password.
To expand on why it's not reversible: If you take 10 and do an integer division by 3, you get 3 with a remainder of 1. In proper math terms, 1 is the modulus of 10 and 3. Having only 1 and 3, you cannot derive that the remaining input was 10 and not 7. When dealing with modulus arithmetic, multiple math problems can result in the same value: 10 \ 3 = 1 7 \ 3 = 1 4 \ 3 = 1 (In programming, you typically use a backslash \ to denote modulus as opposed to a forward slash / to denote division.)
The way I heard it explained is if you multiply two prime numbers, that's relatively easy to do. You can't then look at the resulting number and know which numbers were multiplied together to reach it.
yes you are right sir i am a Cybersecurity instructor i had this problem with my student also they said we will find a way 😂 to do this but this tech is designed to be one way there is no way to directly reverse it or find it .
Finally met a guy who likes hash more than me. 😂 your not wrong dude. Men need to be endured or educated. Your a great teacher. 👍 marcus aurelias would be proud of u.
You are almost correct. Even though the chances are very very low, it is possible that I hash a specific string DIFFERENT than another specific string and it will both generate the same hashes. So the same hash can be originated by different inputs. It is not 100% guaranteed that if two strings output the same hash by the same algorithms, they are the same string. It is just so likely, that we assume it is true and it will be ok for managing content access.
Anyone who said that he was wrong in his other video doesn’t fundamentally understand hashing. Keep up the great work, David. I absolutely, ABSOLUTELY LOVE your work.
what he explained in this video is a large part of how some core cryptocurrency functionality works. and tables with reverse lookups for hashes are called rainbow tables. they aren't practical for anything other than short or common strings or passwords, but they do exist
A way to kind of reverse a hash is to keep a table with the hashes as the key and a list of inputs that give that hash as the value. That way you input the hash value and get a list of some of the possible values. However there are infinite values it could be but 99% of them will be in just a few
Fun fact: This is why websitess will add an additional bit of information to your password (Sometimes called a salt, or a key, which is randomly generated based on a set algorithm) So that if there happens to be a data leak, the data theives will have the hash of the output of the password + the salted key, therefore also making the hash useless unless they also know the salt or key.
tbf you just explained exactly what hashing is used for, and ironically people kind of understand but vehemently defend their minor misunderstanding. oh humanity, always the entertainer.
In fact, the method allows you to generate a 256-bit sequence from an input of any size. The infinite number of possible inputs points to all possible combinations of outputs (2^256). Therefore, knowing an output does not guarantee knowing the input, since there are infinitely many inputs. It is a surjective function. Having two same hashed values does not ensure you the input were the same. So the assertion on "same hash = same password" is not true, as there is a world where two different passwords have the same hash.
Different passwords/strings can give the same hash. In fact, each outputted hash has infinite possible input passwords. This is true because 256 bits gives 2^256 possible hashes but there are infinite passwords since passwords can be any length, not just 256 bits. Therefore an infinite number of passwords must share only 2^256 hashes, so each password must share the same hash with other passwords.
With older encryption schemes, you would sometimes see the same data produce the same hash, but I'm not sure as the specifics that help prevent that today. I seem to remember Windows NT 4 passwords were pretty easy to reverse hash, but all you would need is a matching password data, not necessarily the same hash. I imagine that is still possible with current hash algorithms, but it may take a fair bit longer to engineer a match.
I think that the critiques were aimed at the fact that some older hashing algorithms are no longer considered cryptography secure. And some non cryptographic hashes can in some cases be used to find the original data.
simply explained on a sha256 algo you "remove" information when bit shifting and padding hence it becomes nearly impossible with current compute power to reverse as you need to try the possibilities of what may has been removed. Quantum computing may change that...
A professor in one of my CS classes explained it pretty simply. The space of all combinations of 256 bit strings is large but every string regardless of length outputs a 256 string and the list of every possible string is larger than that. That means there is overlap. This it's equivalent to saying x² = y. If I give you that X = 2, then Y must = 4. But if I say that Y = 4, you don't know if X = 2 or -2. Two different inputs can have the same output.
Also worth mentioning, what you're talking about is why it's best practice for people to use a random salt for each password when generating the password hash.
I think most people don't know the difference between encryption and hashing. Hashing is an one way method. We can not reverse the hash value to get the actual data. It is typically used to ensure the integrity of the original data.
Basically, the cross sum is a very simple (and unsecure) hash function. Using this algorithm, the numbers 2, 11, 10001 and infinitely more all have the same hash 2, but given only the hash 2, you cannot find out the original nuber. A little more complex examples are the ISBN check digit, or the check digits in an IBAN.
Called Rainbow tables. Which is why encryption is a clever combination of various security tactics, so you can't just look up passwords or single hashed values.
The technical term is hash collisions. Ironically, the better the hash function, and the more bits it produces, the higher the chance that the two passwords which produce the collision are actually the same. A weaker hash function, such as parity or ecc does a better job at exemplifying why hash collision is not “reversing”.
A hash function is any function that can be used to map data of arbitrary size to fixed-size values. If the fixed size is large enough you can get the data back.
More accurately described: you don't end up having the same original data, but you have what "mimics" the original data that can pass that same hash check as the true original data.
Let's consider addition as hash function. Then hash of 123 is 6. We can't get back 123 from 6, the original data is lost in calculation. Also hash of 222 is also 6, this is called hash collision.
This makes so much sense, as soon as you give the example of hashing a book or an iso, it becomes quite clear that a 256bit hash would not be able to give us a book, otherwise why the hell would we not just hash the entire internet and back it up as a tiny little 256bit hash, meaning we could store tons of info in a text file.
Of course you were correct! Those who said that you were not, don’t understand what a hash is. When used as an HMAC, you cannot ‘de-hash’…you can only make your own, and see if they match.
More fun facts: Depending on algorithm you don't even need to find the correct password by comparing the hashes, you can also find a string that generates the same hash. It's a collision attack. On MD5 and SHA-1 this was successful, meaning that those algorithms are insecure and should not be used anymore. MD5 collisions can be generated within seconds even on commonly used end user computer hardware.
If you have data shorter than hash - you can use some hash algorithms as encryption. Simplest hash is parity bit, if your data is 1 bit - parity bit contain and equal your data.
A powerful tool I would love for society to use more. For example sharing medical data between hospitals are sometimes not possible due to the security risk but if people would drive around to hospitals and making sure that the hashes get rotated and distributed in a safe manner I think it would make things smoother and safer.
Different passwords/strings can give the same hash. In fact, each outputted hash has infinite possible input passwords since there are 2^256 hashes but infinite passwords.
😂 David, you are the man! Some people watch a couple UA-cam videos on "hacking" and all of a sudden, they're pros lol. Take the time and research anything and everything you can, just like David. Keep it up man, love your videos
technically, hashes are reversible. However two factors make it unviable as a method to recover the hashed data. One is the computational power required to reverse a hash is thousands of orders of magnitude higher than the power required to hash a file. Two, is the fixed size of the hash. SHA256 having a fixed size of 256 bits means there is a finite number of hashes that are possible to produce. However, there are infinite possible streams of data (files), and therefore, infinite possible files with the same hash. So even if you did reverse the hash you’d have absolutely no guarantee the data you recovered is the same data that was hashed. In fact it most likely isn’t.
This is exactly how you can authenticate a digital file, to ensure it has not been altered. We used this method to create receipts for digitally signed documents at my previous job.
There are an infinite number of collisions for every hash. Not only not reversible, you can't even be perfectly certain that matching hashes means matching digests.
This was a good explanation with an example I never thought of. The only thing I think you missed was that two different hashed values can have the same hash as output[COLLISONS]. So a person could guess an incorrect password that just so happened to have a hash that is the same output as your correct password. The probability of that happening is extremely small, but definitely possible.
You're right. We use a hashing function in our work for a particular PCI-DSS scenario, I once asked if we could reverse hash to find out what the customer was doing wrong in creating it and it's not possible to do.
It's all a matter of information. Intuitively, if you put something that contains gigabytes of information into a few bits, it's impossible to recover all of the lost information. This is of course different from compression, where you utilize patterns in the data to reduce the number of bita required to store the original data. Even if the original data was shorter than the hash, are hash functions specifically designed to scramble the contained information in a way that it's as difficult as possible to recover any of the original data.
Cool thing about hashing is you can still search for the hash of a specific thing and still find it but still maintain confidentiality/privacy. Providing you are searching in a system that requires all hashes are unique.
Quibble: Technically it doesn't mean you have the same original data, it just means you have a likely match. Since 256 can't represent larger data sets uniquely it means you either found the real value or a collision. If you're trying to brute force with password like values and not just random values then chances are you did find it given how small the probability of a collision is
Hash functions can have inverse. But if a hash function has an inverse function, then it requires a restricted input type. Indeed, most of the useful hash functions have no inverse, but it is still possible to have a hash without collisions within a certain domain. Also, hashing does not have to use modular arithmetic.
A function that only returns values of a constant length has a finite amount of values it can produce - lets mark this number as n. Feed the function with any (n+1) different inputs and you will surely have a pair of inputs with the same output, proving that the function is not an injection. Any non-injective function cannot be reversed.
A hash has a set amount of bits and encodes any amount of bits. This means it's not a one to one function and hence it's not reversible. Put more simply, there's more things that can be hashed than hashes so for any given hash there are many things that correspond to that hash. There are lookup tables for popular passwords and their hashes which is why developers should salt the password before hashing and why end users should pick uncommon passwords in case the app in question lacks salting. But a lookup table is clearly not the same as a decryption algorithm.
One small contribution: If your plain text generated the same hash, it does not mean you guessed the correct text, just that the original text and your text have the same hash. Generally, if the original text is short, like a password, your guess is probably the same. But this does not generalize to big chunks of data.
You could use a hash db (rainbow table) to "restore" the hash. It works usually better with shorter strings, you won't be able to restore a full book as you said.
Electronic codebook mode can be attacked with Tau analysis, you cannot get the book from the hash, but upcoming AI might can find patterns and therefore find the input by adjusting more efficiently the input than randomly. Stay tuned.
The non-verbalized on-screen text, "assuming no collision", is the most important part. My initial reaction was "you were correct, right up until that last part" because I wasn't looking at the screen when I heard it, so I didn't see that non-verbalized note. I would say it's actually extremely helpful when people argue that they can reverse-engineer a hash because they immediately identify themselves as people whose "knowledge" and opinions can be completely disregarded because they are untethered from reality.
So once upon a time I thought I had a brilliant idea for using hashing as a form of compression. That idea fell out the window when I realized something very simple. A sha256 hash is a hexadecimal number so it contains the numbers 0-9 and the letters a-f If you tried to hash all strings that are 64 characters long and contain letters, numbers and special characters you would run out of unique hashes long before you were done. For a hash to be reversible it would need to be unique but for every possible hash you have an infinite number of valid strings, intigers, floats and binaries that would match. Granted, most of these would basically be random junk data but there would be no way to know that before un-hashing.
I think an algorithm can be used that links an input of any length to a variable-length output so that we can get back the input through the output. That's what I have read and understood so far.
Hashing is basically modulo arithmetic. 10 % 10 is 0, but so does the 20 % 10, and 30 % 10 is. If you know the mod of some number is 0, you still cant get the original number. The only way is to go through all the possible numbers whose modulo will be 0.
if you find a value that results in the same hash you might have found the original input value - but hashes aren’t unique, there may be many inputs that result in the same hash. So all you can say is that you found an inout that results in the same hash, not that you determined what the original input is.
Also note that while one way hash guarantees that if A = B then A.hash = B.hash, it does NOT guarantee that if A.hash = B.hash then A = B. This is especially common when a hash is substantially smaller than the data being hashed.
It's a really simple argument: The hashes are all 256-Bit, and the data can be any 256-Bit string, but also bit-strings of any other length. If you could reverse the hashing, you'd need to get exactly one data bit string for each of the 2^256 hashes when applying your de-hashing algorithm. However, this means we'd also only get 2^256 data bit-strings that the de-hashing algorithm produces. Since there are infinitely many data bit-strings, any de-hashing algorithm would therefore not work.
Do you agree with me? Hopefully this answers questions about Hashcat and other stuff mentioned in the comments :)
No. Damn it David , are u kidding? For example, if we need to keep info in some secret space we can do the same as mfa - hacking will not help you at all ✊
Hey@davidbombal who does the hashing? In an IT world an IT admin would not hash every single file.
@@musharafhussain2316nobody hashes evey single file, if you need to hash every single file you might be interested in encryption, since you can configure encryption on a whole disk for example and it will take care of everything. Hashing is used for other purposes, like storing passwords, or in forensics, where yes, you hash even a whole disk, in order to have a "photograph" of the disk (for example to later prove that you did not alter it during an investigation)
@@tenmaxim1904you look a bit confused
@@musharafhussain2316you don't hash evey single file, if you need that you maybe need encryption, or work in forensics. Hash is used for other purposes, like storing passwords for example
I think a lot of people confuse hashing and encryption
@@blob6591yes, it is. But it is not encryption
How? NO BODY upgraded a cisco swithc in their whole life? Every file in software download has a MD5 and SHA sum in the description box.
@@blob6591 ... no. As he said in the video, even hashing an entire book will result in a 256 bit hash, which does not contain the book's contents. Therefore it's not even similar to encryption.
@@blob6591i mean Deleting the information is technically one way encryption as well
@@blob6591 something encrypted can be decrypted, Sha 256 cannot be "decrypted" because it is not meant to store data.
If it was possible to get the original data, hash would be the best file compressor of all times 😅
Or it wouldn't be a compressor at all
Actually, I am wrong, I guess that you can have a compression a which is revertible with hight probability. For example a compressor that only removes bits
It would work if the first match while compressing and decompressing (bruteforcing) would match the inputdata. If not, you could also encode which collision iteration to use instead.
Ofcourse this would be incredibly slow and unsolvable by todays computers, but Im sure it would cover a large set of Kolmogorov complexity.
@@overbored1337 suppose a compression algorithm which simply truncate to 256 bits. Now you ask to compress a data of 257 bits. You can revert with a probably of 1/2 which is high. If you give it a input data of more thar 256 bits you can say that at worse you do it with a probability of 1/2^k where k =input size - 256. However you can still make the argument, that since you know the previous bits in clear text, knowing the next ones is not 1/2 at each time, but higher than that.
@@Luca-tg2wy not sure where you're getting at, but yeah im not saying that it would work on any data, but depending on the input, how its preprocessed and verified (given unlimited computational power).
Atleast thats how i view it but I could also be wrong.
Good explanation. Thank you! This is also the reason why the EU Privacy Policy doesnt allow web services to store passwords anymore, but their hashes.
Thank you. Good example that.
Hopefully salty hashes.
It makes no difference. It might take longer to crack it but having access to hashes allows us to do the cracking offline entirely
@@lukassnr1503 well Good luck with that 😅
@@robeaston4063 its not obligated by law, but yeah salty hashes is the proper way to store password hashes :)
People are still confusing Hashing with Encryption. Hashing for data integrity and Encryption for data confidentiality, keep that in mind.
💯
Nah. Hashing is just encryption + salt.
That’s why it is called one way encryption.
For example: it algorithm automatically add some random data during the encryption which make it kinda impossible to decrypt without knowing what’s the additional data.
Good explanation!
However, an important point was left out: two different input values can produce the same hash.
This means that the password may be found, or a random value that results in the same hash.
Depending on the hash, there might be a 1:1 relationship (injective function) that repeats every time the input is the size of the hash (so every bit you add usually mutliplies by 2 the number of possibilities)
So if you have a function that has an output that is 256 bit long, each hash corresponds to a single input that is 256 bit in length and a single input that is between 0 and 255 bit in length. (And 2 inputs that are 257 bit in length)
Which means that if the password length is less than the size of the hash, you will exactly get the password (assuming no salt/pepper)
Note that most algorithms pad inputs that are shorter than a given size, so for sha 256 1 followed by 511-the size of your password 0s and then your password is the same as your password.
Due to padding the exact number of bits might be off by a bit, since a prefixed 0 is the same as not having it, but the idea is the same.
@@satibel that relationship is unknown for good hash functions and the hash is deprecated once such a relationship becomes easy to find
Hash collision’s 💥
Yes called a hash collision. Given sha2 is still current and you're clearly not sure what you're talking about, who didn't understand what he said in this video, congratulations. Everyone who upvotes you shares the same braincell.
Very well explained. The only caveat not mentioned is that just because the hashes are the same, doesn't neccesarily mean that the input data is the same, as multiple pieces of data may share the same hash (these are called collisions) but, its incredibly unlikely, especially from the context of brute forcing.
Edit: Wow, this blew up! Lots of good discussion and points below too!
Was just about to comment this same thing lol
lol wow so you would accidentally find a different word that the system would accept as a password because the hashs match 😂
@@Mister.BreadBoard well yeah that’s what rainbow tables are for when systems don’t salt their hashes
@@whasian2007 oh so it still checks the provided password. Darn 😂
@@Mister.BreadBoardno, it check hash values.
If you hash (with salt) your password, you send the hash to the other side. There they compare the hash value with the stored hash value. If the same, you have entered the right password on your side. But you never send the password in clear, and the other side only store hash value, not the password.
So the you are the only one that know the password. Not the one receiving the hash value, and not anyone then listen to the communication.
I think you should also mention that if the hashes matches it doesnt mean that you got the original input. Hash collisions are inevitable if you allow hashing of bigger data than the size of the hash. (pigeon hole principle)
Was about to comment this, great explanation.
Yes, but that doesn't matter to the attacker
@@RampageG4mer actually it should. If you find a collision, you can use that even if not the correct password to login to that one system that you were trying to get into, however, even if the user used the same password for other accounts the collision will not work there because the salt is different and the produced hash from the combination of the collision and the new salt won't match. So ideally the attacker would want to get the real password not a collision that results in the same hash.
he kinda did in the first video, this is about a specific point. he already mentioned what y'al did but also mentioned that just because the data isn't same as long as it does give the same hash then two different passwords can be used for the same account.
Its not about the size of the hash but the number that it represents. It is an unimaginably large number and with a proper collision resistant hashing algorithm you will never get a collision in your lifetime with today's compute power. The chances of it happening are just too low. Unimaginably low. Collision resistance is due to how well the hash outputs are uniformly distributed. No data that we put into a hashing algorithm has a data size anywhere near being larger than the number a 256 bit hash can represent. Even with a quantum computer that can reduce the effectiveness of a hashing algorithm from 256 bits to effectively 128 bits, its still not going to be an issue. That's why today's hashing algorithms are so secure and considered quantum resistant.
With something like Sha3_256 or blake3, that is properly collision resistant, the 256 bit digest represents more unique combinations of inputs than humanity could generate before the death of the solar system.
People really think they discovered the cheat code to storage space.
It is a difficult position. You can’t teach somebody ignorant in the very basics, which may be the majority of the people passing by such video. At the same time, I’d you explain this to people that knows it, doesn’t make too much sense that effort.
That is why such videos are difficult to settle to the correct public, that is a person ready to learn that, knowing the basics up to there.
Unlimited compute and you do basically. Unless there are also unlined hash clashes 😅.
@@John-lw7bzno you don’t. hashes aren’t some sort of magic black hole that outputs data into small sized hashes just like that. hashes are also storage so you inevitably lose some information which means you get hash clashes
technically, you could store a bluray as a 256kb hash and use that to "restore" the original image, but how powerful of a computer would you need to be able to go 0...000,0...001,0...010, 0...011, etc. to figure out the actual data that was once held? Dont forget that due to hash clashes, you also have to verify you have the correct data. So in all practicality, it is impossible.
And yes, if you have even the faintest clue of what hash salting is... you should know there are "unlimited" hash clashes since a string of X with a salt of Y might produce the same hash as a string of A and a salt of B.
@metalwolf112002 extremely powerful artificial intelligence (real) on a quantum supercomputer (future)
Exactly! Video is 100% right. Technically the hash is an outcome of a calculation over the data. Like 2 + 4 + 3 = 9. My simple hash equals 9. But I can never get 2 + 4 + 3 back only when having 9. There are dozens of sums that could lead to 9 as an outcome. That's why there are hash collisions.
Getting data back from an hash is because someone has generated a table of hashes from known data (like passwords and iso files). If the hash matches we know which data is corresponds to. This is still at best 'most likely' the data. There is a theoretical chance of a collision.
Best explanation on the Internet sir.
Your explanation was very clear the first time. They didn't just understand.
They probably didn't want to either. They just wanted to _sound_ clever with none of the effort.
Yip! Hashing a big file was a good example though, might help some people understand.
@@TrollDeckercan you explain the difference between hash and encryption? sorry im still a noob
@@ImDGreatWhen you encrypt normally there will be a key and you can use that key to decrypt the data sp if you know the key you can get the original data
but in hashing its impossible to retrieve data from the hash, the only way to verify hashed data is comparing the hashes
@@vaishakhgk2006oh, thanks!
For added hash security, you could salt the hash. Unsalted hashes has rainbow tables available which lets you query a hash (in etc an SQL table) to obtain first available password for that hash.
Salting a hash means you append etc the account id or registration date to the password before hashing it, making it much more resistant to rainbow tables.
Even 'better' than salting is adding pepper as well (and no, I'm not joking or being sarcastic, look it up 😅).
Pepper is typically (or only?) used when salt is already being used as well, it's essentially just another security 'layer/step'.
@@Chinoman10can you explain how pepper works? Im familiar with salting hashes but is it basically another layer of salting? Also is it necessary?
@@deshonekizer5943 essentially, by storing 'an additional salt' on a different table (or entirely different DB altogether, on a separate DC, etc.) you are protecting that data against a physical breach or a localized remote with access to that specific system.
Imagine you use AWS for one and GCP for the other; if your AWS root account gets compromised, the data is still unbreached as they'd need access to the GCP credentials as well.
rainbow tables in sha256? what year and planet are you on
@@biigsmokeeyou can use a rainbow table on any hash algorithm. It’s a fundamental flaw/feature of hashing based on pigeonholes. Sha256 is not immune to rainbows. Like, literally you just saw a rainbow attack happen in front of you.
It is also worth noting that it is possible to get the same hash with 2 different inputs; Getting the same hash doesn't always mean you have the same original data
I guess it's also worth mentioning that a hash can be gotten from infinitely many inputs, unless you limit the length of the input.
Yes but if you get the same hash, you can access the account or whatever even without the original data right?
@@personalviews6950 not necessarily. Read up on "salt" in cryptography if you're interested.
@@personalviews6950there are defenses against pass-the-hash attacks, but yes thats the idea
@@personalviews6950 depends on what's stored where, but maybe. Passwords have a very small risk of clashing though, because they're not usually that long.
The whole point of hashes to compare data without actually having to give up the data. Passwords, version checking, file validity, etc. If you could reverse them, then by giving the hash you'd be giving the data and that would subvert the entire point.
It's like cooking. You cannot reverse the process to know the ingredients but you can guess and guess until you get the correct recipe.
Nah. You could reverse engineer the recipe. You can't do that with a hash.
Cooking is more like compiling a program. You can't get the original source code but you can look into the ingredients and make something similar out of it.
@@zekiz774you started good, but ended doing his same mistake. It's not even comparable to coding, you can reverse engineer a program and look at the assembly code. You can't do that with a hash, even if you look into the algorithm that was used to hash the original data. What you can do is simply keep hashing data and compare the result with a hash that you want to "crack"
@@ShinigamiAngercooking is pretty comparable to writing a program in a compiled language. Doesn't really have anything to do with Hashing tho
@@zekiz774 of course it is, but we are talking about hashing here, that is why my clarification
@@zekiz774 That analogy doesn't work at all.
The issue is when passwords have been leaked so more common phrases and their hashes are already on a list which can make it easier for hackers to get into an account.
This is also why the salt and pepper concept exists where you add another random string to the password that gets stored separately but always stays the same to make the hash unrecognisable. Pepper is just adding another random character each time which means it tries 30-ish combinations on every login to further jumble the hash.
We call this injection. If there existed a bijection (surjection and injection) between each hash and all possible inputs, it would be invertible and, therefore, crackable from only the outputs.
If you reversed the SHA256 for a particular output, you would receive a field of inputs since its 'many-to-one'
NON-injectivity
There's a bijection if you restrict the input to being also 256 bits
Reversing the hash is about collision radius. If I had 1gigabyte of a book, I hashed it to 256 bits. Now I have 8 billion quantum bits. I set them to find a book of 1gigabyte that matches the hash. It will find the book theoretically. That's quantum to the extreme
It would work because 256 bits has a unique enough collision radius that is sufficiently large to reverse engineer. If the collision radius was only 1 in a trillion or quadrillion it would be insufficient
The collision radius was 2^256. Sha does try to reduce the collision radius to scramble.
That was a fantastic explanation. Hashing is a deterministic one way function. So if you have the same output than you can say you have the same input, that doesn't mean you can reverse the output.
This clip was very informative and easy to understand. Well done and thank you!
Thank you. Glad you enjoyed it!
I’ve been a malware analyst and cybersecurity manager since 2009… Hashing is a one way function. The people arguing clearly know absolutely nothing about the subject.
Please advise all of your clients to use MD5 or SHA1 as their hashing algorithms and see how long you keep a job for
While it's in theory a one way function, in practice some hashes can be reversed to one of the possible inputs. And collisions are even possible.
So if you use the md5 hash of a program to be sure that there hasn't been a mitm attack, well, the mitm could have downloaded the program, added a virus, and modified it to generate a collision, which means the md5 hash is the same but the program you downloaded has a virus.
And in the case of passwords, since the password is shorter than the hash in most cases, you can usually find the original password from a hash, as it's gonna be the first string to match the hash in the majority of cases. And in most cases where a list of hashes is used for cracking, having a few passwords that are just a collision doesn't matter.
@@satibel So first of all, I started my career as a malware analyst for the NSA. I have a ton of experience in this area. Hashes cannot be reversed. The fact that you say collisions are possible supports the fact that they cannot be reversed And no, no one is "adding a 'virus' to a program and then adding code to generate a collision"... This literally has never happened.
And you're saying that passwords can be obtained from hashes? What is your background? You have no idea what you are talking about.
@@stevem437if you have a hash of a password (that is in a rainbow table) that corresponds to an account, you can usually get the password, so for all intents and purposes you have gotten the password from the hash.
It doesn't usually work for a targeted attack (assuming a password that isn't weak), but it works for a broad attack like a leaked db from a random website.
If you get 50% of the accounts, or even 1% depending on the size of the userbase, it's quite a lot of passwords.
Yes it assumes that users reuse their passwords to have any usefulness, but that's a safe assumption on a large dataset.
And yes hash collisions aren't practical, in most cases it's easier to just use social engineering or a weakness in the hardware/software that does the computation (e.g. the buffer overflow in the tegra on the Nintendo switch)
Like it's way easier to also change the displayed hash if you can modify the program in transit.
But it's technically doable by someone with enough funds, though at this point you might as well bribe someone.
@@codewithdrew sorry but md5 still cant be irreversible
Bruh if people could reverse hash and get the original message, we'd be in big trouble 😂
Actually I think that would be a huge jump for humanity 😂 Imagine hashing terabytes of data into a small hash and getting it back.
Sure, we'll have to look for alternatives for checking passwords but that seems like a low price for storing all that data in a hash 😂
Who needs privacy when I can have all of Netflix in a QR code?
No we dont. Acutally, some obsolete hash athgorithsm can be reversed. However, it is a very time consuming process and needs a hugh amount of computing power. It also only works for a short piece of data like a password.
So here is why it does not matter. If you can reverse a hash to a password but in maybe 5 years, that piece of information is irrelevant by the time it is discovered because the password has been changed many times over. Thats why in many big techs, they force password changing in about 3 months.
@@asandax6 The question is how long does it take for you to reverse that QR code back to Netflix? 10 years ,50 years or 100 years?
@@thanhnguyenviet3382 100 Years isn't so bad considering you've stored over 100TB in just 64B if you're using SHA-512.
In short, you can't reverse it, but you can check that it hasn't changed. You "can" however use a Rainbow Table and check hashes with your own hashes to "reverse" it and get the data. But that would mean that you ALREADY have it, hence there being NO WAY to reverse it and why it's a one way function.
Collisions (same hash shared by more than one value) are possible. Which is why stronger functions are pushed to default and standard when collisions become probable to happen within a given period. If you build a hash table of your files using the same CRC as used in data CD sector encoding you'll see a lot of collisions in your own set.
Actually, comparing hashes does not mean the original inputs are the same, rather that they are very very likely to be the same. There's a chance of 1 / 10^97 with SHA-256 of what's called a hash collision, where the same 2 inputs give the same hash value
No. Hash functions, in a broad computational sense, are defined by their ability to take input of arbitrary length and produce a fixed-size output. This characteristic is fundamental to various applications, such as indexing in data structures like hash tables. The crucial point to note here is that reversibility in the context of general hash functions is a matter of design and intent rather than an inherent impossibility!!! As long as the original input data is within the constraints of the hash function's output capacity, there exists the potential for these functions to be reversible, possibly through the function itself or other means.
Contrastingly, !!CRYPTOGRAPHIC HASH!!!! functions are a specialized subset of hash functions with additional properties designed explicitly to enhance security. Among these properties is the principle of irreversibility-or more technically, pre-image resistance. This means that it should be computationally infeasible to reverse the hash function, i.e., to find the original input given the hash output. The design of cryptographic hashes aims to negate the possibility of reversibility, ensuring that even if the input data fits within the fixed output length, reversing the process to retrieve the original data should be impractical.
You don't seem to grasp the distinction of those: not all hash functions are created with the same objectives, and thus, they vary in properties such as reversibility. So you are wrong. Hash functions can be reversed in some cases.
A hash function in general is not injective (multiple inputs can get mapped to the same output). Thus it is also not bijective, hence it can't be reversed. No need for a multiple paragraph essay to show that he is correct...
@@horrorgurke6669Well, you generalize and come to the wrong conclusion. I tried to explain why this is wrong. I guess I failed in that, maybe due to my poor explanation or your lack of careful reading.
I was a researcher in cryptographic hash implementation for five years, and I am certain he is wrong. He and you are generalizing something that cannot be generalized.
Oxford definition of a hash function:
"noun: COMPUTING
noun: hash function; plural noun: hash functions
a function whose output values are all the same number of bits in length, especially one used to encrypt or compress data or to generate indices."
The devil is in the details. Be precise with your words; one of the most important thing in computer science and mathematics is precision.
Man, some people just need to be the contrarian for no reason, You're technically correct about the broader definition of hash functions. However, in the context of cybersecurity which is the main theme here, when we discuss hashes, we're exclusively referring to cryptographic hash functions. These are designed with security in mind and are intentionally one-way functions. Please, next time take a moment and consider the possibility that this person might be right. If I speak up, I could be reacting out of my own ignorance of the topic he's referring to. This way, you can avoid being contrarian when there's no need.
If a hash was reverable it would defeat the point of a hash
Hashing is a one way function for checking file integrity. Encryption is 2 way function and also two types of encryption techniques is exist.symmetric and asymmetric encryption (public key cryptography).
Hashing is usually meant for comparing passwords and reveal data tampering or losses in transit. People confuse it with encryption.
Yes and no - you will obviously get the same hash with the same input, but you can also get the same hash with other inputs. I'm sure you're aware, but for the uninitiated, these are called hash collisions (in hash tables, anyway)
EDIT: I can't believe I'm arguing with toddlers on the internet, but here we go...
To clear up the "confusion" regarding my comment, I'm not responding to the video's title like some sort of half-wit who reads a book title and thinks he's absorbed the content. (For clarity, that's definitely an insult directed at some of you commenters)
Instead, I'm referring to the comment made in the video, and I quote "I'm checking if the hashes are the same which means I have the same original data as you" - That claim is BLATANTLY FALSE!!!
WATCH IT AGAIN!!!
What I was trying (and failing, apparently) to communicate is that YES - The same input will hash to the same value, but NO it does NOT guarantee you have the same input. Multiple values CAN RESULT IN THE SAME HASH - this is called a HASH COLLISION.
To all of you arrogant children who want to puff out their chest attempting to appear intellectually superior - You should be embarrassed! You've proven that you rank somewhere between a soggy bowl of cereal and a seahorse. Congrats....
To the question of whether or not one can retrieve the original data, the answer is NO. Not Yes and No.
Hash collision is a different topic, which he acknowledged with a red highlighted note at the end of the video.
@@garydunken7934 I didn't say a damn thing about retrieving data from a hash, gary, I very clearly only addressed his comment about "if you get the same hash, you know you have the same input data" which is categorically false.
Yeah and I remember several years ago where researchers discovered a method to reliably generate hash collisions for SHA-1 hashes of files. (meaning generating a different files that shares the same hash as a target file)
Video title: "Can you decrypt a hashed password?"
Your comment: "Yes and no"
Actual answer: "No"
@@CorrosiveCitrusif you have a lookup table for hash -> plain text you're likely to find the password by looking up the hash, if there's no salt and pepper. And you have the password that corresponds to an account, which is for all intents and purposes the same as decrypting the password.
The hash function has no inverse because it relies on the modular function that in mathematics has no inverse.
To expand on why it's not reversible: If you take 10 and do an integer division by 3, you get 3 with a remainder of 1. In proper math terms, 1 is the modulus of 10 and 3. Having only 1 and 3, you cannot derive that the remaining input was 10 and not 7.
When dealing with modulus arithmetic, multiple math problems can result in the same value:
10 \ 3 = 1
7 \ 3 = 1
4 \ 3 = 1
(In programming, you typically use a backslash \ to denote modulus as opposed to a forward slash / to denote division.)
The way I heard it explained is if you multiply two prime numbers, that's relatively easy to do. You can't then look at the resulting number and know which numbers were multiplied together to reach it.
yes you are right sir i am a Cybersecurity instructor i had this problem with my student also they said we will find a way 😂 to do this but this tech is designed to be one way there is no way to directly reverse it or find it .
Finally met a guy who likes hash more than me. 😂 your not wrong dude. Men need to be endured or educated. Your a great teacher. 👍 marcus aurelias would be proud of u.
You are almost correct. Even though the chances are very very low, it is possible that I hash a specific string DIFFERENT than another specific string and it will both generate the same hashes. So the same hash can be originated by different inputs. It is not 100% guaranteed that if two strings output the same hash by the same algorithms, they are the same string. It is just so likely, that we assume it is true and it will be ok for managing content access.
Anyone who said that he was wrong in his other video doesn’t fundamentally understand hashing. Keep up the great work, David. I absolutely, ABSOLUTELY LOVE your work.
Thanks for the explanation of a very basic authentication process....
what he explained in this video is a large part of how some core cryptocurrency functionality works. and tables with reverse lookups for hashes are called rainbow tables. they aren't practical for anything other than short or common strings or passwords, but they do exist
If hashed worked the way these guys thought, it would be the greatest compression algorithm ever!
A way to kind of reverse a hash is to keep a table with the hashes as the key and a list of inputs that give that hash as the value. That way you input the hash value and get a list of some of the possible values. However there are infinite values it could be but 99% of them will be in just a few
Fun fact: This is why websitess will add an additional bit of information to your password (Sometimes called a salt, or a key, which is randomly generated based on a set algorithm) So that if there happens to be a data leak, the data theives will have the hash of the output of the password + the salted key, therefore also making the hash useless unless they also know the salt or key.
tbf you just explained exactly what hashing is used for, and ironically people kind of understand but vehemently defend their minor misunderstanding.
oh humanity, always the entertainer.
In fact, the method allows you to generate a 256-bit sequence from an input of any size. The infinite number of possible inputs points to all possible combinations of outputs (2^256). Therefore, knowing an output does not guarantee knowing the input, since there are infinitely many inputs. It is a surjective function. Having two same hashed values does not ensure you the input were the same. So the assertion on "same hash = same password" is not true, as there is a world where two different passwords have the same hash.
This is the best explanation of hashing I have ever seen
Different passwords/strings can give the same hash. In fact, each outputted hash has infinite possible input passwords. This is true because 256 bits gives 2^256 possible hashes but there are infinite passwords since passwords can be any length, not just 256 bits. Therefore an infinite number of passwords must share only 2^256 hashes, so each password must share the same hash with other passwords.
With older encryption schemes, you would sometimes see the same data produce the same hash, but I'm not sure as the specifics that help prevent that today. I seem to remember Windows NT 4 passwords were pretty easy to reverse hash, but all you would need is a matching password data, not necessarily the same hash.
I imagine that is still possible with current hash algorithms, but it may take a fair bit longer to engineer a match.
I think that the critiques were aimed at the fact that some older hashing algorithms are no longer considered cryptography secure. And some non cryptographic hashes can in some cases be used to find the original data.
Hashing ensured an integrity of data. Absolutely, it’s one way function to check whether data is corrupted or not.
simply explained on a sha256 algo you "remove" information when bit shifting and padding hence it becomes nearly impossible with current compute power to reverse as you need to try the possibilities of what may has been removed. Quantum computing may change that...
A professor in one of my CS classes explained it pretty simply. The space of all combinations of 256 bit strings is large but every string regardless of length outputs a 256 string and the list of every possible string is larger than that. That means there is overlap. This it's equivalent to saying x² = y. If I give you that X = 2, then Y must = 4. But if I say that Y = 4, you don't know if X = 2 or -2. Two different inputs can have the same output.
Also worth mentioning, what you're talking about is why it's best practice for people to use a random salt for each password when generating the password hash.
That’s why alongside hashes, we need to also create and add salt on the back, for example. All code breaks, this way is just harder to break it.
I think most people don't know the difference between encryption and hashing.
Hashing is an one way method. We can not reverse the hash value to get the actual data. It is typically used to ensure the integrity of the original data.
Quickest and best explanation I've ever seen. Thank you
Basically, the cross sum is a very simple (and unsecure) hash function.
Using this algorithm, the numbers 2, 11, 10001 and infinitely more all have the same hash 2, but given only the hash 2, you cannot find out the original nuber.
A little more complex examples are the ISBN check digit, or the check digits in an IBAN.
For people who don't get it :
-encryption : scrambling the data
-hash : the data scrambles other data of fixed size
Called Rainbow tables.
Which is why encryption is a clever combination of various security tactics, so you can't just look up passwords or single hashed values.
The technical term is hash collisions. Ironically, the better the hash function, and the more bits it produces, the higher the chance that the two passwords which produce the collision are actually the same. A weaker hash function, such as parity or ecc does a better job at exemplifying why hash collision is not “reversing”.
A hash function is any function that can be used to map data of arbitrary size to fixed-size values. If the fixed size is large enough you can get the data back.
Wow, explained calmly and competently to what seems to me like trolls.
More accurately described:
you don't end up having the same original data, but you have what "mimics" the original data that can pass that same hash check as the true original data.
Let's consider addition as hash function.
Then hash of 123 is 6. We can't get back 123 from 6, the original data is lost in calculation.
Also hash of 222 is also 6, this is called hash collision.
This makes so much sense, as soon as you give the example of hashing a book or an iso, it becomes quite clear that a 256bit hash would not be able to give us a book, otherwise why the hell would we not just hash the entire internet and back it up as a tiny little 256bit hash, meaning we could store tons of info in a text file.
Beautifully explained. This man simplified what is known as a clash for you guys
There are actually an infinite number of different strings that can represent one hash value.
Of course you were correct!
Those who said that you were not, don’t understand what a hash is.
When used as an HMAC, you cannot ‘de-hash’…you can only make your own, and see if they match.
More fun facts:
Depending on algorithm you don't even need to find the correct password by comparing the hashes, you can also find a string that generates the same hash.
It's a collision attack. On MD5 and SHA-1 this was successful, meaning that those algorithms are insecure and should not be used anymore. MD5 collisions can be generated within seconds even on commonly used end user computer hardware.
If you have data shorter than hash - you can use some hash algorithms as encryption. Simplest hash is parity bit, if your data is 1 bit - parity bit contain and equal your data.
A powerful tool I would love for society to use more. For example sharing medical data between hospitals are sometimes not possible due to the security risk but if people would drive around to hospitals and making sure that the hashes get rotated and distributed in a safe manner I think it would make things smoother and safer.
Different passwords/strings can give the same hash. In fact, each outputted hash has infinite possible input passwords since there are 2^256 hashes but infinite passwords.
😂 David, you are the man! Some people watch a couple UA-cam videos on "hacking" and all of a sudden, they're pros lol. Take the time and research anything and everything you can, just like David. Keep it up man, love your videos
technically, hashes are reversible. However two factors make it unviable as a method to recover the hashed data.
One is the computational power required to reverse a hash is thousands of orders of magnitude higher than the power required to hash a file.
Two, is the fixed size of the hash. SHA256 having a fixed size of 256 bits means there is a finite number of hashes that are possible to produce. However, there are infinite possible streams of data (files), and therefore, infinite possible files with the same hash. So even if you did reverse the hash you’d have absolutely no guarantee the data you recovered is the same data that was hashed. In fact it most likely isn’t.
Hashes are a good way to check for small errors between two supposedly identical pieces of data. Most notably when you download something.
This is exactly how you can authenticate a digital file, to ensure it has not been altered. We used this method to create receipts for digitally signed documents at my previous job.
That's how you find out if someone knows anything about encryption theory. What's a hash? What's a digest? Who is Bob and Alice?
There are an infinite number of collisions for every hash. Not only not reversible, you can't even be perfectly certain that matching hashes means matching digests.
This was a good explanation with an example I never thought of. The only thing I think you missed was that two different hashed values can have the same hash as output[COLLISONS]. So a person could guess an incorrect password that just so happened to have a hash that is the same output as your correct password. The probability of that happening is extremely small, but definitely possible.
You're right. We use a hashing function in our work for a particular PCI-DSS scenario, I once asked if we could reverse hash to find out what the customer was doing wrong in creating it and it's not possible to do.
It's all a matter of information. Intuitively, if you put something that contains gigabytes of information into a few bits, it's impossible to recover all of the lost information. This is of course different from compression, where you utilize patterns in the data to reduce the number of bita required to store the original data. Even if the original data was shorter than the hash, are hash functions specifically designed to scramble the contained information in a way that it's as difficult as possible to recover any of the original data.
Cool thing about hashing is you can still search for the hash of a specific thing and still find it but still maintain confidentiality/privacy.
Providing you are searching in a system that requires all hashes are unique.
Quibble: Technically it doesn't mean you have the same original data, it just means you have a likely match. Since 256 can't represent larger data sets uniquely it means you either found the real value or a collision. If you're trying to brute force with password like values and not just random values then chances are you did find it given how small the probability of a collision is
True, even many different things can generate same hash code, though It's really rare in a good hash function.
Hash functions can have inverse. But if a hash function has an inverse function, then it requires a restricted input type.
Indeed, most of the useful hash functions have no inverse, but it is still possible to have a hash without collisions within a certain domain. Also, hashing does not have to use modular arithmetic.
A function that only returns values of a constant length has a finite amount of values it can produce - lets mark this number as n.
Feed the function with any (n+1) different inputs and you will surely have a pair of inputs with the same output, proving that the function is not an injection.
Any non-injective function cannot be reversed.
A hash has a set amount of bits and encodes any amount of bits. This means it's not a one to one function and hence it's not reversible. Put more simply, there's more things that can be hashed than hashes so for any given hash there are many things that correspond to that hash. There are lookup tables for popular passwords and their hashes which is why developers should salt the password before hashing and why end users should pick uncommon passwords in case the app in question lacks salting. But a lookup table is clearly not the same as a decryption algorithm.
One small contribution: If your plain text generated the same hash, it does not mean you guessed the correct text, just that the original text and your text have the same hash. Generally, if the original text is short, like a password, your guess is probably the same. But this does not generalize to big chunks of data.
You could use a hash db (rainbow table) to "restore" the hash. It works usually better with shorter strings, you won't be able to restore a full book as you said.
Electronic codebook mode can be attacked with Tau analysis, you cannot get the book from the hash, but upcoming AI might can find patterns and therefore find the input by adjusting more efficiently the input than randomly. Stay tuned.
Good explanation. Please also include collision when you talk about this
The non-verbalized on-screen text, "assuming no collision", is the most important part. My initial reaction was "you were correct, right up until that last part" because I wasn't looking at the screen when I heard it, so I didn't see that non-verbalized note. I would say it's actually extremely helpful when people argue that they can reverse-engineer a hash because they immediately identify themselves as people whose "knowledge" and opinions can be completely disregarded because they are untethered from reality.
I love how you explain things even though I know the subject
Hash tables yeah, that's why there's usually "salt" included before the hashing.
So once upon a time I thought I had a brilliant idea for using hashing as a form of compression.
That idea fell out the window when I realized something very simple.
A sha256 hash is a hexadecimal number so it contains the numbers 0-9 and the letters a-f
If you tried to hash all strings that are 64 characters long and contain letters, numbers and special characters you would run out of unique hashes long before you were done. For a hash to be reversible it would need to be unique but for every possible hash you have an infinite number of valid strings, intigers, floats and binaries that would match.
Granted, most of these would basically be random junk data but there would be no way to know that before un-hashing.
Simple explanation!
Thank you!
I think an algorithm can be used that links an input of any length to a variable-length output so that we can get back the input through the output.
That's what I have read and understood so far.
Did you not see the video???
Hashing is basically modulo arithmetic. 10 % 10 is 0, but so does the 20 % 10, and 30 % 10 is. If you know the mod of some number is 0, you still cant get the original number. The only way is to go through all the possible numbers whose modulo will be 0.
if you find a value that results in the same hash you might have found the original input value - but hashes aren’t unique, there may be many inputs that result in the same hash. So all you can say is that you found an inout that results in the same hash, not that you determined what the original input is.
Also note that while one way hash guarantees that if A = B then A.hash = B.hash, it does NOT guarantee that if A.hash = B.hash then A = B. This is especially common when a hash is substantially smaller than the data being hashed.
It's a really simple argument: The hashes are all 256-Bit, and the data can be any 256-Bit string, but also bit-strings of any other length. If you could reverse the hashing, you'd need to get exactly one data bit string for each of the 2^256 hashes when applying your de-hashing algorithm. However, this means we'd also only get 2^256 data bit-strings that the de-hashing algorithm produces. Since there are infinitely many data bit-strings, any de-hashing algorithm would therefore not work.