2
$\begingroup$

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?

$\endgroup$
  • 10
    $\begingroup$ AES behaves the same way on all platforms. If it differs, it's a flaw in your code. $\endgroup$ – CodesInChaos Nov 2 '17 at 10:03
  • $\begingroup$ Implementations may be different on different platforms, for example through the AES-NI, but the algorithm itself is always the same. $\endgroup$ – dsprenkels Nov 2 '17 at 10:23
  • $\begingroup$ I had a code which encrypted using aes on windows and when i decypted on Linux the resultant got garbled . When i search i get links which suggest that people have written there own corss platform libraries like github.com/keel/aes-cross . These make me think that maybe its not cross platform . $\endgroup$ – MAG Nov 2 '17 at 10:26
  • 1
    $\begingroup$ @MAG AES is only a small building block. To produce something usable in practice you need to make quite a few choices (e.g. the mode of operation), which have to be the same for interoperability. It's helpful to have an interoperable high-level library for many languages. $\endgroup$ – CodesInChaos Nov 2 '17 at 10:29
5
$\begingroup$

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.

$\endgroup$
  • $\begingroup$ This answer is most likely to solve op's real problem, even if it does not directly answer the question $\endgroup$ – Richie Frame Nov 4 '17 at 1:14
5
$\begingroup$

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.

$\endgroup$
3
$\begingroup$

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.

$\endgroup$
  • $\begingroup$ Would C++ code compile if you tried to reference AES-NI on a processor that didn't actually have that native feature? The OP's code compiles. $\endgroup$ – Paul Uszak Nov 2 '17 at 22:07
  • 1
    $\begingroup$ @PaulUszak: Yes the code could compile (e.g. for x86-64 on a x86-64 CPU that does not have AES-NI) ; but (under most OSes/Virtualization managers) it would fail to run. $\endgroup$ – fgrieu Nov 2 '17 at 23:43
  • 1
    $\begingroup$ You might want to emphasize that AES is not platform-dependent but certain AES implementations are. In a literal sense, the questioner asked whether ‘AES encryption/decryption is platform-dependent’. Whether they meant the mathematical function or a particular implementation is not clear. $\endgroup$ – Squeamish Ossifrage Nov 3 '17 at 17:50

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.