Talk:Rijndael MixColumns

	Mathematics portal This article is within the scope of WikiProject Mathematics, a collaborative effort to improve the coverage of mathematics on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.MathematicsWikipedia:WikiProject MathematicsTemplate:WikiProject Mathematicsmathematics articles
Low	This article has been rated as Low-priority on the project's priority scale.

Cryptography: Computer science Low‑importance

	This article is within the scope of WikiProject Cryptography, a collaborative effort to improve the coverage of Cryptography on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.CryptographyWikipedia:WikiProject CryptographyTemplate:WikiProject CryptographyCryptography articles
Low	This article has been rated as Low-importance on the importance scale.
	This article is supported by WikiProject Computer science (assessed as Low-importance).

Rijndael's Galois field - modulus in implementation example[edit]

AFAIK, the b[c] should be XORed with 0x11b, instead of 0x1b. I'am aware that the AES-Specification is contradictory regarding the correct value: "If b7 = 1, the reduction is accomplished by subtracting (i.e., XORing) the polynomial m(x). It follows that multiplication by x (i.e., {00000010} or {02}) can be implemented at the byte level as a left shift and a subsequent conditional bitwise XOR with {1b}." (page 11). Above, m(x) is defined as x^8+x^4+x^3+x+1, that's equivalent to the binary value (100011011)_2, which is 0x11b. So the first sentence in the quoted passage says to XOR with 0x11b, the second sentence is obviously due to a typo.

The data type is 8-bit, so the high bit is implicitly masked off by the shift, and thus xor by 0x1b is correct. If a 16/32/64-bit data type is used instead, xor by 0x11b is correct. 93.34.50.73 (talk) 11:39, 6 March 2012 (UTC)[reply]

regarding implementation example[edit]

can someone explain why h is anded by 0x80, rather than just checked if it's zero?

	for(c=0;c<4;c++) {
		a[c] = r[c];
------------->h = r[c] & 0x80; /* hi bit */
		b[c] = r[c] << 1;
------------->if(h == 0x80) 
			b[c] ^= 0x11b; /* Rijndael's Galois field */
	}

the only way r[c] could ever be anded with 0x80 and still be equal to 0x80 later is if r[c] is zero. Why not do this instead:

	for(c=0;c<4;c++) {
		a[c] = r[c];
		b[c] = r[c] << 1;
------------->if(r[c] == 0x0) 
			b[c] ^= 0x1b; /* Rijndael's Galois field */
	}

h does not appear to be used else where. Is this a mistake, am I missing something Ethyr (talk) 03:41, 27 February 2009 (UTC)[reply]

"the only way r[c] could ever be anded with 0x80 and still be equal to 0x80 later is if r[c] is zero" is simply not true. For example, 0x80 & 0x80 == 0x80. In fact, if r[c] were zero then r[c] & 0x80 would equal zero. —Preceding unsigned comment added by 98.206.101.209 (talk) 03:08, 15 June 2009 (UTC)[reply]

Test Vectors[edit]

Running the vectors through Octave, for the first two vectors I get the following output:

Before: 219 19 83 69 After: 136 77 161 186 (not 142 77 161 188);

Before: 242 10 34 92 After: 153 220 88 155 (not 159 220 88 157)

Can anyone verify whether my results are correct, or show that the vectors listed are correct? The rest of the vectors match the output from Octave. — Preceding unsigned comment added by 99.8.142.82 (talk) 18:33, 27 July 2011 (UTC)[reply]

FWIW, I implemented this in python, and both test vectors check out. Zeebrommer (talk) 08:16, 14 November 2014 (UTC)[reply]

Intro error[edit]

In the intro the following is stated:

The MixColumns operation performed by the Rijndael cipher, along with the shift-rows step, is the primary source of diffusion in Rijndael. Each column is treated as a polynomial over GF(2⁸) and is then multiplied modulo $x^{4}+1$ with a fixed polynomial $c(x)=3x^{3}+x^{2}+x+2$ ; the inverse of this polynomial is $c^{-1}(x)=11x^{3}+13x^{2}+9x+14$ .

Shouldn't the reduction polynomial be $x^{4}+x^{3}+x+1$ instead of $x^{4}+1$ ? — Preceding unsigned comment added by 86.86.12.173 (talk) 12:32, 1 July 2016 (UTC)[reply]

Anon edit tweaking constants[edit]

This edit tweaks constants in two places, and looks incorrect to me. Of course, no-one should be copying crpyto code from a wiki in the first place, but this raises the interesting question of whether someone might be testing out corrupting crypto examples on Wikipedia in the hope that something might stick? — The Anome (talk) 21:14, 13 March 2022 (UTC)[reply]

I expect that was an honest mistake, or just ordinary vandalism. Any real-world (software-based) implementation is going to combine this step and the Rijndael S-box into four 8x32 lookup tables (example), or use some fancy timing-attack-resistant techniques that aren't even described here. That said, I haven't checked the tables in this article. I tried to remove the tables a while back, but people like them.

Also, that tweak would have caused every test vector to fail. If you're trying something underhanded, you want it to work correctly most of of the time. Suffusion of Yellow (talk) 21:41, 13 March 2022 (UTC)[reply]