It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 10 years ago.
Let said given two hash code, you have been given the value of character 1 to character 9. The remaining of characters are unknown. The message length is unknown too.
Happens that this two hash code generated from 2 different plaintext but only first character are different, the remaining of the characters are exactly the same.
First hash code = *********************
Second hash code = *********************
plaintext1 = 1************************
plaintext2 = 2************************
Able to brute force to recover the plaintext?
Brute-forcing is always possible, it depends on your intention, whether it is applicable or not.
Finding collision (password login)
If you only need to find a collision (a value that results in the same hash-value), brute-forcing is applicable. An off the shelf GPU is able to calculate 3 Giga SHA1 hash values per second. That's why a fast hash function like SHA1 is a bad choice for hashing passwords, instead one should use a key derivation function like BCrypt or PBKDF2.
Finding original password
Finding a collision will be relatively fast, finding the original password (not just a collision) can use more time, it depends on the strength of the password, how much time you need then.
With a good cryptographic hash function, the knowledge about same characters should give you no advantage.
Modification of plaintext (digital signature)
If you want to alter the plaintext, so that it produces the same hash-value, then you will probably spend your life, looking for such a text. This is much harder, because the new text should make sense at last.
Cryptographic hash algorithms are designed to spread small changes in the plaintext across the whole of the computed hash. The kind of attack you're asking about is not feasible.
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
Update:
SHA-512 is one-way so I will need to not attempt to crack passwords because it is easier to simply reset a password. If someone is aware of getting the original password from a SHA-512 hashed text, please let me know. Otherwise, I am moving on from this question. Thank you for all of your answers.
Original Question:
I have read a lot of articles that state that SHA-512 hashing cannot be unhashed. However, there is a source code for the various SHA-1 + algorithms here: https://tls.mbed.org/sha-512-source-code.
I would like to know if it is possible to reverse this coding, in a way, to decrypt SHA-512 hashed text. Linux encrypts their passwords with SHA-512 hashing. As a systems administrator, I would prefer to simply decrypt or unhash this information as needed, rather than guessing whether a password is correct or incorrect and see if the hash matches. Creating new passwords can cause a lot of extra time and money. If you do not feel comfortable publishing this information and would like to discuss it privately, feel free to request my contact information.
Thank you!
Why do you not believe what you have read?
Cryptographic hash functions can not be reversed.
Thought experiment: You have 200 bytes you pass to SHA512, out come 64 bytes. Something has been lost. How do you regain what is lost?
In a similar manner if you have an integer, say 123, and mod by 10 the result would be 3. Now reverse that–oh it could have been and of 3, 13, 23, 33, 123, 9343453, *3.
I have read a lot of articles that state that SHA-512 hashing cannot be unhashed.
Yes. That is the definition of "hash". This has nothing to do with SHA-512. The definition of a hash function is that it cannot be reversed. Period. If it can be reversed, it's not a hash.
I would like to know if it is possible to reverse this coding, in a way, to decrypt SHA-512 hashed text.
No, you can't decrypt it, because it isn't encrypted, it's hashed.
Linux encrypts their passwords with SHA-512 hashing.
No, it doesn't. It hashes them, it doesn't encrypt them.
As a systems administrator, I would prefer to simply decrypt or unhash this information as needed, rather than guessing whether a password is correct or incorrect and see if the hash matches. Creating new passwords can cause a lot of extra time and money. If you do not feel comfortable publishing this information and would like to discuss it privately, feel free to request my contact information.
As a systems administrator, if you don't understand the difference between encryption and hashing, please tell me where you work, so that I never ever accidentally become of customer of yours! The Pigeonhole Principle is so simple and obvious that it can be understood by a child.
The articles you have read are correct.
However, if for example, a user uses a dictionary word, and you aren't salting your hashes, then those circumstances are open to dictionary attacks. Which is why no-one worth their salt, pun intended would use a hash algorithm without a salt.
Frankly I find it unlikely a systems administrator would need to get a password, as generally they have impersonation rights.
It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 10 years ago.
Suppose you want to implement a graph which can have million number of nodes.But the nodes count will increase from 0 to million.Its uncertain whether it will reach the million mark or not.It may cross it to multi-million nodes also.
I know adjacency list is what is used for this.But a typical adjacency list has a data structure maintaining pointers to the linked lists.
What data structure then should be used to store the pointers to the adjacency list ?
For example take Facebook for that matter.It has millions of users. Suppose each user represents a node. Now all users are represented as nodes of a very big single graph and you want to do operations on it how will you store it ?
Well if you know the basics behind them, it shouldn't be too hard.
Generally you create an array called "buckets" that contain the key and value, with an optional pointer to create a linked list.
When you access the hash table with a key, you process the key with a custom hash function which will return an integer. You then take the modulus of the result and that is the location of your array index or "bucket". Then you check the unhashed key with the stored key, and if it matches, then you found the right place.
Otherwise, you've had a "collision" and must crawl through the linked list and compare keys until you match. (note some implementations use a binary tree instead of linked list for collisions).
Check out this fast hash table implementation:
http://attractivechaos.awardspace.com/khash.h.html
It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 10 years ago.
The csv data file is 3.2 GB in total, with god knows how many rows and columns (assume very large). The file is a genomics data with SNP data for a population of individuals. Thus the csv file contains IDs such as TD102230 and genetic data such as A/A and A/T.
Now that I used Text::CSV and Array::Transpose modules but couldn't seem to get it right (as in the computing cluster froze). Is there specific module that would do this? I am new to Perl (not much experience in low level programming, mostly used R and MATLAB before) so detailed explanations especially welcome!
As direct answer, you should read file line by line, process them with Text::CSV, push new values to arrays with each array corresponds to original column and then just output them with join or like to get transposed representation of original. Disposing of each array right after join will help with memory problem too.
Writing values to external files instead of array and joining them with OS facilities is another way around memory requirements.
You also should think about why you need this. Is there really no better way to solve real task at hand, since transposing just by itself serves no real purpose?
Break down the task into several steps to save memory.
Read a line and write the fields into a file named after the line number. Output one line per field.
Repeat step 1 until the input CSV file is exhausted.
Use paste to merge all output files into a big one.
It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 12 years ago.
which is faster and usefull ? accumulator , register , or stack?
Registers are the fastest. An accumulator is also a register in which intermediate arithmetic and logic results are stored (info from Wikipedia).
A stack will be slower since it's a region of memory, and memory will always be slower than registers.
However, you will always have more memory available than registers since CPU storage is very costly.
Bottom line: they're all useful and their speed is inversely proportional to their available storage.
Those questions without any context about CPU architecture or other information what you want to accomplish cannot be answered in any useful way.
Usually the accumulator is just one of the registers - modern CPUs don't differentiate anymore, so for old one accu might be faster - or actually the only register allowing you certain operations. Registers are always faster then external memory, but there are just a limited amount of them (and they need to be explicitely named by the compiler/assember).
The stack is an area of RAM used to store data. So that's slower for sure :)
Quistion is not quite correct. "Fast" is related to the operations, not to the registers and etc. Another point - there is nothing about architecture of CPU in first message :-)
Depending on CPU architecture accumulator is a register but can have a special implementation. This way the operations that use accumulateor usualy faster than register operations.
About stack. Some processors have no support of Register-Register operations(i.e. input-output processor). That case some operations on the stack can be faster because it is not required to calculate effective address.
Register are always faster because it doesn't go get data into the memory, but be more clear about the situation.
Registers are usefull when you have many like x64 or Arm architecture.
Generally, registers are faster because they are actually part of the microprocessor. And the accumulator is just one of the register (the one that normally stores the result of various operations).
The stack is just memory like any other memory, allocated for the purpose of tracking return addresses and local variables.
But you can't use registers for everything because there are only a very limited number of them available.
If you explained why you were asking these questions, they might make a little more sense.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 2 years ago.
Improve this question
I've always been curious... Which is better when salting a password for hashing: prefix, or postfix? Why? Or does it matter, so long as you salt?
To explain: We all (hopefully) know by now that we should salt a password before we hash it for storage in the database [Edit: So you can avoid things like what happened to Jeff Atwood recently]. Typically this is done by concatenating the salt with the password before passing it through the hashing algorithm. But the examples vary... Some examples prepend the salt before the password. Some examples add the salt after the password. I've even seen some that try to put the salt in the middle.
So which is the better method, and why? Is there a method that decreases the chance of a hash collision? My Googling hasn't turned up a decent analysis on the subject.
Edit: Great answers folks! I'm sorry I could only pick one answer. :)
Prefix or suffix is irrelevant, it's only about adding some entropy and length to the password.
You should consider those three things:
The salt has to be different for every password you store. (This is quite a common misunderstanding.)
Use a cryptographically secure random number generator.
Choose a long enough salt. Think about the birthday problem.
There's an excellent answer by Dave Sherohman to another question why you should use randomly generated salts instead of a user's name (or other personal data). If you follow those suggestions, it really doesn't matter where you put your salt in.
I think it's all semantics. Putting it before or after doesn't matter except against a very specific threat model.
The fact that it's there is supposed to defeat rainbow tables.
The threat model I alluded to would be the scenario where the adversary can have rainbow tables of common salts appended/prepended to the password. (Say the NSA) You're guessing they either have it appended or prepended but not both. That's silly, and it's a poor guess.
It'd be better to assume that they have the capacity to store these rainbow tables, but not, say, tables with strange salts interspersed in the middle of the password. In that narrow case, I would conjecture that interspersed would be best.
Like I said. It's semantics. Pick a different salt per password, a long salt, and include odd characters in it like symbols and ASCII codes: ©¤¡
The real answer, which nobody seems to have touched upon, is that both are wrong. If you are implementing your own crypto, no matter how trivial a part you think you're doing, you are going to make mistakes.
HMAC is a better approach, but even then if you're using something like SHA-1, you've already picked an algorithm which is unsuitable for password hashing due to its design for speed. Use something like bcrypt or possibly scrypt and take the problem out of your hands entirely.
Oh, and don't even think about comparing the resulting hashes for equality with with your programming language or database string comparison utilities. Those compare character by character and short-circuit as false if a character differs. So now attackers can use statistical methods to try and work out what the hash is, a character at a time.
It shouldn't make any difference. The hash will be no more easily guessable wherever you put the salt. Hash collisions are both rare and unpredictable, by virtue of being intentionally non-linear. If it made a difference to the security, that would suggest a problem with the hashing, not the salting.
If using a cryptographically secure hash, it shouldn't matter whether you pre- or postfix; a point of hashing is that a single bit change in the source data (no matter where) should produce a different hash.
What is important, though, is using long salts, generating them with a proper cryptographic PRNG, and having per-user salts. Storing the per-user salts in your database is not a security issue, using a site-wide hash is.
First of all, the term "rainbow table" is consistently misused. A "rainbow" table is just a particular kind of lookup table, one that allows a particular kind of data compression on the keys. By trading computation for space, a lookup table that would take 1000 TB can be compressed a thousand times so that it can be stored on a smaller drive drive.
You should be worried about hash to password lookup tables, rainbow or otherwise.
#onebyone.livejournal.com:
The attacker has 'rainbow tables' consisting not of the hashes of dictionary words, but of the state of the hash computation just before finalising the hash calculation.
It could then be cheaper to brute-force a password file entry with postfix salt than prefix salt: for each dictionary word in turn you would load the state, add the salt bytes into the hash, and then finalise it. With prefixed salt there would be nothing in common between the calculations for each dictionary word.
For a simple hash function that scans linearly through the input string, such as a simple linear congruential generator, this is a practical attack. But a cryptographically secure hash function is deliberately designed to have multiple rounds, each of which uses all the bits of the input string, so that computing the internal state just prior to the addition of the salt is not meaningful after the first round. For example, SHA-1 has 80 rounds.
Moreover password hashing algorithms like PBKDF compose their hash function multiple times (it is recommended to iterate PBKDF-2 a minimum of 1000 times, each iteration applying SHA-1 twice) making this attack doubly impractical.
BCrypt hash if the platform has a provider. I love how you don't worry about creating the salts and you can make them even stronger if you want.
Inserting the salt an arbitrary number of characters into the password is the least expected case, and therefore the most "secure" socially, but it's really not very significant in the general case as long as you're using long, unique-per-password strings for salts.