Does iPhone Support Hardware-Accelerated Aes Encryption

iOS hardware-based encryption

It's not an automatic process. You as a developer have to make sure to enable protection for all files you save. You also have to make sure that your app will not try to access protected files while the device is locked. See Working with Protected Files in the iOS Programming Guide for details.

Also note that data protection is only available on iPads that have gotten a fresh install of iOS 4.2. Devices that have been upgraded from iOS 3.2 need to be restored for data protection to work (source).

AES encryption using MonoTouch

MonoTouch provides AES support inside it's class library, e.g. the RijndaelManaged class.

However you need to know a bit more about how it was encrypted (cipher mode, padding mode, key size) to be able to decrypt a file. Also depending on the file size you might want to decrypt it in memory (safer) if it's small or to a temporary file (if large).

Notes:

Rijndael is the original name of the algorithm that got selected to be AES;
AES is a subset of Rijndael (only one block size, 128 bits) so you can do everything AES supports using RijndaelManaged;
At the moment MonoTouch does not use CommonCrypto (it uses the managed implementation from Mono) so you won't get hardware acceleration. This will likely change in future releases (and will be compatible, i.e. simply re-compile, for people who used RijndaelManaged in their applications).

EDIT

MonoTouch 5.3.3 (alpha) now default to use CommonCrypto implementations, including hardware acceleration (when available) for AES and SHA1.

Is .NET AesManaged cryptography hardware accelerated?

Clearly the .NET AesManaged implementation is not hardware accelerated. Searches of SO and Google indicate that AesCryptoServiceProvider (which is a wrapper over the OS crypto) is generally much slower than the AesManaged implementation.

However, I have found that the AesCryptoServiceProvider was actually faster, way faster, as in order of magnitude difference. I'm suspecting that the OS level implementation is actually handing AES-NI instructions off to the CPU for hardware acceleration.

I cannot locate any documentation on the above observation, but if my suspicions are correct then at least on a Core i7 4770 CPU running 64-Bit Windows 8.1 Update 1, the AesCryptoServiceProvider is hardware accelerated.

Performance observations are that on the above machine, 8 threads of AES CBC decryption using AesManaged will max out the CPU and consume as much memory as needed for the data (i.e. for us 32GB of RAM gets maxed out regularly). The exact same code but using AesCryptoServiceProvider has the CPU cores average around 30-40% and memory (private working bytes) seldom go over 10GB.

To semi-answer my own question, try AesCryptoServiceProvider, especially on 64-bit Windows 8.1 Update 1.

Hardware AES support for .NET

I can't find much information but this answer to this question implies that AesCryptoServiceProvider will make uses of AES-NI when available.

Are BouncyCastle's AES engines hardware accelerated?

According to Bouncy Castle it is not supported and will not be supported:
https://github.com/bcgit/bc-java/issues/221