# Tag Info

4

No, it's recommended to use a well described KBKDF (key based Key Derivation Function). If you like counters you could try NIST SP 800-108 section 5.1: KDF in Counter Mode. But note that it doesn't use Counter Mode encryption; rather than that it uses a counter combined with a PRF: HMAC or CMAC. If you use CMAC you could still use AES (or any other secure ...

1

I'll write down the definitions for tweakable block ciphers and ideal block ciphers, and hopefully the distinction becomes more clear. A tweakable block cipher is a function $E:\mathsf{K}\times\mathsf{T}\times\mathsf{X}\to\mathsf{X}$, where $\mathsf{K}$ is the set of keys, $\mathsf{T}$ the set of tweaks, and $\mathsf{X}$ the inputs. In particular, it should ...

5

Block size does not directly affect the security of the cipher. However, if block size is too small, it can prevent you from using the cipher securely. The main effect of block size is due to the fact that a block cipher is meant to be a pseudorandom permutation (PRP). That means that any two inputs will have outputs that differ iff the inputs differ. So ...

5

Block ciphers are usually used in modes of operation. The security of a mode of operation depends on two things: the security of the underlying block cipher, and the security of the mode itself when you replace the block cipher with an "ideal" permutation. Say you're using a block cipher with block size $n$ bits, so with AES-256, $n = 128$ (the 256 refers ...

4

As Maarten Bodewes points out, you should use a known key derivation function instead of this method (i.e. don't roll your own crypto). Having said that we can still try to understand what happens if you do use this method. I assume that the method you're describing is something as follows. You take a block cipher $E:\mathsf{K}\times \mathsf{X} \to ... 2 If you want to attack the block cipher, then there are no generic attacks which use the block size. However, if you want to use a block cipher for messages which are longer than 32 bits, then you will have to use it in a mode of operation, like GCM, or OMAC (more popular modes are CBC and CTR, but they should not be used for communication on their own since ... 3 The block size does not directly determine the security of a block cipher. Even with a 32 bit block cipher the number of possible permutations is 2^32!, a stupendously big number. Small block sizes are however cumbersome to use in secure modes of operation as the input is limited. For instance, it would be easy to have repeating counters in counter mode ... 5 The simple answer is that fewer than 3 rounds can be easily distinguished from a random permutation. The 2-round Luby-Rackoff cipher on$2n$bits, using random functions$f_i$mapping$n$bits to$n$bits, consists of $$F(L, R) = (A, B),$$ where$A = L \oplus f_1(R)$and$B = R \oplus f_2(L \oplus f_1(R))$. Now consider an attacker that wants to ... 3 It's required for diffusion and achieving the avalanche effect. The concept of diffusion and the avalanche effect basically means that each input bit should influence each output bit evenly. Changing one input bit should flip, on average, half the output bits. Due to the nature of the Feistel construction, how it is split up into halves, only one side ... 3 I'm not sure about your definition, so let's take branch number in terms of the byte-wise differential branch number, i.e. the branch number of a function$F(x)$is $$\mathcal{B}_{F(x)} = \min_{a,b \neq a}\{ w(a \oplus b) + w(F(a) \oplus F(b))\}$$ where$w(x)$is the number of non-zero bytes in$x\$. In this case, the branch number of the Twofish round ...

1

After trying all the possible inputs with Hamming Weight of 8 and below from the space of 2^64, it seems that MDS + PHT combined achieves branch number not less than 8. Since there was no output which had Hamming Weight of 0 in case of Input Hamming Weight from 1-7, MDS + PHT combined will never attain Branch Number less than 8.

1

If you encrypt (partially) random values then the likelyhood that you encrypt the same value is larger for block ciphers that operate of fewer bits. If you encrypt the same value with the block cipher (which is a PRP) it will result in the same ciphertext. Identical ciphertext can be used by an attacker to retrieve information about the plaintext, breaking ...

4

There is actually a field of study regarding provably secure block ciphers. The seminal paper was "How to construct pseudorandom permutations from pseudorandom functions" (1988) by Luby and Rackoff. Their paper used pseudorandom round functions in a Feistel construction, and proved that 4 rounds were sufficient to make the resulting block cipher a ...

1

I remember that BEAR and LION are two block ciphers are provably secure under the assumption that the primitives used (hash and stream cipher) are secure. This is the most "provable secure like" approach I can remember. A part of that, I think the securite of block ciphers are anaylized as the paper you have cited do. Checking the security against the ...

4

In symmetric cryptography it is hard to prove security properties on algorithm. Most of block ciphers relies on showing resistances to the current attacks (cf the paper you linked or any paper that introduce a new block cipher). As nobody can know what will be the next attack vector, it is not possible to be prepared against it. From The design of Rijndael ...

1

The speed of a cipher actually depends on lots of factors, including: The specific hardware platform you're considering (CPU architecture, instruction set, number of cores etc). Implementation details. Compiler flags used. Some ciphers have a large initial overhead due e.g. to a slow key setup; as a result they are slow when encoding very small messages. ...

Top 50 recent answers are included