Turns out that that text is incorrect and it's 64-bit and 128-bit block sizes. The text on the cheat sheet page has been partially corrected to now say 128-bit block size, but still says 64-bit key size.

The current version of that page reads as:

> This would typically be 2^35 bytes (~34GB) for 64-bit keys and 2^68 bytes (~295 exabytes) for 128-bit block size.

So it's sloppy writing that's the issue, not that people are still using 64-bit keys. (I had a similar question reading the quote above and followed the link where this was pointed out.)

I’m not a crypto geek! But, I thought the block size had to be smaller than the key size?

There's no rule that you need to mix a raw key bit with every data bit. Block ciphers usually expand their key into a bunch of subkeys to use in different rounds, and you can stretch that expansion as far as you desire.

And if you squint, a stream cipher is just a block cipher with a stupidly large block.

> Why are we allowing anyone to use 64 bit keys in 2024? Why is it even part of the WPA3 spec?

"We" are not, and it is not. That is just a general example of the concept of needing key rotation.

Maximum integer size on a CPU or in a language has nothing to do with key sizes for serious (non-toy) cryptographic systems. Use multiple integers, likely in an array, if needed, as has been done for a very long time.

Yes, it's not usual for the rest of the software to think about these as integers at all, they're just a bunch of bits, like a JPEG so yes, the 128-bit key would be e.g. Rust's [u8; 16] exactly 16 contiguous bytes.

The encryption algorithms themselves, if they're even written in a high level language rather than supplied as machine code, perhaps using hardware acceleration, may treat this some other way, but that's completely irrelevant to you in the rest of the code. Maybe it sees this as [u16; 8] or as [[u32; 2]; 2] for some reason, you don't care.