NETWORK SECURITY ROLLNO-15MCE1036

HOT QUESTIONS ON RECENT TRENDS

For example, if I have a bit stream that is 64K bytes long and there is about 16 *8 bits worth of
entropy randomly dispersed in that byte stream, so I have 16*8 bits worth of entropy.

However, if I SHA256 that byte stream, I will now only have 32 bytes total rather than 64K
bytes.

(OR)

Another way of looking at the question, is the entropy of SHA256(10GB with 16 bytes of entropy) equal
to SHA256(16 bytes with 16 bytes of entropy) and if not, how much exactly has been lost?

Sol:- A simple way to imagine the effect of the hash function is a truncation. A "good" hash
function ought to behave like a random oracle. If your source has entropy s bits, then this means
that the source somehow assumes 2s possible values. When processed with a random oracle with
an n-bit output, you force the 2s input values into 2n

possible outputs.

When s

is smaller than n/2, then it is expected that the hash function will produce 2s distinct values, and
all your s bits of entropy are preserved. When s reaches n/2, collisions begin to appear, and
each collision means a tiny fraction lost entropy. You still preserve most of it, though. When s
reaches n (e.g. you hash an input with 256 bits of entropy, with SHA-256), then it is expected
that you get about 0.62s distinct output (you lost one third of the inputs to collisions), so the
resulting entropy will be a bit more than n1 bits. When s is higher than n, the output entropy
will still rise, but never exceed 2n: you cannot have more than 2n distinct outputs of n

bits...

To sum up, when hashing your input, you preserve almost all your input entropy, up to at most
the output size of the hash function. To make things simple: when you hash with SHA-256 an
input of entropy s

bits, then you get an output entropy at least equal to the lower of s1 and 255 bits.

2) Does the position of the salt improve its effectiveness when hashing?
Sol:-

If the hash function is a random oracle, then the salt can go wherever you wish, it will do its
job.

On the other hand, there is, arguably, no such thing as a random oracle. On an existing, real,
tangible hash function, details on how you input things may or may not trigger slight structural
weaknesses in the function, which could impair the role of the salt, which is to prevent an
attacker from doing exhaustive searches ("dictionary attacks") in a parallel way (time-wise or
space-wise). In particular, on Merkle-Damgrd hash functions (such as MD5, SHA-1 or SHA-
256), the so-called "length extension attack" may be relevant.

So this is a matter of some delicacy. It seems best, generally speaking, to use constructions
which have benefitted from wide scrutiny by many people. Salts are from the password-hashing
business, and known good constructions for transforming passwords into keys are PBKDF2 and
bcrypt.