Hot answers tagged

49

Entropy is a measure of what the password could have been so it does not really relate to the password itself, but to the selection process. We define the entropy as the value $S$ such the best guessing attack will require, on average, $S/2$ guesses. "Average" here is an important word. We assume that the "best attacker" knows all about what passwords are ...


32

You are likely going to have both false positives and false negatives if you try to use Shannon entropy for this. Many compressed files would have close to 8 bits of entropy per byte, resulting in false positives. Any encrypted file that has some non-binary encoding (like a file containing an ASCII-armored PGP message, or just a low entropy header) could ...


30

If you repeatedly apply a generic function on its result, in a finite domain, you tend to obtain a "rho" structure: at some point, you enter a cycle whose length is (roughly) $\sqrt{N}$, where $N$ is the size of the output space for your function. In the case of MD5, $N = 2^{128}$ (MD5 outputs 128-bit values), so the cycle will have length about $2^{64}$ ...


24

If taking the first or last bits of a SHA-256 output made any difference, it would be viewed as a serious blow against the security of SHA-256. Right now, no such weakness is known in SHA-256. So, as far as we know, you can use whatever bits you want. If you need a more "administrative" answer, have a look at SHA-224 (also specified in FIPS 180-3). This is ...


20

On the other hand, the Shannon entropy of a 6-sided die tossed 100 times is $-6 × 1/6 × \log_2(1/6) = 2.5849625007$ bits. That is wrong: $-6\cdot\frac16\cdot\log_2\frac16$ is the entropy of a single die roll. Assuming the $100$ die rolls are independent, you can simply sum the entropies of the individual rolls to obtain $$ 100 \cdot\left(-6 \cdot\frac16\...


18

I will answer considering Linux OS, as being one of most popular Unix-like OS (between OSes which have urandom). If you need other OS, please, inform me. Also I will answer using source code of random.c driver from Linux 3.3.3 Kernel, because it is one of best documentation of /dev/random mechanics. And the other is paper: Analysis of the Linux Random Number ...


18

First of all, there is a difference between writing to /dev/random and/or /dev/urandom and increasing the entropy count maintained in the Kernel. This is the reasony why, by default, /dev/random is world-writable - any input will only augment, but never replace the internal state of the RNG; if you write completely predictable data, you're doing no good, ...


18

Even in context, much of what is written in the blog post makes no sense. E.g., it says: While it can be argued that the DRNG is in reality just splitting a 128-bit value into two pieces and handing them to you one piece at a time, from a theoretical viewpoint this does not matter. While the original value had 128 bits of entropy, the end result is that ...


17

Is it possible to securely transfer random values in such a way that they are still viable for use in cryptography? Yes and this is done all the time. If you use a TLS_RSA cipher suite, the client uses RSA to encrypt key material, i.e. random values, and transfer that securely to the server for key derivation. The owner of the random.org service ...


15

You're absolutely correct: numbers (or a given binary string) don't have entropy. However, a number can be sampled from a distribution that has entropy. In other words, the entropy is a property of the process used to generate a number, not of the number itself. So if I just give you the number 4, and assure you that I picked this number uniformly at random ...


14

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 $2^s$ possible values. When processed with a random oracle with an $n$-bit output, you force the $2^s$ input values into $2^n$ possible ...


13

To give you a short answer to your question: The common notion of entropy is the notion of Shannon entropy. The information content $H_x$ of a value $x$ that occurs with probability $\Pr[x]$ is $$H_x = -\log_2(\Pr[x]) \text.$$ The entropy of a random source is the expected information content of the symbol it outputs, that is $$H(X) = E[H_X] = \sum_x \Pr[x]...


13

The answer rather depends on what you mean by 'entropy'; if you mean 'Shannon Entropy', then no, a deterministic function cannot increase entropy. For example, if the unhashed password has only 7 different possible values, then the hashed version of the password will also have (at most) 7 different possible values; you've made things look more obscure, but ...


12

Very short answer: No Quite Short answer: No, because a scheme can only be a One-Time-Pad if the entire pad is perfectly random and secret. Concise answer: It sounds like you're trying to build a stream cipher. The security of it really comes down to how much of the scheme you think can be kept secret. If I listen in to your wifi and hear you requesting a ...


12

First let's say that entropy is a property of a generation process. A number, by itself, does not have any entropy. What has entropy is the algorithm or process which has produced that number, and the entropy measures what the number could have been. In that sense, the formulation in the Wikipedia page lacks rigour. For a "nothing up my sleeve" number, we ...


12

If one source remains uncompromised plus statistically random on all bits, and both sources remain independent, then a xor of both sources together can also be considered uncompromised plus statistically random for all bits. Basic proof: Label the the results two RNGs $X$ and $Y$, consider bits $X_n$, $Y_n$ and $Z_n = X_n \oplus Y_n$ Assume each value ...


12

It seems that with your shannon entropy, you are using 100 tosses to estimate the shannon entropy of a single die toss. If it is a fair die, that would be $\log_2{6}\approx 2.58$. This is different from rolling a die 100 times to generate a cryptographic key, for example. Each roll of the fair die would contain $2.58$ bits of entropy, so in total you would ...


12

I know that humans would find it impossible to maintain a 128 bit password -- however, I wonder if there is some technical reason why a 52 bit password would not be as weak as a 52-bit encryption key for that matter. First, I would argue that 128 bits is not impossible to remember. My current password manager master password is almost 100 bits (6 words ...


11

Well, your definition of entropy is known as Kolmogorov complexity, and it's not so much that it is incorrect, as it is that it is inapplicable to what gzip does. For example, the value $\pi$ can also be generated by a short program; however, if you attempt to compress a 2.2Mbyte sample of the binary expansion, you'll also find that gzip will also not be ...


11

No. This is not safe. The one-time pad requires that the pad be generated by a true-random process, where each bit of the pad is chosen uniformly at random (0 or 1 with equal probability), independent of all other bits. Any deviation from that, and what you haven't is no longer the one-time pad cryptosystem -- it is some kludgy thing. In particular, once ...


11

Entropy is a function of the distribution. That is, the process used to generate a byte stream is what has entropy, not the byte stream itself. If I give you the bits 1011, that could have anywhere from 0 to 4 bits of entropy; you have no way of knowing that value. Here is the definition of Shannon entropy. Let $X$ be a random variable that takes on the ...


11

It is feasible to generate 300 million public key pairs of reasonable strength in 8 hours on a single computer, easily with ECDSA using a single core/thread, and even with DSA using quite a common multi-core computer. RSA would require many standard computers (baring hardware accelerators for modular exponentiation), assuming all the public keys are made ...


11

You've actually been trapped by the mindset that OTP will hide all information about the underlying plaintext. This is not true as you have observed. The definition of perfect secrecy, given in Introduction to Modern Cryptography by Katz-Lindell, reads like this: Definition 2.3 An encryption scheme $(\text{Gen, Enc, Dec})$ with message space $\mathcal ...


10

Prove resistance to differential cryptanalysis. For example, this presentation: Provable security against Impossible Differential Cryptanalysis. Or this paper: ProvableSecurity Against a Differential Attack (1995) Prove resistance to linear cryptanalysis. For example: On Measuring Resistance to Linear Cryptanalysis Run a bunch of statical tests against ...


10

Assuming the n-bit CRC of an unknown bit string b is known, one can constructively rebuild any consecutive n bits of b from the rest of the bit string (and the definition of the CRC). Indeed, in the case described, that speeds up password search considerably. One can compute the last 32 bits of the password (likely, 4 characters) from the beginning of the ...


10

Their numbers are off and the explanation confusing, but they do have a point. The algorithms used for RDRAND/RDSEED instructions are described in the software implementation guide (pdf). What it amounts to is that for RDRAND, some hardware entropy is conditioned and used as a 256-bit seed for AES CTR_DRBG (from SP 800-90A). The same 256-bit seed is used ...


10

The entropy for the output of SHA-256 truncated to its first $128$ bits when fed a random $128$-bit input is about $127.173$ bit, down from very close to $128$ bit before truncation (see final note). The truncation does not halve the entropy, because the halves are not independent. The right line of thought is that SHA-256 truncated to its first $128$ bits ...


10

In World War II, this practice of generating "random" code books by hand is known to have been used by the Special Operations Executive, or SOE: Various techniques have been used to do the random generation. Marks describes how SOE agents’ silken keys were manufactured in Oxford by little old ladies shuffling counters. (Security Engineering: A ...


10

I believe Thomas Pornin's answer is by far superior to mine, but perhaps this answer can provide a simplification to his answer. When you initially hash some data, the possible input is infinite/limitless. You could input "abcdefghi...", "123456...", etcetera. However, the resulting hash possibilities are finite/limited. One of the beautiful things about ...



Only top voted, non community-wiki answers of a minimum length are eligible