|
I understand that hashing a datetime is a pseudo-random number, and not good in a security context. But what about hashing a datetime plus a truly-random but constant string (just a string that an "attacker" could not possibly guess)? This is not a question for a practical implementation, just a theoretical question. Is pseudo-random plus a bit of "true random", "fully-random"? (p.s.: I'm not a security specialist, so please don't use overly-complex terms if possible.) |
||||
|
|
|
Let's look at this from the bottom ("what is random?") to the top (is that secure?). When we talk about "random" in cryptography we almost always prefer to talk about "entropy". The intuitive and concise definition of cryptographic entropy is that it is a measure of how much information the attacker does not know about the target message. When you hear about, for example, "128 bits of entropy" in cryptography, it essentially means that the message has 128 bits of information that the attacker is expected to not know about, and thus a total $2^{128}$ possible values that, from the attacker's perspective, could be the one they're looking for. For example, a 100-bit string might be generated by always prefixing a So then, what's the entropy of "pseudo-random"? A pseudo-random string is just something that looks random (ie, passes all good tests for randomness) but is deterministically derived from an input. So the amount of cryptographic entropy in a pseudo-random string is actually the amount of entropy in the seed input that was used to create the pseudo-random string. This is because if the attacker can determine the seed, then they too can generate the resulting pseudo-random string. So from the attacker's perspective, the number of possible pseudo-random strings is simply the number of possible inputs that could have been supplied. (This fits with the above notion of cryptographic entropy.) Why the distinction between "entropy" and "random"? Because we have have strings that look very random but actually have low entropy. (Such as a pseudo-random generator that always looks random regardless of the input.) In cryptography we don't usually care how random a secret looks but rather how hard it would be to re-create, and as far as vocabulary goes, "entropy" is more explicitly a measure of the source of the string, not the content. (However, for what it's worth, the terms "random" and "very high entropy" often seem to be used interchangeably amongst those familiar with the concepts.) So what does your proposed scheme do with entropy? Your time-stamp will have some entropy, but it's unclear how much. The attacker will likely know something about the time-stamp (such as the year it was generated) but not everything (such as the exact millisecond). So the entropy won't be maximal or minimal for that source. For your secret string, it will have entropy because it has some information unknown to the attacker. If it's a string you hand-designed then it is highly unlikely it has full entropy, but it does likely have some entropy if you put any effort into designing it. (Without knowing more we can't estimate how much entropy your string has.) The fact that you hash the concatenation of your strings does not change the amount entropy. The attacker still needs only to guess the input to the hash function. The hash will act similar to the pseudo-random generator above in that it will provide random-looking output that conceals the content of the input. But the attacker's job is simply to guess the input to that hash and so the measurement of cryptographically secure entropy is the same despite the use of the hash. The same number of original message possibilities remain, from the attacker's perspective. To address your italicized question: A message that is "fully random" is going to have entropy the same size as the message. For example, a truly random 128-bit key will have 128 bits of entropy, but 128-bit key with 127 bits of entropy is probably not going to be considered "fully" random. But practically speaking, we actually don't really care about having full entropy, we care about having enough entropy. A 128-bit string with 128 bits of entropy is, in theory, just as secure as a 500-bit string with 128 bits of entropy, especially if you're going to put it through some sort of function like a hash or a PRG. If security is your goal, be primarily concerned with how much entropy you collect and less so with how many bytes it took to do so. The summary here is that a string has at least as much entropy as its highest entropy source. If you concatenate a weak string with a strong string, your result is a strong string. If you have a weak string and add a strong string and hash the two, the hash output should be a strong string. |
|||||||||
|
|
First off as yet there is no such thing as fully random unless you have access to quantum cryptography. Even the best random number generators are pseudo random on conventional hardware. If you did have access to a truly random source and you mix even a bit of pseudo-random numbers in the result cannot be considered truly random anymore. From a cryptography standpoint though if you mixed a small amount of pseudo-random with a whole lot of truly random numbers the result would likely be considered random enough for most applications. |
|||||||||||
|
