Hot answers tagged

9

The fastest block cipher is identity, which leaves input blocks completely unchanged. This is infinitely fast on all platforms; however, it is not secure. So maybe you want the fastest block cipher that still offers some given non-trivial level of security? Then it depends a lot on what you want to implement the block cipher on. With recent PC, you would ...


7

Is Rijndael the fastest block cipher in the world? No. On an Intel 64 Sandy Bridge without AES-NI, AES (a subset of Rijndael) is outperfomed by ChaCha20 (and also likely by Threefish 512 which has about 6-7cpb cost on an older Intel Core 2 Duo with 64-bit ASM (link: original Skein paper PDF)) as opposed to AES' 11 cpb. (7.59 cpb on an Intel Core 2) ...


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


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


2

GOST symmetric cipher uses 256-bit keys to encrypt 64-bit blocks. That means there are many keys which give the same result This is actually incorrect. A block cipher, when given a key, maps $n$-bit plaintext blocks to $n$-bit ciphertext blocks (and vice versa for decryption). Here's a toy example for $n=2$: $E_k(00) = 01 \\ E_k(01) = 10 \\ E_k(10) ...


2

This is because the set of possible permutations of 64 bit blocks of plaintext ($2^{64}$ possibilities) to 64 blocks of ciphertext is very high. A key selections just one of these permutations. Even a 256 bit key space is smaller by far than the number of possible permutations. Some plaintext blocks will likely map to the same ciphertext block for a few of ...


2

If you are going to generate ALL the numbers in the output domain, an attacker's job of guessing the next number becomes easier the more numbers you use, once you pass the halfway point. I would suggest with whatever method you choose, to never exceed $N/2$ values used, where $N$ is the total number of elements that can be generated using that method, ...


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


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


1

Assuming that there are no collisions and there exists a 1 to 1 bijection between input and output, you could construct and store a table of assignments on a single round of encryption for all 256 possible bytes regardless of the key size. From there you can extend this to subsequent rounds by simply XORing the result of the previous round to the next 8 bit ...


1

Check out Swap or Not (pdf). Unlike some Feistel-network based solutions, this will provide you with near-ideal security (the adversary would have to query close to the entire space to have non-negligible advantage). Alternatively, enumerating and shuffling a list of 2^16 16-bit numbers would require only ~128KB of RAM. If you needed to reproduce the ...


1

Do I really need a random IV if I salt the data? Prepending 128-bits of random salt to the data is the same as using a 128-bit random IV, right? Yes, it should do the job, but if I'm reading your question correctly you don't really have to optimize storage away, but if you want to, I'd rather recommend going with AES-128 and a 128-bit IV which is ...


1

Here is how I would approach this: First off, strip off the unkeyed parts of the cipher at the beginning and the end. That is, process the plaintexts with the 'rotr 8/add/rotl 3' at the beginning, and process the ciphertexts with the 'xor/rotr 3' at the end (rotr because we're working the inverse direction). Next, we focus in on only the right side ...



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