# Tag Info

16

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 more ...

14

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 ...

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 ...

9

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 ...

7

Bill is right. To give you a short answer to your question: The common notion of entropy is the notion of Shannon entropy. The Shannon entropy H(x) of a value x that occurs with probability Pr[x] is H(x) = -log_2(Pr[x]) you can interpret this as the uncertainty about x knowing only the distribution according to which x is chosen. For the case of bit ...

7

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 ...

6

You should not remove any part of the pool, or do some more-or-less random selection out of it. Instead, just hash the whole thing with SHA-256. This will get you all the entropy there is to get out of the data, up to 256 bits, which is more than enough. Once you got 256 bits of entropy, i.e. you accumulated physical measures which should amount, together, ...

6

The bits are not independent from each other, at least within an individual song, so the pad is not truly random, thus this is not a one-time-pad. Perhaps a hash-based approach would fix this, but... ... there are a limited number of songs available, a simple attack would then be to enumerate every song (in the same format you describe) and try to decrypt a ...

5

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 ...

5

In my practice (Smart Cards, often using DES and increasingly AES) Key Expansion is often used to designate production of subkeys in a block cipher. This process is often a mere bit extraction, as part of the algorithm's Key Schedule. Key Diversification is, almost exclusively, the process of producing a device key from its serial number (or other ...

5

Entropy is not gas -- you do not "consume" it. In the case of hashing passwords, entropy is a measure of what the password could have been. A password with "$n$ bits of entropy" is a password such that breaking it by dictionary attack (trying potential passwords until the right one is found) has average cost $2^{n-1}$. It is useless to have a password ...

5

No, your formula isn't correct. I don't know how you came to it, so I don't know what's wrong with your intuition. You can check whether your formula makes sense with dimensional observation — it's the same kind of reasoning that helps a lot in physics. Write all numbers with their units: entropy rate = 1.5 bit/character random key size = 128 bits ...

4

A quite common way to actually prove something is building a system on already known components, and then proving the security of the composed system, given the security of the components. Most often the paper has a theorem like If the function F has property Y, then this new function G has property X. The proof then shows that if someone can attack ...

4

What you ask for is a RNG to produce some output which another RNG will use as seed. This looks quite overly complex... The point of the seed is to be unknown to the attacker: the seed data should be such that "trying out" possible seed values should not match the actual seed except with negligible probability. With a 64-bit seed, even if the seed is ...

4

Well, from your previous questions, I'm assuming that your writing a utility to brute-force decrypt a password protected file (encrypted with a certain encryption utility), and you're looking for a way to determine whether your trial decryption is plausible. Normally, when an attacker attempts to decrypt something, he has some idea about what it is (why ...

4

You should not use the raw data of any image as a one time pad. This is even worse with an image of a sky, because of the large amount of blue pixels. For all images, adjacent pixels tend to be the same colour - which means there is a large amount of repetition. If you want to use some of the data of the image as a one time pad, you will need to condition ...

3

The reason repetition is so dangerous is imagine trying to attack a worst case scenario: a BMP picture file that contains all black. The contents of the image file will be #000000 #000000 #000000 #000000 ... Now consider how a one-time pad works: it XORs the cleartext with the bit stream. So if your plaintext was "ATTACK ON 10 SEPT", and you XORed it ...

3

The amount of randomness in common pictures has actually been studied thoroughly, just not for applications to encryption, but rather for stenography. An artifact of images is that the least significant bit (it is what changes between slightly different shades of blue) has the highest entropy. A simple stego-system is to overwrite the least significant ...

3

Well, no, in general, it is not. Here's a simple example that demonstrates it is not: Suppose that $m=2$, $n \ge 3$ and the matrix $A$ can take one of the following two values: $\pmatrix{1&2\cr1&1}$ with probability $1/2$, and $\pmatrix{1&2\cr1&2}$ with probability $1/2$ Note that the first matrix is nonsingular (invertible), while the ...

3

The usual assumption is that the attacker knows a full plaintext block; that's what the EFF DES-cracking machine uses. That machine knows exactly 8 consecutive plaintext bytes and the corresponding ciphertext block; it stops when it finds a matching key. Since there are 256 possible DES keys, and 264 possible 8-byte blocks, chances are high that there is ...

3

The high level architecture is alright. You implement a sponge-like structure that absorbes randomness from any source, and when you need randomness back, you squeeze it out. (Note: there actually is something called a cryptographic sponge, used in some new hash functions, which I am not referring to although it is related). There are a few improvements you ...

3

Summary: an entropy argument shows that block encryption in counter mode can't be perfectly secure. The remark that any block cipher in CTR mode generates a keystream with very low entropy per bit of keystream is correct. That hints CTR mode is not secure against an hypothetical unbounded adversary. In fact that holds as soon as more bits of keystream are ...

3

Still 30 bits. A hash function does not add entropy. It could change the entropy rate though. For example if you had 30 bits of entropy in a 64 bit password and hashed it to a 128 bit digest, the rate has gone down ($\frac{30}{64}\approx 0.47$, but $\frac{30}{128}\approx 0.23$). On the other hand, if the password is 500 bits, the entropy rate goes up. One ...

2

Information entropy is closely related to the "predictability" of the same information. When we talk about password entropy we are usually concerned with how easy it is for a password cracking software to predict a password. The more passwords the software has to try before guessing the password the larger the entropy is. You can check software like John ...

2

The most important take-away is that if you are asking this question, you are almost certainly not qualified to design a secure cryptographic primitive. Sounds harsh, but I mean it in all earnestness. You wouldn't trust someone who hadn't been to medical school to do surgery on you. Similarly, we wouldn't trust someone who doesn't already know the ...

2

There is no good way to stretch your 64-bit seed value without some secret material. Anything deterministic you do is bound to be vulnerable to enumeration of all 64-bit seed values. The least wrong option is to use a purposely slow derivation function designed for passwords, e.g. Scrypt. With some $Secret$ material assumed hidden from an adversary, you ...

2

For cryptographic hash functions we usually want to avoid collisions as much as possible (and even more we want to avoid any way to get from the output back to the preimage). So what you want certainly is not a cryptographic hash function, but something else. On the first look, something like a CRC (cyclic redundancy check) could fit your bill. These have ...

2

What you are doing sounds a lot like what the /dev/random and /dev/urandom or the PRNGD on many systems already do: those systems take an arbitrary large sequence of numbers (from a true hardware random number generator if available, or else from environmental noise such as keystroke timing) and feed it into a CSPRNG. The CSPRNG internally maintains an ...

2

Great question. I had actually been thinking about the same thing some time ago, but I realized that using an image as a one-time pad isn't a good idea. Try to take some random pictures and then open the pictures with a hex editor (like XVI32). I did that and noticed that the bytes were not all that random, for example many picture files have a lot of 0x00 ...

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