# Tag Info

5

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

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

3

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

2

Your assumption is flawed, you are thinking the IV used for encryption and decryption are different, and that the decrypt IV is an output from the cipher. It is only an input, and it is the same for both operations. Therefore it does not leak any information about the key or the plaintext. Is using the IV in such a way, which can keep both sides of a ...

2

I assume you mean that the CBC-mode encryption and decryption process would 'update' the "output IV" will be identical to the most recent ciphertext block. This isn't obvious from your question; for example, the diagrams you show don't show any "output IV" being generated at all. Now, for your specific questions: Does this "Output IV" holds information ...

2

To give some general intuition: Longer keys give the attacker more "degrees of freedom" in a related-key attack. Therefore, defending against related-key attacks likely requires more complex key schedule if the key is long, than if the key is short. That might explain, at a conceptual level, why 256-bit keys require more complexity in the key schedule. ...

2

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

1

I guess that a single e-mail to Vincent Rijmen might solve this problem, but I would speculate that the new S-box should have been more hardware-friendly compared to that of Rijndael. The recursive structure of $W$ and smaller constants in the MDS matrix may have required another field representation.

1

"Serial concatenation" is not a standard term in cryptography. Without any further information, I would guess that it probably refers to just concatenation. If that's not what it refers to, then your spec is deficient and ambiguous; you'll need to consult with the author of the spec to ask for to clarify what they meant by that phrase.

1

I'm assuming there are holes in your question, but I'll answer it as is and then you'll probably want to change the question. Although please also see this question as it might answer your question too. The probability of decrypting an AES encrypted ciphertext is $1$ if you have the right key and (practically) $0$ if you have the wrong key. This is ...

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