5 ms·
Is it? 6 guesses and I have 14 hex digits (56 bits) of the hash, along with knowing the population counts for all the numbers. This is enough to run a passwor
by mlyle 5y ago
Is it?
6 guesses and I have 14 hex digits (56 bits) of the hash, along with knowing the population counts for all the numbers. This is enough to run a password cracker and determine the plaintext if it's a readily guessed password.
Sure, it breaks conventional use of rainbow tables, etc, but...
edit: Eh, 14 characters. OK, that's pretty resistant to anything other than debugging.
- deleted 5y ago[deleted]
- residualmind 5y agoHow does that help you when any of your inputs' digest is not related to any other's, not even knowing the target length of the original message? what am i missing?
- residualmind 5y ago[ @some-sober-math-guy insert probabilities ]
- thewakalix 5y agoThe correct password is impossible to calculate from the given data, but it seems like it should be possible to check whether a password matches the data.
- residualmind 5y agoYeah because the algo is known, it is SHA256. The thing is you don't know the length of the password. It could be more than the number of hydrogen atoms in the universe, or 12. You still have to brute force or look up one possible solution (or collision thereof). The whole thing just shows that a hash makes ZERO applicable inferable assertions about the message (password). Thats the definition of evenly distributed hashing functions: change anything in the message, including length, and there will be no identifiable relation between the hashes of one messsage and the next you try,
- enkid 5y agoI mean, anything past 256 bits is going to have a collision, so that doesn't matter, but you're right that the entire point of a hash is that even if you know the hash, it's very very hard to find what the plaintext is.
- mtreis86 5y agoThere are a number of reversible hash algos. The point of hash is that the small changes in the input produce big changes in the output so even a 1-bit change to the input produces a completely different output. Some hash algos having trap door functionality is really more of a bonus.
- enkid 5y agoSure, I guess I wasn't being specific enough. Once of the reasons to use SHA-256 is because that's hard to do.
- eru 5y agoYou can only reverse your hash function, if you output is at least as long as your input. The kind of function you describe is useful, too, of course. You can build something like them out of almost any modern encryption method: Encryption methods have to be reversible, so you can decrypt; and they are expected not to betray anything about their inputs, so there are probably some that have this avalanche property, or can be patched to have it fairly simply.
- thaumasiotes 5y agoIt's true that any input length larger than 256 bits will exhibit a collision. It isn't true that it will necessarily exhibit every possible output. Maybe there's an output value that is only available for ridiculously large input.
- eru 5y agoYes, that's possible in general. Though fairly unlikely, if the hash was 'random'. We know the structure of SHA256, so we could actually answer that question. https://en.wikipedia.org/wiki/Preimage_attack https://en.wikipedia.org/wiki/Preimage_attack says that pre-image attacks on hash function in general only take 2^n time (ie you don't need to look for passwords longer than 256 bits), but I don't see how they conclude that.
- nilsbunger 5y agoi don't think anyone has created a hash collision in SHA-256 yet (meaning, given a hash, create an input that generates the hash)
- throwawaynay 5y agoyeah but who cares? it's still 100% possible, you just need a lot of time
- Simon_says 5y agoThe length of the password is 14. function randomPassword() { let letters = 'abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ'; let digits = '0123456789'; let punctuation = '!"#$%&\'()\*+,-./:;<=>?@[\\]^_`{|}~'; let s = letters.repeat(7) + digits.repeat(4) + punctuation.repeat(3); let length = 14; let res = Array.from({length}, (() => s[randomInt(s.length)])).join(''); debugger; // どうぞ return res; }
- acchow 5y agoThis isn’t how Sha works
- mlyle 5y agoIf they were dictionary words, or a similarly constrained search space, fed through SHA, this is exactly how it works. The information given after one guess excludes a whole lot of guesses as being possible solutions. Here, there's 91.7 bits of entropy in what goes into the hash function. Each guess shaves off more than 10 bits of entropy. After 9 guesses, only one password conforming to the generation format will be possible... yes, it will be very (impractically) hard to find this password, but the rest could be done offline to find the 10th value and solve it in 10 guesses. e.g. Make 9 random guesses. Then, for each of the 2^92 possible input strings: 1. Hash it. 2. See if the hash matches the things we know about the hash from the previous guesses.
- acchow 5y agoRight, it's a random password tho not a dictionary word
- mlyle 5y agoEven so, I just edited my comment and elaborated. You can do this in 9 online guesses with feedback + a very large number of offline guesses, and have the solution for the 10th. The information is there-- just the best search strategies known are very expensive.
- acchow 5y ago> a very large number of offline guesses Right, the entire search space of random passwords. The matching hash characters are tongue-in-cheek. They don't help you. They could've just given you the entire hash up front and you would still have to search the entire random password space. Sure, you could do it "offline", but it would still take forever to compute
- deleted 5y ago[deleted]
- deleted 5y ago[deleted]