how many bits in the resultant hash will change, if the x bits are changed in its the original inputWhat is...
Sending a photo of my bank account card to the future employer
What details should I consider before agreeing for part of my salary to be 'retained' by employer?
What advantages do focused Arrows of Slaying have over more generic ones?
Construct, in some manner, a four-dimensional "RegionPlot"
How Can I Process Untrusted Data Sources Securely?
How can I find what program is preventing my Mac from going to sleep?
Why do candidates not quit if they no longer have a realistic chance to win in the 2020 US presidents election
How could a medieval fortress manage large groups of migrants and travelers?
Why should I cook the flour first when making bechamel sauce?
Credit card details stolen every 1-2 years. What am I doing wrong?
Sankhara meditation
What happens if there is no space for entry stamp in the passport for US visa?
Advice for paying off student loans and auto loans now that I have my first 'real' job
Trivial cases of shared_ptr and weak_ptr failing
Did 007 exist before James Bond?
What could be reasoning of male prison in VR world to only allow undershirt and sarong as nightwear to male prisoners
What is the German word or phrase for "village returning to forest"?
FPGA CPU's, how to find the max speed?
When does Fisher's "go get more data" approach make sense?
Can you perfectly wrap a cube with this blocky shape?
Why are road bikes (not time trial bikes) used in many triathlons?
Is there a standard way of referencing line numbers in a draft?
Adjusting vertical spacing in fractions?
Is the Gritty Realism variant incompatible with dungeon-based adventures?
how many bits in the resultant hash will change, if the x bits are changed in its the original input
What is the “Random Oracle Model” and why is it controversial?Hash functions and the Avalanche effectHow are timestamps verified?Do parts of a hash carry the properties of the entire hash?How hard/easy will be to break a SHA-1 or SHA-256 hash if the attacker knows part of the original text?Do I need to use AE/AEAD in my particular scenario? Or is it redundant?Is there an algorithm that allows verification that 2 encrypted or hashed bits of data are the same, given that I may only know half of the key/ salt?Reversing a hash of known hashing algorithmHow can I calculate the avalanche effect in symmetric algorithms?Better than diceware? And sha512 related questionWhat is the length of the SHA-1 message digest and how is RSASSA-PSS used for verification?Can length extension attacks be avoided by a single bit flip?
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty{ margin-bottom:0;
}
$begingroup$
I came across a question stating:-
We have a message consisting of 10,000 characters. After computing its message digest using SHA-1, we decide to change the last 19 characters in the original message. How many bits in the digest will change if it is recomputed, and why?
Until and unless this is an explicit attack on the hashing scheme, the new hash would be different then the original one (sort of exhibiting Avalanche effect).
But I am unable to understand how does small changes in Input text, affect their corresponding Hashes. Like does there exists a relationship on how many bits of the hash will be affected, if a certain change is done to the Input text?
P.S.:- I am not a 100% sure, but I believe I have read it somewhere that a hashing algorithm should change the bits of hash by $X$% if a new character/bit is added/substituted to the previous input text.
Note:- I believe that my title isn't the best on for stating my problem. So, if anyone can come with a better title to describe my problem, then feel free to change the title, and delete this note from the description too. And if it is okay for describing my problem, then just remove this note.
hash sha-1 avalanche
$endgroup$
add a comment |
$begingroup$
I came across a question stating:-
We have a message consisting of 10,000 characters. After computing its message digest using SHA-1, we decide to change the last 19 characters in the original message. How many bits in the digest will change if it is recomputed, and why?
Until and unless this is an explicit attack on the hashing scheme, the new hash would be different then the original one (sort of exhibiting Avalanche effect).
But I am unable to understand how does small changes in Input text, affect their corresponding Hashes. Like does there exists a relationship on how many bits of the hash will be affected, if a certain change is done to the Input text?
P.S.:- I am not a 100% sure, but I believe I have read it somewhere that a hashing algorithm should change the bits of hash by $X$% if a new character/bit is added/substituted to the previous input text.
Note:- I believe that my title isn't the best on for stating my problem. So, if anyone can come with a better title to describe my problem, then feel free to change the title, and delete this note from the description too. And if it is okay for describing my problem, then just remove this note.
hash sha-1 avalanche
$endgroup$
$begingroup$
See also Hash functions and the Avalanche effect
$endgroup$
– kelalaka
7 hours ago
$begingroup$
This sounds like a good job interview question. (Of the fizz buzz test kind, anyway.) It must either be a trick question or come from someone that doesn't understand hash functions. There isn't supposed to be any such relationship for a cryptographic hash. (Which isn't to say SHA-1 is safe...)
$endgroup$
– Future Security
6 hours ago
1
$begingroup$
The statement "last 19 characters" is a red herring. Any change in the input on average changes half of all bits - anything else would be a serious issue for its properties. Considering the state of SHA-1, even if it is considered broken, this should still apply.
$endgroup$
– tylo
2 hours ago
add a comment |
$begingroup$
I came across a question stating:-
We have a message consisting of 10,000 characters. After computing its message digest using SHA-1, we decide to change the last 19 characters in the original message. How many bits in the digest will change if it is recomputed, and why?
Until and unless this is an explicit attack on the hashing scheme, the new hash would be different then the original one (sort of exhibiting Avalanche effect).
But I am unable to understand how does small changes in Input text, affect their corresponding Hashes. Like does there exists a relationship on how many bits of the hash will be affected, if a certain change is done to the Input text?
P.S.:- I am not a 100% sure, but I believe I have read it somewhere that a hashing algorithm should change the bits of hash by $X$% if a new character/bit is added/substituted to the previous input text.
Note:- I believe that my title isn't the best on for stating my problem. So, if anyone can come with a better title to describe my problem, then feel free to change the title, and delete this note from the description too. And if it is okay for describing my problem, then just remove this note.
hash sha-1 avalanche
$endgroup$
I came across a question stating:-
We have a message consisting of 10,000 characters. After computing its message digest using SHA-1, we decide to change the last 19 characters in the original message. How many bits in the digest will change if it is recomputed, and why?
Until and unless this is an explicit attack on the hashing scheme, the new hash would be different then the original one (sort of exhibiting Avalanche effect).
But I am unable to understand how does small changes in Input text, affect their corresponding Hashes. Like does there exists a relationship on how many bits of the hash will be affected, if a certain change is done to the Input text?
P.S.:- I am not a 100% sure, but I believe I have read it somewhere that a hashing algorithm should change the bits of hash by $X$% if a new character/bit is added/substituted to the previous input text.
Note:- I believe that my title isn't the best on for stating my problem. So, if anyone can come with a better title to describe my problem, then feel free to change the title, and delete this note from the description too. And if it is okay for describing my problem, then just remove this note.
hash sha-1 avalanche
hash sha-1 avalanche
asked 10 hours ago
Vasu Deo.SVasu Deo.S
1718 bronze badges
1718 bronze badges
$begingroup$
See also Hash functions and the Avalanche effect
$endgroup$
– kelalaka
7 hours ago
$begingroup$
This sounds like a good job interview question. (Of the fizz buzz test kind, anyway.) It must either be a trick question or come from someone that doesn't understand hash functions. There isn't supposed to be any such relationship for a cryptographic hash. (Which isn't to say SHA-1 is safe...)
$endgroup$
– Future Security
6 hours ago
1
$begingroup$
The statement "last 19 characters" is a red herring. Any change in the input on average changes half of all bits - anything else would be a serious issue for its properties. Considering the state of SHA-1, even if it is considered broken, this should still apply.
$endgroup$
– tylo
2 hours ago
add a comment |
$begingroup$
See also Hash functions and the Avalanche effect
$endgroup$
– kelalaka
7 hours ago
$begingroup$
This sounds like a good job interview question. (Of the fizz buzz test kind, anyway.) It must either be a trick question or come from someone that doesn't understand hash functions. There isn't supposed to be any such relationship for a cryptographic hash. (Which isn't to say SHA-1 is safe...)
$endgroup$
– Future Security
6 hours ago
1
$begingroup$
The statement "last 19 characters" is a red herring. Any change in the input on average changes half of all bits - anything else would be a serious issue for its properties. Considering the state of SHA-1, even if it is considered broken, this should still apply.
$endgroup$
– tylo
2 hours ago
$begingroup$
See also Hash functions and the Avalanche effect
$endgroup$
– kelalaka
7 hours ago
$begingroup$
See also Hash functions and the Avalanche effect
$endgroup$
– kelalaka
7 hours ago
$begingroup$
This sounds like a good job interview question. (Of the fizz buzz test kind, anyway.) It must either be a trick question or come from someone that doesn't understand hash functions. There isn't supposed to be any such relationship for a cryptographic hash. (Which isn't to say SHA-1 is safe...)
$endgroup$
– Future Security
6 hours ago
$begingroup$
This sounds like a good job interview question. (Of the fizz buzz test kind, anyway.) It must either be a trick question or come from someone that doesn't understand hash functions. There isn't supposed to be any such relationship for a cryptographic hash. (Which isn't to say SHA-1 is safe...)
$endgroup$
– Future Security
6 hours ago
1
1
$begingroup$
The statement "last 19 characters" is a red herring. Any change in the input on average changes half of all bits - anything else would be a serious issue for its properties. Considering the state of SHA-1, even if it is considered broken, this should still apply.
$endgroup$
– tylo
2 hours ago
$begingroup$
The statement "last 19 characters" is a red herring. Any change in the input on average changes half of all bits - anything else would be a serious issue for its properties. Considering the state of SHA-1, even if it is considered broken, this should still apply.
$endgroup$
– tylo
2 hours ago
add a comment |
3 Answers
3
active
oldest
votes
$begingroup$
For any one of the SHA hashes, the hash should be indistinguishable from pseudo-random. That means each and every bit flips with a chance of 50%. So on average half of the amount of bits gets flipped, as long as the input message doesn't repeat (because that will match 100% with the hash of the identical message, of course). It doesn't matter how many input bits are removed, added or altered, this is always the case as long as the input message isn't identical to the previous one.
Hashes are likely well distributed, so the likely number of bits that get flipped is a bell curve like you would get by throwing dice. Same thing for the number of zero bits - or one bits of course. So you cannot give an absolute number as an answer to this question. The result is not a function on $x$ if $x$ is the number of bits flipped - as long as $x$ is larger than zero.
$endgroup$
$begingroup$
So, does that mean that the change does occur in the resultant hash, but it is not guided by a predefined value. Meaning change in bits will occur, but the no. of changed bits won't be obtainable by using a formula
$endgroup$
– Vasu Deo.S
9 hours ago
$begingroup$
Yes, exactly. The chance of no change is the same as finding a specific collision of course. The chance of all bits changing is exactly as low (bell curve, right?). The chance that exactly half the bits changing is the highest, but the chance that half minus one bits are changing is pretty high as well (again bell curve). The only formula that describes this is, of course, the hash function itself.
$endgroup$
– Maarten Bodewes♦
8 hours ago
$begingroup$
"The chance that exactly half the bits changing is the highest" could you please elaborate on this?
$endgroup$
– Vasu Deo.S
7 hours ago
$begingroup$
I did elaborate on it. Bell curve. The highest bar is the most likely. Just like 7 is most likely if you throw two dice.
$endgroup$
– Maarten Bodewes♦
6 hours ago
add a comment |
$begingroup$
Actually, the number of changed bits is obtainable by using a formula. It's about 80 with a 6% probability. As you've guessed, the hash exhibits an avalanche effect. On average each output bit will flip with a probability $P =0.5$ if an input bit flips. And the output bits are independent of each other (as far as we can tell). Thus one input flip or multiple input flips has the same effect. That generates a classic Binomial distribution defined as $Bin(160, 0.5)$, resulting in $mu = frac{160}{2}, sigma = frac{sqrt{160}}{2}$.
And it will look like this:-
$endgroup$
1
$begingroup$
"The number of changed bits" is an absolute, not a probability that at least 80 bits are changed. You can calculate the probability that a certain range of bits is changed, but the formula cannot give an exact answer.
$endgroup$
– Maarten Bodewes♦
6 hours ago
add a comment |
$begingroup$
how many bits in the resultant hash will change, if the x bits are changed in its the original input
50% on average, regardless of how many bits are changed.
SHA-1, like all cryptographic hash functions, attempts to model a pseudorandom function according to the random oracle model.* This means that any change to the input will result in, on average, 50% of the output bits changing. Another way to put it is that each bit has exactly a 50% chance of toggling when the input changes. It doesn't matter what the input is and whether it differs by a single bit or nineteen bits.
In the random oracle model, every output bit is completely independent of every other bit. Because we don't have access to a "real" random oracle, we can only approximate it using mathematical functions. While this does mean that the output bits are not independent, they appear to be, and any distinguisher would constitute a cryptanalytic attack against the core hash function, which would be pretty big news.
* It doesn't model it perfectly, as evidenced by both the length extension attack and extant collision attacks, but that doesn't matter for the sake of your question. Despite its weaknesses, it still exhibits the avalanche effect extremely well.
$endgroup$
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "281"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
noCode: true, onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fcrypto.stackexchange.com%2fquestions%2f71988%2fhow-many-bits-in-the-resultant-hash-will-change-if-the-x-bits-are-changed-in-it%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
3 Answers
3
active
oldest
votes
3 Answers
3
active
oldest
votes
active
oldest
votes
active
oldest
votes
$begingroup$
For any one of the SHA hashes, the hash should be indistinguishable from pseudo-random. That means each and every bit flips with a chance of 50%. So on average half of the amount of bits gets flipped, as long as the input message doesn't repeat (because that will match 100% with the hash of the identical message, of course). It doesn't matter how many input bits are removed, added or altered, this is always the case as long as the input message isn't identical to the previous one.
Hashes are likely well distributed, so the likely number of bits that get flipped is a bell curve like you would get by throwing dice. Same thing for the number of zero bits - or one bits of course. So you cannot give an absolute number as an answer to this question. The result is not a function on $x$ if $x$ is the number of bits flipped - as long as $x$ is larger than zero.
$endgroup$
$begingroup$
So, does that mean that the change does occur in the resultant hash, but it is not guided by a predefined value. Meaning change in bits will occur, but the no. of changed bits won't be obtainable by using a formula
$endgroup$
– Vasu Deo.S
9 hours ago
$begingroup$
Yes, exactly. The chance of no change is the same as finding a specific collision of course. The chance of all bits changing is exactly as low (bell curve, right?). The chance that exactly half the bits changing is the highest, but the chance that half minus one bits are changing is pretty high as well (again bell curve). The only formula that describes this is, of course, the hash function itself.
$endgroup$
– Maarten Bodewes♦
8 hours ago
$begingroup$
"The chance that exactly half the bits changing is the highest" could you please elaborate on this?
$endgroup$
– Vasu Deo.S
7 hours ago
$begingroup$
I did elaborate on it. Bell curve. The highest bar is the most likely. Just like 7 is most likely if you throw two dice.
$endgroup$
– Maarten Bodewes♦
6 hours ago
add a comment |
$begingroup$
For any one of the SHA hashes, the hash should be indistinguishable from pseudo-random. That means each and every bit flips with a chance of 50%. So on average half of the amount of bits gets flipped, as long as the input message doesn't repeat (because that will match 100% with the hash of the identical message, of course). It doesn't matter how many input bits are removed, added or altered, this is always the case as long as the input message isn't identical to the previous one.
Hashes are likely well distributed, so the likely number of bits that get flipped is a bell curve like you would get by throwing dice. Same thing for the number of zero bits - or one bits of course. So you cannot give an absolute number as an answer to this question. The result is not a function on $x$ if $x$ is the number of bits flipped - as long as $x$ is larger than zero.
$endgroup$
$begingroup$
So, does that mean that the change does occur in the resultant hash, but it is not guided by a predefined value. Meaning change in bits will occur, but the no. of changed bits won't be obtainable by using a formula
$endgroup$
– Vasu Deo.S
9 hours ago
$begingroup$
Yes, exactly. The chance of no change is the same as finding a specific collision of course. The chance of all bits changing is exactly as low (bell curve, right?). The chance that exactly half the bits changing is the highest, but the chance that half minus one bits are changing is pretty high as well (again bell curve). The only formula that describes this is, of course, the hash function itself.
$endgroup$
– Maarten Bodewes♦
8 hours ago
$begingroup$
"The chance that exactly half the bits changing is the highest" could you please elaborate on this?
$endgroup$
– Vasu Deo.S
7 hours ago
$begingroup$
I did elaborate on it. Bell curve. The highest bar is the most likely. Just like 7 is most likely if you throw two dice.
$endgroup$
– Maarten Bodewes♦
6 hours ago
add a comment |
$begingroup$
For any one of the SHA hashes, the hash should be indistinguishable from pseudo-random. That means each and every bit flips with a chance of 50%. So on average half of the amount of bits gets flipped, as long as the input message doesn't repeat (because that will match 100% with the hash of the identical message, of course). It doesn't matter how many input bits are removed, added or altered, this is always the case as long as the input message isn't identical to the previous one.
Hashes are likely well distributed, so the likely number of bits that get flipped is a bell curve like you would get by throwing dice. Same thing for the number of zero bits - or one bits of course. So you cannot give an absolute number as an answer to this question. The result is not a function on $x$ if $x$ is the number of bits flipped - as long as $x$ is larger than zero.
$endgroup$
For any one of the SHA hashes, the hash should be indistinguishable from pseudo-random. That means each and every bit flips with a chance of 50%. So on average half of the amount of bits gets flipped, as long as the input message doesn't repeat (because that will match 100% with the hash of the identical message, of course). It doesn't matter how many input bits are removed, added or altered, this is always the case as long as the input message isn't identical to the previous one.
Hashes are likely well distributed, so the likely number of bits that get flipped is a bell curve like you would get by throwing dice. Same thing for the number of zero bits - or one bits of course. So you cannot give an absolute number as an answer to this question. The result is not a function on $x$ if $x$ is the number of bits flipped - as long as $x$ is larger than zero.
answered 9 hours ago
Maarten Bodewes♦Maarten Bodewes
57.2k6 gold badges82 silver badges206 bronze badges
57.2k6 gold badges82 silver badges206 bronze badges
$begingroup$
So, does that mean that the change does occur in the resultant hash, but it is not guided by a predefined value. Meaning change in bits will occur, but the no. of changed bits won't be obtainable by using a formula
$endgroup$
– Vasu Deo.S
9 hours ago
$begingroup$
Yes, exactly. The chance of no change is the same as finding a specific collision of course. The chance of all bits changing is exactly as low (bell curve, right?). The chance that exactly half the bits changing is the highest, but the chance that half minus one bits are changing is pretty high as well (again bell curve). The only formula that describes this is, of course, the hash function itself.
$endgroup$
– Maarten Bodewes♦
8 hours ago
$begingroup$
"The chance that exactly half the bits changing is the highest" could you please elaborate on this?
$endgroup$
– Vasu Deo.S
7 hours ago
$begingroup$
I did elaborate on it. Bell curve. The highest bar is the most likely. Just like 7 is most likely if you throw two dice.
$endgroup$
– Maarten Bodewes♦
6 hours ago
add a comment |
$begingroup$
So, does that mean that the change does occur in the resultant hash, but it is not guided by a predefined value. Meaning change in bits will occur, but the no. of changed bits won't be obtainable by using a formula
$endgroup$
– Vasu Deo.S
9 hours ago
$begingroup$
Yes, exactly. The chance of no change is the same as finding a specific collision of course. The chance of all bits changing is exactly as low (bell curve, right?). The chance that exactly half the bits changing is the highest, but the chance that half minus one bits are changing is pretty high as well (again bell curve). The only formula that describes this is, of course, the hash function itself.
$endgroup$
– Maarten Bodewes♦
8 hours ago
$begingroup$
"The chance that exactly half the bits changing is the highest" could you please elaborate on this?
$endgroup$
– Vasu Deo.S
7 hours ago
$begingroup$
I did elaborate on it. Bell curve. The highest bar is the most likely. Just like 7 is most likely if you throw two dice.
$endgroup$
– Maarten Bodewes♦
6 hours ago
$begingroup$
So, does that mean that the change does occur in the resultant hash, but it is not guided by a predefined value. Meaning change in bits will occur, but the no. of changed bits won't be obtainable by using a formula
$endgroup$
– Vasu Deo.S
9 hours ago
$begingroup$
So, does that mean that the change does occur in the resultant hash, but it is not guided by a predefined value. Meaning change in bits will occur, but the no. of changed bits won't be obtainable by using a formula
$endgroup$
– Vasu Deo.S
9 hours ago
$begingroup$
Yes, exactly. The chance of no change is the same as finding a specific collision of course. The chance of all bits changing is exactly as low (bell curve, right?). The chance that exactly half the bits changing is the highest, but the chance that half minus one bits are changing is pretty high as well (again bell curve). The only formula that describes this is, of course, the hash function itself.
$endgroup$
– Maarten Bodewes♦
8 hours ago
$begingroup$
Yes, exactly. The chance of no change is the same as finding a specific collision of course. The chance of all bits changing is exactly as low (bell curve, right?). The chance that exactly half the bits changing is the highest, but the chance that half minus one bits are changing is pretty high as well (again bell curve). The only formula that describes this is, of course, the hash function itself.
$endgroup$
– Maarten Bodewes♦
8 hours ago
$begingroup$
"The chance that exactly half the bits changing is the highest" could you please elaborate on this?
$endgroup$
– Vasu Deo.S
7 hours ago
$begingroup$
"The chance that exactly half the bits changing is the highest" could you please elaborate on this?
$endgroup$
– Vasu Deo.S
7 hours ago
$begingroup$
I did elaborate on it. Bell curve. The highest bar is the most likely. Just like 7 is most likely if you throw two dice.
$endgroup$
– Maarten Bodewes♦
6 hours ago
$begingroup$
I did elaborate on it. Bell curve. The highest bar is the most likely. Just like 7 is most likely if you throw two dice.
$endgroup$
– Maarten Bodewes♦
6 hours ago
add a comment |
$begingroup$
Actually, the number of changed bits is obtainable by using a formula. It's about 80 with a 6% probability. As you've guessed, the hash exhibits an avalanche effect. On average each output bit will flip with a probability $P =0.5$ if an input bit flips. And the output bits are independent of each other (as far as we can tell). Thus one input flip or multiple input flips has the same effect. That generates a classic Binomial distribution defined as $Bin(160, 0.5)$, resulting in $mu = frac{160}{2}, sigma = frac{sqrt{160}}{2}$.
And it will look like this:-
$endgroup$
1
$begingroup$
"The number of changed bits" is an absolute, not a probability that at least 80 bits are changed. You can calculate the probability that a certain range of bits is changed, but the formula cannot give an exact answer.
$endgroup$
– Maarten Bodewes♦
6 hours ago
add a comment |
$begingroup$
Actually, the number of changed bits is obtainable by using a formula. It's about 80 with a 6% probability. As you've guessed, the hash exhibits an avalanche effect. On average each output bit will flip with a probability $P =0.5$ if an input bit flips. And the output bits are independent of each other (as far as we can tell). Thus one input flip or multiple input flips has the same effect. That generates a classic Binomial distribution defined as $Bin(160, 0.5)$, resulting in $mu = frac{160}{2}, sigma = frac{sqrt{160}}{2}$.
And it will look like this:-
$endgroup$
1
$begingroup$
"The number of changed bits" is an absolute, not a probability that at least 80 bits are changed. You can calculate the probability that a certain range of bits is changed, but the formula cannot give an exact answer.
$endgroup$
– Maarten Bodewes♦
6 hours ago
add a comment |
$begingroup$
Actually, the number of changed bits is obtainable by using a formula. It's about 80 with a 6% probability. As you've guessed, the hash exhibits an avalanche effect. On average each output bit will flip with a probability $P =0.5$ if an input bit flips. And the output bits are independent of each other (as far as we can tell). Thus one input flip or multiple input flips has the same effect. That generates a classic Binomial distribution defined as $Bin(160, 0.5)$, resulting in $mu = frac{160}{2}, sigma = frac{sqrt{160}}{2}$.
And it will look like this:-
$endgroup$
Actually, the number of changed bits is obtainable by using a formula. It's about 80 with a 6% probability. As you've guessed, the hash exhibits an avalanche effect. On average each output bit will flip with a probability $P =0.5$ if an input bit flips. And the output bits are independent of each other (as far as we can tell). Thus one input flip or multiple input flips has the same effect. That generates a classic Binomial distribution defined as $Bin(160, 0.5)$, resulting in $mu = frac{160}{2}, sigma = frac{sqrt{160}}{2}$.
And it will look like this:-
answered 7 hours ago
Paul UszakPaul Uszak
8,1961 gold badge17 silver badges39 bronze badges
8,1961 gold badge17 silver badges39 bronze badges
1
$begingroup$
"The number of changed bits" is an absolute, not a probability that at least 80 bits are changed. You can calculate the probability that a certain range of bits is changed, but the formula cannot give an exact answer.
$endgroup$
– Maarten Bodewes♦
6 hours ago
add a comment |
1
$begingroup$
"The number of changed bits" is an absolute, not a probability that at least 80 bits are changed. You can calculate the probability that a certain range of bits is changed, but the formula cannot give an exact answer.
$endgroup$
– Maarten Bodewes♦
6 hours ago
1
1
$begingroup$
"The number of changed bits" is an absolute, not a probability that at least 80 bits are changed. You can calculate the probability that a certain range of bits is changed, but the formula cannot give an exact answer.
$endgroup$
– Maarten Bodewes♦
6 hours ago
$begingroup$
"The number of changed bits" is an absolute, not a probability that at least 80 bits are changed. You can calculate the probability that a certain range of bits is changed, but the formula cannot give an exact answer.
$endgroup$
– Maarten Bodewes♦
6 hours ago
add a comment |
$begingroup$
how many bits in the resultant hash will change, if the x bits are changed in its the original input
50% on average, regardless of how many bits are changed.
SHA-1, like all cryptographic hash functions, attempts to model a pseudorandom function according to the random oracle model.* This means that any change to the input will result in, on average, 50% of the output bits changing. Another way to put it is that each bit has exactly a 50% chance of toggling when the input changes. It doesn't matter what the input is and whether it differs by a single bit or nineteen bits.
In the random oracle model, every output bit is completely independent of every other bit. Because we don't have access to a "real" random oracle, we can only approximate it using mathematical functions. While this does mean that the output bits are not independent, they appear to be, and any distinguisher would constitute a cryptanalytic attack against the core hash function, which would be pretty big news.
* It doesn't model it perfectly, as evidenced by both the length extension attack and extant collision attacks, but that doesn't matter for the sake of your question. Despite its weaknesses, it still exhibits the avalanche effect extremely well.
$endgroup$
add a comment |
$begingroup$
how many bits in the resultant hash will change, if the x bits are changed in its the original input
50% on average, regardless of how many bits are changed.
SHA-1, like all cryptographic hash functions, attempts to model a pseudorandom function according to the random oracle model.* This means that any change to the input will result in, on average, 50% of the output bits changing. Another way to put it is that each bit has exactly a 50% chance of toggling when the input changes. It doesn't matter what the input is and whether it differs by a single bit or nineteen bits.
In the random oracle model, every output bit is completely independent of every other bit. Because we don't have access to a "real" random oracle, we can only approximate it using mathematical functions. While this does mean that the output bits are not independent, they appear to be, and any distinguisher would constitute a cryptanalytic attack against the core hash function, which would be pretty big news.
* It doesn't model it perfectly, as evidenced by both the length extension attack and extant collision attacks, but that doesn't matter for the sake of your question. Despite its weaknesses, it still exhibits the avalanche effect extremely well.
$endgroup$
add a comment |
$begingroup$
how many bits in the resultant hash will change, if the x bits are changed in its the original input
50% on average, regardless of how many bits are changed.
SHA-1, like all cryptographic hash functions, attempts to model a pseudorandom function according to the random oracle model.* This means that any change to the input will result in, on average, 50% of the output bits changing. Another way to put it is that each bit has exactly a 50% chance of toggling when the input changes. It doesn't matter what the input is and whether it differs by a single bit or nineteen bits.
In the random oracle model, every output bit is completely independent of every other bit. Because we don't have access to a "real" random oracle, we can only approximate it using mathematical functions. While this does mean that the output bits are not independent, they appear to be, and any distinguisher would constitute a cryptanalytic attack against the core hash function, which would be pretty big news.
* It doesn't model it perfectly, as evidenced by both the length extension attack and extant collision attacks, but that doesn't matter for the sake of your question. Despite its weaknesses, it still exhibits the avalanche effect extremely well.
$endgroup$
how many bits in the resultant hash will change, if the x bits are changed in its the original input
50% on average, regardless of how many bits are changed.
SHA-1, like all cryptographic hash functions, attempts to model a pseudorandom function according to the random oracle model.* This means that any change to the input will result in, on average, 50% of the output bits changing. Another way to put it is that each bit has exactly a 50% chance of toggling when the input changes. It doesn't matter what the input is and whether it differs by a single bit or nineteen bits.
In the random oracle model, every output bit is completely independent of every other bit. Because we don't have access to a "real" random oracle, we can only approximate it using mathematical functions. While this does mean that the output bits are not independent, they appear to be, and any distinguisher would constitute a cryptanalytic attack against the core hash function, which would be pretty big news.
* It doesn't model it perfectly, as evidenced by both the length extension attack and extant collision attacks, but that doesn't matter for the sake of your question. Despite its weaknesses, it still exhibits the avalanche effect extremely well.
edited 1 hour ago
answered 1 hour ago
forestforest
6,5641 gold badge21 silver badges52 bronze badges
6,5641 gold badge21 silver badges52 bronze badges
add a comment |
add a comment |
Thanks for contributing an answer to Cryptography Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
Use MathJax to format equations. MathJax reference.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fcrypto.stackexchange.com%2fquestions%2f71988%2fhow-many-bits-in-the-resultant-hash-will-change-if-the-x-bits-are-changed-in-it%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
$begingroup$
See also Hash functions and the Avalanche effect
$endgroup$
– kelalaka
7 hours ago
$begingroup$
This sounds like a good job interview question. (Of the fizz buzz test kind, anyway.) It must either be a trick question or come from someone that doesn't understand hash functions. There isn't supposed to be any such relationship for a cryptographic hash. (Which isn't to say SHA-1 is safe...)
$endgroup$
– Future Security
6 hours ago
1
$begingroup$
The statement "last 19 characters" is a red herring. Any change in the input on average changes half of all bits - anything else would be a serious issue for its properties. Considering the state of SHA-1, even if it is considered broken, this should still apply.
$endgroup$
– tylo
2 hours ago