If all it does is prevent length extension attacks, then there are much simpler and less risky ways to do that (i.e., MD variants).
Also, your explanation of the sponge structure omits the real difference between it and MD: It is a transform that turns a non-compressing function (f in that diagram) into a compressing function. MD, on the other hand, starts with a fixed-input-size compressing function and extends its domain.
By the way, what do you mean by "Furthermore, Keccak's Sponge design derives security by only allowing inputs to directly influence a subset of the internal state bits."? That's as true for an MD-type construction as it is for a sponge construction. In fact, it's a crucial fact that allows us to build a reduction from, say, the collision-resistance of MD[f] to the collision-resistance of f.
Regarding the bits exposed to inputs in Keccak, I read the claim in the same manner as the claim that CTR is more side-channel resistant because attacker ciphertext bits never hit the AES core; here further margin is given by the additional capacity bits. That's my attempt at exposition from the Sponge paper. You would know far better than I would, though; I'm a tester, not a cryptographer.
Regarding length extension, strong disagree; we see the SHA functions routinely abused this way.
BLAKE and Skein inject a message block by first running it through the block cipher (as key in BLAKE, as plaintext in Skein), and then XORing the result with the message block to get a new state. JH XORs message block into one half of the state before permutation, and into the other half after it. Keccak XORs message block into a part of state before permutation, and that's it.
He is mistaken. What he meant is that there exists a finite field with exactly 256 elements, so you can "make" {0, ..., 255} into a finite field (in the sense that you can make any set of size 256 into a field by assigning + and * operations), but addition and multiplication in that field won't be the usual modular integer arithmetic. Instead, the operations will be determined by mapping the numbers to polynomials and performing modular polynomial operations and then mapping them back to numbers {0,...,255} (or determined by some other process that is morally equivalent).
Cryptographic hash functions, by contrast, are not well understood at all. They are "magic" in many ways, and aren't modeled after anything. Many more "bad things" happen in this space than in the block cipher space.
Is this a common opinion amongst practitioners? The opposite philosophy (e.g., that a random oracle is a "weaker object" than an ideal cipher) underlies some lines of work in the theoretical cryptography literature.
If this kind of thing takes off, it will become easier for dictionary based password attacks. Using this advice would go a long way towards preventing this.
Easier, yes, but not easy. A dictionary attack on 4 words is the same as brute forcing 4 letters except now instead of just 26 letters there are thousands. 2000^4 vs 26^4 = 35,000,000% more to check.
Not only are these just trying establish if you're in the club or not, but judging from his answers on the DH vs RSA questions (which are not-well formed to begin with), it seems like he's trying to establish if you're in the club that knows the names but has no knowledge of WTF is actually going on in crypto.
I'm the author and I wouldn't say I am a crypto guy, but the conceptual difference between RSA and DH is clear to me, and I defend the proposition that it should be for others in infosec as well.
I can't speak for the parent comment, but saying that "Diffie-Hellman" is a good answer to the problem of establishing a secure channel over an untrusted medium is like saying "plutonium" is a good answer to the problem of submarine propulsion.
It's a category error to those well-versed in cryptography, like "explain the difference between mergesort and recursion" - two unrelated concepts. (Whereas "explain the difference between quicksort and mergesort" is an interesting question.)
Your answer also does not sufficiently differentiate between e.g. key agreement (DH), message authentication ("signing"; HMAC), symmetric encryption (AES), or asymmetric encryption and signing (RSA).
It's the most counter-intuitive thing in the world that rand() rand() is less secure than rand(); shouldn't it be twice as unpredictable?*
Under some reasonable assumptions, rand() + rand() mod 1 is twice as random! If both calls return independent samples, and at least one of the calls to rand() returns a uniform sample in [0,1], then the sum will be uniform on [0,1].
So if you assume you get at least one good shot and that the other is not specifically correlated to it, you'll be improving your randomness.
How is that related to the SO question? The post is asking about how to tell if one distribution is "more random" than another, which is what entropy is all about.
Consider a random number generator that produces integers between 0 and 15. Here's a really crappy algorithm:
1. Start with a truly random seed between 0 and 15.
2. Increment it each time to generate a random number, modulo 16.
Suppose you start at 11. Your sequence of random numbers will be 11, 12, 13, 14, 15, 1, 2, 3 ....
This is obviously not very random. But look at the entropy of it. All values between 0 and 15 are equally likely, so this will have the maximum possible entropy: 4 bits.
The problem here is that, for entropy to be an accurate measurement of information content, you have to assume that you're measuring independent identically distributed random variables. The outputs from a pseudo-random number generator are not independent.
If we are interested in a _sequence_ of pseudorandom numbers, then we should be talking about the _joint_ entropy of the sequence. But information theory is plenty capable of describing "how random" a sequence is.
The generator you are talking about is far from producing a uniform distribution (which would have maximum entropy) jointly over the n-dimensional hypercube that would represent a sequence of n draws from your generator, so it has less entropy and is thus "less random" than the distribution you'd get from n independent draws from a perfect rand().
During my first semester in college I took a course that used these notes. It was perhaps the most valuable course I took in college, as I subsequently became a researcher in theoretical computer science (and honestly taught myself a lot of the rest). The value in this type of course is that it introduces very green high school graduates to the type of thinking necessary to reason about proofs. The time required to build up the theory of groups/rings/modules/fields or measure-theoretic probability (is that what you want CS freshman doing?) would be wasted, as those topics are largely beside the point of the course. A sprinkling of conditional probability will at least give them something to remember in their randomized algorithms class.
I don't think the course is worth the time for anyone. Yes, maybe a freshman could struggle through it, but freshman need to be in a hurry to get to the 'good stuff' and have better things to do.
Students, be warned: I know all the material there much deeper than there and have done applications to military and commercial problems and have published peer-reviewed work in applied math, mathematical statistics, and artificial intelligence, and I don't think that book is worth your time or effort -- you need better material.
The quality level is just too low:
A quality problem in the book is a lack of emphasis on proofs which are the main means we have to get new results we know are correct and know that long before some rack of computers has served one million unique users a day.
The math background in Knuth 'The Art of Computer Programming' is done with much higher quality.
Of course, measure theory, say, from Papa Rudin, is the way to do probability, but it is not done that way often enough in the US: Nearly the only people who take Papa Rudin are pure math grad students, and pure math in the US doesn't much like the applications to probability.
Still, it is quite possible to give a MUCH better treatment of probability with just calculus plus, say, a few theorems about calculus, e.g., about improper integrals and interchange of order of integration, usually not covered in undergrad calculus.
Yes, conditioning is a big deal, should be covered, and is touched on in the book. But more is needed in conditioning. Then the classic limit theorems should be covered -- at least the weak law of large numbers and the central limit theorem.
For computer science, it would be super nice to cover Poisson processes and the renewal theorem since operational networks and server farms are awash in these processes.
There are plenty of good books on probability without measure theory although I am not a fan of Feller I because it is too difficult to see the forest for the trees and too easy for an unguided tour to get lost.
