Why is AES encryption decryption not platform agnostic?

Question

We work on C++ code which compiles on Windows and Linux. I have been told that AES encryption/decryption is platform dependent. Is it true? If so, why is it OS dependent?

Answer 1

Potential issues are the inputs and outputs of the two implementations.

There is a mode, generally CBC which requires a random IV the size of the block, it must be shared between the encryption and decryption implementations.

There is the encoding of the data, key and IV: binary, hex, Base64, etc.

There is padding, generally PKCS#7 (sometimes called PKCS#5).

The key size must be 16, 24 or 32 bytes.

If the sizes of the IV and key are not correct the implementation may return an error or just extend in some unique way.

Finally implementation documentation is generally incomplete.

But the AES algorithm is platform/language agnostic and works accross platforms.

Answer 2

No, it isn't.

As a C++ programmer you'll realise that the source code can be environment dependant - such as the 32 /64 bit thing. Or memory capacity. But you should also realise that an algorithm is OS agnostic. Isn't this actually intuitive? One way to look at it are all the IOT devices out there. They often use AES for encryption and they manage to talk to each other and control your hot water from your phone. Those devices are all different, and some might be 8 or 16 bit affairs. And some might even run on batteries like your phone.

See the Advanced Encryption Standard Algorithm Validation System for test vectors. This document shows you what should come out of your AES code. You've just messed up either your native code implementation or the library API. If you can't understand section 6, Modes of Operation then you need to do some additional fundamental research regarding block ciphers. Remember that AES itself is only the block primitive that accepts a key and a (plain/cipher/IV)text input. Nothing else.

To reinforce what I've said, look at the referenced document, appendices B to E. There is absolutely no mention of operating system, programming language, hardware type or battery voltage. AES is totally abstracted from it's environment. If you have a problem with compatibility, it's an implementation issue.

Answer 3

Yes, cryptographic code (doing/using e.g. AES) tends to be platform-dependent, for a number of reasons:

• Often, it includes conversion from octets to some larger type and back, and this can be endianness-dependent (if it is not, there's a risk of inefficiency there, from negligible if outside the round loop, to sizable if within)
• Same conversion might be possible with the best efficiency, or not, depending on alignment considerations, that might impact the calling code on some platforms.
• Very often nowadays, it relies on hardware feature like AES-NI, both for efficiency and avoiding data-dependent timing dependencies (which can lead to timing attack). This is heavily CPU and compiler-dependent. For example, according to Intel, their Atom Z3530 has AES instructions, when their later and faster Pentium A1020 does not.
• When no hardware does the job, software must do it and should find ways to avoid timing attack and other side-channel attack, typically cache-related. Messing with the cache is very dependent on CPU, OS and compiler.
• Both for efficiency and resistance to side-channel attacks, it might be necessary to align buffers on some page boundary, and this is platform-dependent.
• More often than not, in order to solve the above problems, the application uses an OS-supplied cryptographic service, which interface becomes OS-dependent.

Note: AES itself is platform-agnostic; only its implementation and use is platform-dependent.