# Tag Info

18

I'm just curious to know why the 128-bit version become the standard[.] That question is easy to respond. In the section Minimum Acceptability Requirements of Request for Candidate Algorithm Nominations for the AES, it says: The candidate algorithm shall be capable of supporting key-block combinations with sizes of 128-128, 192-128, and 256-128 bits. A ...

15

No, this isn't an oversight. AES is a block cipher, which is a keyed permutation. Now if you have a permutation of, say, three elements there are e few permutations possible: a -> a b -> b c -> c but also: a -> b b -> c c -> a and a -> c b -> a c -> b and a -> c b -> b c -> a (there should be $6$ for $3!$, the ...

14

In complete honesty: if you have to ask this question, it's overwhelmingly unlikely that you have actually succeeded in breaking the security of AES. At best, you may have discovered a well-known attack against misuse of particular block cipher modes; for instance, plaintext recovery with a chosen-ciphertext attack against ECB, or blind manipulation of the ...

13

Assuming you really had broken AES or another frequently used algorithm that is thought to be secure, the first step would be to prove it. Write the code for the attack. Verify that it works on randomly generated data of the kind it requires. If it can break some challenge (e.g. these), do it. Post the results to the challenger or show the results publicly....

12

Rijndael (the algorithm behind AES) is specified with block sizes and key sizes of 128, 160, 192, 224 and 256, in any combination of block and key size. (Thus, Wikipedia was wrong with the keysize has no theoretical maximum here, though one could invent extensions of the key schedule algorithm which allow longer keys. See below for details. I now fixed this ...

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

8

I can immediately think of four reasons: They're both not using AES256. I see in the Obj-C document a direct statement that they are using AES256 (unless you deliberately change it), I don't see any statement in the Visual Basic document that says what key size they're using (unless that's what they mean by "Block Bits"). Different keys. AES256 takes a ...

8

Prompted by Paŭlo's comment, I took a look at the original requirements set out for the AES candidates. A useful page for that turns out to be AES - The Early Years (1997-98) on the NIST web site (and surprisingly hard to find there; the internal links are broken and Google doesn't find it either). The AES key lengths were specified in the original Request ...

8

The use of the AES key many times is not a problem. However, there is a fundamental flaw with your solution. The server has no way of validating that it received the client's authentic public key. In particular, a man-in-the-middle can capture the client's public key, can forward its own public key to the server, and can then decrypt all traffic sent by each ...

7

The key schedule uses constants that differ between the key sizes. For arbitrary sized keys you would have to define an algorithm for deriving them. Each key size also uses a different number of rounds, for which you would have to do the same. Also, what's the point? 256-bit keys are enough for all eternity. Using a longer keylength variant would likely ...

7

The S-Box was generated when Rijndael was designed, not in any step. It's used in every round in the SubBytes step. The S-box is constant. You could see it as a function taking a byte and returning a byte. It is used to reduce algebraic properties of Rijndael. In fact, this is it: | 0 1 2 3 4 5 6 7 8 9 a b c d e f ---|--|--|--|--|--|--|--...

7

This begs the question, why would you in any real-world circumstance wish to reduce the difficulty for an attacker to break your cryptosystem? To answer your question practically, the only reasonable way I can think of to accomplish this is to simply reduce the entropy in the key. At 100%, all 128 bits of the key are used. At 50%, 64 bits of the key are ...

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

6

That variation directly implements Rinjdael's ShiftRow as specified (section 4.2.2) in the proposal to NIST, defining Shitftrows for 128, 192 and 256-bit block size (Nb=4, 6 and 8). Loosely speaking, the offsets improve the mixing (diffusion) properties of consecutive rounds of the cipher. More precisely the authors state their motivation (section 7.4) ...

6

AES-128 takes a 128-bit key, produces 11 128-bit subkeys out of it with a cryptographically weak function, and uses them in 10 internal rounds. It can be said that the full key is reused 10 times. AES-192 takes a 192-bit key, produces 13 128-bit subkeys out of it (or, equivalently, 9 192-bit subkeys), and uses them in 12 rounds. The full key is reused 8 ...

6

First, it's not said that AES is unbreakable, merely that none of the currently known attacks reduce the computational cost to a point where it's feasible. The current best attack on AES-128 takes 2^126.1 operations, if we had a computer (or cluster) several million times more efficient than any current computer and could operate at the thermodynamic ...

6

There is no NIST oversight here. The key size and the block size are two completely different parameters and issues. The only reason that you need a large block size is because bad things start to happen when you encrypt too many blocks. Specifically, for an $n$-bit block size, the birthday paradox kicks in at $\sqrt{2^n}$. So, for a 128-bit block, you need ...

5

Assuming for the moment that your claim is correct, I would suggest caution in revealing the details of your findings. After having your results validated by one or two people with the skills to do so (and whom you trust to keep things confidential), then some sort of general announcement (without specifics) would be best, to give people time (say three ...

5

It has to do with the alignment between the size of cipher the key and the size of a round key. Since a 256-bit key is twice the size of a round key, the nonlinearity of the key schedule would be aligned to every other block, and that is bad. Here is an example of the round keys generated by the key schedule for a key (hex bytes) of value ...

5

The most likely rationale to change the AES design is political. It's a NIST standard, designed in Western Europe. It's a bad idea! How much scrutiny has it received? Almost none. How much will it receive? Almost none. Bad idea.

5

I ("SEJPM" as of now) have contacted the authors asked them the same questions as in my question. I'm posting this as community wiki, as it's not my answer to this question but rather theirs. Now the responses follow: First off, the authors are working on a design rationale in english for their new cipher. As soon as it's published, it will be linked here....

4

During the final round of the AES contest, NIST issued a summary of the 5 finalists on the topics of security, speed, implementation, and such. That sounds like what you're looking for, see sections 3 and 5 of the paper. General ideas from the paper: Rijndael had a potentially lower security margin than Twofish and Serpent. Rijndael had better performance ...

4

Rcon(9) is 0x1b because 0x80 multiplied by 0x02 is 0x100, which is reduced to 0x00 xor 0x1b in the finite field. Rcon(10) is twice Rcon(9), and so forth. Rcon(0) is 0x8d because 0x8d multiplied by 0x02 is 0x01 in the finite field. If what I mean by finite field is not understood, it is because the numbers you are dealing with are actually polynomials, see:...

4

You may be overthinking this a bit. Just pick any byte in the ciphertext, and for each possible value of the last RoundKey in that byte, do the following: decrypt just that single byte of the 256 ciphertexts (i.e. compute $AR-SR^{-1}-BS^{-1}$ for that single selected byte using the candidate RoundKey byte in the $AR$ step), and then check to see if the ...

4

Quoting from FIPS 197 (PDF), on page 11: Rcon[] The round constant word array. So, the answer is obviously "round constant".

3

They are referring to the formula for Bézout's identity which calculates the greatest common divisor, extended to a finite field, where 1 is the multiplicative neutral element. From the relation $b(x)a(x)+m(x)c(x)=1$, $$b^{-1}(x)=a(x)\mod m(x)$$ I cant figure out what $a(x)$ and $c(x)$ are? In this case, $b(x)$ is the element for which the inverse is ...

3

I'm not seeing any particularity between the two field that they build, but exists? First off, one basic truth about finite fields is that there is at most one finite field of a given size. Given that both $x^7 + x + 1$ and $x^7 + x^4 + x^3 + x^2 + 1$ are both irreducible, they both generate the same finite field. Where they differ is the representation; ...

3

I am using chunks of 1MB and give them a GUID as filename That is fine although unnecessary, the entire input file can be encrypted. These chunks are then first compresses using DEFLATE to minimize attacks based on known Content VERY BAD idea, since you are breaking the input file into pieces, you are now exposing the entropy of specific file ...

3

According to the original NESSIE submission of Whirlpool: "The ﬁnite ﬁeld ${\rm GF}(2^8)$ will be represented as ${\rm GF}(2)[x]/p(x)$, where $p(x) =$ $x^8 +$ $x^4 +$ $x^3 +$ $x^2 +$ $1$ is the ﬁrst primitive polynomial of degree $8$ listed in [19]. The polynomial $p(x)$ was chosen so that $g(x) = x$ is a generator of ${\rm GF}(2^8) \setminus \{0\}$." ...

3

As fgrieu already pointed out, using a OWF in the way you describe would make the key schedule not efficiently invertible (or even not invertible at all), meaning you would need more memory/chip space to store the user-input key in order to efficiently encrypt more than one block. In terms of other implications, if the key-state update function $e_n(\cdot)$ ...

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