# Tag Info

0

The PC-2 substitution transforms the 56-bit concatenation of the 28-bit $C$ and $D$ after they have been appropriately rotated, into the 48-bit subkey $K_i$ for round $i$, before that is combined using XOR with the 48-bit output of expansion $E$ and divided into 6-bit entries for each of the 8 S-tables. The table defining PC-2 is correspondingly organized as ...

-1

Now the standard key size for RSA is recommended of 2048 bits. This is large enough to never having a collision in practice, where brute force is 2^{2048}. Even if we consider some attacks that allow to break it with half the key size or in birthday attack, this number is quite secure. However, larger the key size, more overhead and lower efficiency.

1

This depends on the MAC because there are different kinds of attacks to consider. If the best attack is randomly trying authentication tags, then the key does not matter. If the best attack is brute forcing the key, then key renewal does mean that the attacker has to "start anew", but as long as the key space is large enough that the probability of finding ...

1

Well, as SEJPM and Mok-Kong Shen pointed out, it's described in FIPS 197, but let's explain it in details: Here's the Key Expansion algorithm pseudo-code from FIPS 197: Where $Nk$ is the number of $32$-bit words that composed the key $Nr$ is the number of rounds $Nb$ is the number of columns in the state block (which is always $4$). $word$ is a ...

5

Many keys do not consist of a single value. Other key types, such as most symmetric keys, don't have a most significant bit or byte as the key value isn't interpreted as an integer. So this question would be different for each key type and encoding. In general though you would just decrease the "entropy" or key size. This is certainly the case for ECC, and ...

3

If a cryptosystem is expecting a 16-byte key, making the first byte nonzero simply reduces the number of possible keys. It is better to allow all bytes to be all values.

0

Permuted Choice 1 selects 28 bits for C and 28 bits for D from the input 64 bits. The remaining 8 bits are odd byte parity. From FIPS 46-3, Data Encryption Standard (DES) (withdrawn May 19, 2005) We see Permuted Choice 1 expressed (PDF page 24): Reading the text associated with the table you'll find there are two groups of 28 input values each ...

1

The parity bits act as error checking. In effect there is only 56 bits being used for entropy. Also This question has already been answered. See similar question here or here

4

Each 56-bit key has a unique 8-bit parity value. For this reason there are only $2^{56}$ keys.

0

Are you implementing this for cryptographic purpose ? If so, you should use True Random Number Generators (TRNGs) to generate your master key.Your key should have following properties: Statistical independence = For a given generated sequence of values, a particular value should not be more likely to appear next. Uniform distribution = All numbers are ...

0

You have to be sure that blocks of data would have sufficient size such that equivalent key size remains secure. Also the key should only be used once. Once you have a secure PRG then you can employ a stream cipher like XOR encryption. This comes however with the disadvantage of having key size equal your data, and the key should be used once

9

XORing a master key (presumably a long term key) with data is a very dangerous idea. If any data key is leaked, then the master key may be easily calculated, thus leaking all keys. ($m$ for the master key, $d_x$ for all data keys) $$c_x = d_x \oplus m$$ then somehow $d_4$ is leaked $$m = d_4 \oplus c_4$$ $$d_x = c_x \oplus m$$ You'd be better off applying a ...

-1

If done right, XOR can be used to encrypt data. One way to do this, is to generate a pseudo-random key-stream using your master key and XOR the key-stream, which needs to be as long as the data, with the data. The key-stream can be generated using a block-cipher like AES. This is how AES-CTR (Counter) Mode works.

Top 50 recent answers are included