# Tag Info

6

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

7

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

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

0

As SEJPM mentions, what you are doing is called "format preserving encryption" and there is a lot of information out there on that, in case you want to go deeper than the answers here give you. The problem of creating a custom sized cipher is a difficult one, especially if you want to be sure it's crypto secure, but one nice way to approach the problem is ...

0

not possible if it's CBC hidden. Try using pairs and put them in dictionarys. Bruteforce is also a way but not answering the question properly.

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

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

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

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 ... 3 In general you want to treat primitives like block ciphers as black boxes. You first analyze and try to break the block cipher. Once it is proven to operate correctly you can use it as primitive for a block cipher mode of operation. The mode of operation can then be proven to be secure assuming that the block cipher primitive operates well. If you don't ... 0 I think the attack models establish constraints on the cipher parameters that allow you to confirm guesses in a brute force or probabilistic search. A simple way to look at it is that they let your write equations involving the cipher parameters. For example, in$c = enc(p,k)$, you can fix two of the parameters and solve for the third. Clearly$c\$ ...

2

I doubt something like this exists, because it would be more or less equivalent to having some internal block cipher in a non-standard mode of operation. Also, changing keys is to be avoided when designing high-performance primitives, because it's pretty slow in most modern ciphers. You'd need a weird cipher that had really high key agility, but then you'd ...

Top 50 recent answers are included