But as I said, you should first fully understand the problem yourself (to correctly scale down). That's basically how any scientific discipline is taught. If you are a university professor or a school teacher, you always proceed from the lower scope all the way up to your own limits or limits required by the curriculum. I can't explain the measurement problem in quantum theory because I don't understand it myself, but whatever I understand I can always (I repeat again, always) explain it in a few sentences within the scope of understanding of whoever may get interested. As an aside, that's basically what makes an interesting read
You have no idea how ironically wrong your message is if you would know who I am.
If your fundamental thesis is that everything is explicable to anyone "in a few sentences", your pedagogical (and most probably your academic) skills are very limited, and the proof of that is so terribly simple that it is stultifying that you can't grasp it:
most courses by "professors and school teachers" take more than a few sentences. Most scientific papers are more than a few sentences
I don't care who you are
If you talk bullshit that will remain bullshit no matter who you might be (though I really doubt that you are somebody). For a pissing contest, you may want to look elsewhere (iamnotback will make you a good company, I guess). The aim or courses is to expand knowledge base but you can't expand without proper understanding what has been explained before. And this expansion is done in small increments, basically, a thing explained conceptually in a few sentences if you please and then elaborated to gory details. Going down the learning curve is a pretty good test to see the real level of understanding the subject. In other words, if you can't explain a thing in simple terms within the scope of someone's understanding, your abstruse verbiage goes straight out the window even if it is technically correct (while in your case it is no more than just empty verbiage)
It is a pity that you have turned this learning opportunity in a pissing contest, as you say, because of your unwillingness to admit that your lack of attention span width rendered your initial technical and erroneous objection moot when engaging in a technical discussion, which I tried to keep as simple and to the point as possible.
Re-read the posts from there, and you will see that your shifted attack, namely "you couldn't explain why I was wrong in a few sentences", is a childish response to someone who had taken the pains to explain to you in HALF A PAGE with a mathematically traceable example exactly where the problem in your objection was lying.
In other words, we have the typical example of the not too smart student that tells the professor he's wrong, and when the professor gives him a more involved proof on the black board, goes whining that the argument is too long and hence the professor is an asshole that doesn't know how to teach.
Again: in one sentence:
you are confusing entropy of secret key/password with brute-forcing hash functions.Short enough ?
Here are (again) the longer explanations:
You confused me since I wasn't thinking quite clearly yesterday
Indeed, this approach doesn't add to security, but that was not my point initially which I somehow lost during this conversation with you myself. My point is that if you are reversing the hash function you will still have to brute force all passwords as you would do if there was no hash function at all.
Yes, so ?
In this way, hash function doesn't lower the security which you seem to accept yourself, and this was exactly my point.
No, of course not, it conserves entropy as long as the input is smaller than the output. But that was not the point. In other words, your example is right, but non sequitur for what I said earlier.
In other words, you would anyway do the same amount of work, and there is no shortcut or backdoor which could give you a clue what a password might be, for example, its length
Nope. That's your error.
Providing a "hash with conditions" is a proof of work *because of the assumed irreversibility of the hash function* ; because you have no other way of satisfying the condition on the hash output, but to try randomly at the input.
However, if you crack the hash function, that is, if you can find EASILY all input solutions that give a given output hash, then providing a hash that satisfies a given condition is NOT a proof of work any more.
This has nothing to do with your example of transforming entropy, because proof of work is not a matter of entropy.
Let us take a very simple example. Suppose my silly hash function is again:
f(n) = (K.n + C) mod M, with K,M and C fixed parameters of the hash function. I'm a naive guy thinking that my hash function is a good, irreversible function.
Essentially, my hash function takes on ANY number n, and produces a number between 0 and M-1. Let us say that M is a big prime number, with 256 bits, and K is of that order too and C too. If you put arbitrary numbers into this function, you get arbitrary-looking numbers out.
Now, if I want you to give me some proof of work, I give you a number A, and I want you to find a number N so that:
f ( f(N) XOR A) < Z
If my hash function is irreversible, the only thing you can do is to try this function so many times as needed, which must be on average 2^256 / Z times.
However, if f is reversible (and it is !), I pick a number, say, Z/2. I calculate (easily) an inverse value U such that f(U) = Z/2. I calculate easily V = A xor U, and I calculate just as easily W such that f(W) = V.
W satisfies the condition I asked, but I didn't have to provide for any work of the order of calculating 2^256 / Z hashes. Hell, I could put in Z = 0, and with the same effort, I calculate U' such that f(U') = 0 (even before you gave me A!) ; I calculate V' = U' xor A ; I calculate W' such that f(W') = V'. Done.