Key stretching algorithms
Key stretching algorithms – comptia security+ sy0-501 – 6.2
Key stretching techniques are used in cryptography to make a potentially weak key, such as a password or a passphrase, more reliable against a brute force attack by lengthening the time it takes to test each possible key. Human-created passwords are often short or predictable enough to allow password cracking. Such attacks are made more complex by key stretching.
The following are some of the most popular stretching techniques. The initial key is fed into an algorithm, which produces a more efficient key. The improved key should be large enough to be impossible to crack using brute force (e.g. at least 128 bits). The overall algorithm should be safe in the sense that there should be no known shortcut that allows the enhanced key to be calculated with less processor work than using the key stretching algorithm itself.
The attacker has two choices after the key stretching process: either try any possible combination of the enhanced key (impossible if the enhanced key is long enough), or try possibly combinations of the initial key. If the initial key is a password or a passphrase, the attacker will first try every word in a dictionary or a list of commonly used passwords, and then all character combinations for longer passwords. This method is not prevented by key stretching, but it does require the attacker to spend much more time on each attempt.
Professor messer’s sy0-501 security+ study group
Is there a security problem if I introduce a function that hashes the first half of my password with MD5 and the second half with SHA-2 and MD5 and then combines the two hashes to create a 64 character string?
I’d like to use something like this to extend the hash and hide the type of hash I used from the attackers. As a result, traditional rainbow tables would be useless. Since it has more characters, there will be no regular MD5 collisions. Am I correct?
No, it’s not true. Even for strong passwords, it would be easy for them to simply take each component and bruteforce it. You’re running into the same issue as NTLM did in the beginning, where a long password becomes two very short passwords that are both easy to bruteforce.
They just have to crack two 5-character passwords (keyspace of 120,932,352 for the same password) instead of one 10-character password (assuming a-z 0-9, that’s a keyspace of 3.6561013), making the problem many orders of magnitude simpler for them.
What is key stretching? what does key stretching
In cryptography, key stretching techniques increase the resources (time and likely space) needed to test each possible key, making a potentially weak key, such as a password or passphrase, more safe against a brute-force attack. Key stretching is designed to make password cracking more difficult by complicating a simple phase of attempting a single password candidate. Passwords or passphrases produced by humans are often short or predictable enough to allow password cracking. Since a key generation function must be deterministic in order for the weak key to always produce the same stretched key (known as an enhanced key), stretching the key has no effect on the entropy of the key-space, but it does complicate the process of computing the enhanced key. Rainbow tables are assaults on unsalted core stretching features. The process of salting the key involves appending a long, random string to the weak key. This is done to prevent precomputed hashes of short keys or password lists from being used in authentication schemes that require the hash to be displayed, or to reverse hashes into their original passwords, which could be used to compromise users on other sites that use the same password.
Intro to key stretching (demonstrates key stretching and
“It’s important to strike the right balance between protection and usability when using bcrypt. The calculation time increases as the cost factor is increased. When it comes to password operations, where do they take place? What is the maximum period of time that your users are able to wait?” This can be shared on Twitter. I generated a Node.js script that computed the hash of DFGh5546* percent __90 using a cost from 10 to 20 as an example of how increasing the work factor increases the work time. require(“bcrypt”); plainTextPassword1 = “DFGh5546* percent __90”;bcrypt gives us access to a Node.js library with utility methods to make the hashing process easier. The cost or job factor is represented by saltRounds. We’ll use plainTextPassword1 as an example of a random password. This Node.js implementation is interesting because it provides us with two separate password hashing techniques. Let’s take a look at them. Technique 1: Use different function calls to generate a salt and a hash. / app.js.catch(err => console.error(err.message));res is valid in this case, meaning that the hashed password given matched the stored hash. If we search the hash against plainTextPassword2:/ app.js, we should get false for res.