Separate AES from Rijndael; Support Rijndael 192-bit and 256-bit block sizes

[mouse07410]

For the purpose of supporting Rijndael features not included in AES, specifically 192- and 256-bit block sizes.

In case it matters, AESNI instruction set allows hardware-optimized RIjndael implementation, not only AES.

[DevJPM]

The reason why it was not done in the past is (I believe) the fact that the library has no support (yet?) for blocktransformations with dynamic size. So the main interface class and the helper classes all focus on a static, fixed block size.

Thus a change here wouldn't be impossible, but would take some time to be done.

[mouse07410]

... the library has no support (yet?) for blocktransformations with dynamic size ...

Yes, this needs addressing. As I expect ciphers to come that have this property (block size varies, like the key size).

Thus a change here wouldn't be impossible,

Good!

but would take some time to be done

Understood.

[noloader]

With the advent of Issue 302: AES and incorrect argument to _freea() under Microsoft compilers, we have got to clean that Rijndael code up...

The cleanup will allow us to logically segregate all the things going on so we can make changes like Padlock implementation, ARMv8 implementation and additional block sizes. Right now its practically impossible to maintain.

For completeness, here are the intertwined implementations I am aware of:

• Straight C++ implementation
• SSE2 implementation
• AES-NI implementation
• Aligned data-access
• Unaligned data access
• Compressed tables
• GCC ASM
• Microsoft MASM

[noloader]

@johnwbyrd, Take a look at this report. There's a fair amount of intersection with your observation in the 302 Issue. If you have any design suggestions, then we would be delighted to hear them.

[johnwbyrd]

I do have opinions on this, but they might be too complex to list as an addendum to a bug report.

To summarize, I think the only long-term maintainable approach to implementing a cross-platform AES that addresses all these issues, involves implementing AES as a cross-platform template library, for which specializations exist for each target and for each instruction set. I believe that per-platform assembly code should be minimized to a few particular and obvious cases, and instead vectorization speedup should be performed by representing transformations mostly in a way in which the new auto-vectorization features of clang and MSVC can detect.

More details later...

[johnwbyrd]

Whatever solution is chosen must take into account the ever-exploding number of instruction sets and speedups thereof: http://www.intel.com/content/dam/www/public/us/en/documents/white-papers/communications-ia-multi-buffer-paper.pdf

[EAirPeter]

It is 2018 now, so where is the support for 192-bit and 256-bit block sizes? Sorry for commenting on this issue after 2 years :(

[bgarisn]

I'd like to know what the plan for these block sizes is as well? Any updates?

[fionafibration]

Don't GCC and MSVC now give access to a lot of the SSE2 instructions as __builtin functions? As well as things like counting leading zeroes in a data type?

[noloader]

@ThePlasmaRailgun,

We can gain access to the SIMD unit using intrinsics, like:

__m128i x = _mm_setzero_si128();
x = _mm_add_si128(x, y);

But we don't have a way to convert the ASM directly. That is, we can't convert something like this because the intrinsics do not map to the integer unit.

push ebp
mov ebp, esp
mov eax, 0