Google Details Their New Adiantum Encryption For Low-End Android Devices

[elatllat]

On the N2 adiantum is an order of magnitude slower than xts (84 vs 427 MiB/s).
But It would likely help a rpi4

https://forum.odroid.com/viewtopic.php?f=149&t=30103

[willmore]

[*]Adiantum is still 5x faster than AES-256-XTS, and would even still be around 3-4x faster than AES-128-XTS. (Adiantum uses a 256-bit key, so it's more comparable to AES-256-XTS.)[/LIST]AES is simply too slow to be viable for universal, default-on storage encryption on low-end Android devices without the ARMv8 crypto extensions, regardless of the mode of operation chosen. If there was a trivial solution, we would have done it :-)

Adiantum is faster than AES on chips which lack AES crypto support, but it's slower by a good factor on chips which do support it. But other than that one point, I agree.

[Mangix]

It's slower at decoding but not so much when encoding.

[ebiggers]

Hm looks like Google was using AES CBC for full disk encryption...... isn't that significantly slower than AES XTS?

No wonder that ARMv7 Android devices have been struggling and having poor performance since encryption was introduced.

Not really. XTS encryption is parallelizable across AES blocks whereas CBC encryption is not, which can make XTS encryption somewhat faster. However:

• Decryption is actually more performance-critical than encryption. CBC decryption is actually a bit faster than XTS decryption.
• Android is already moving to "file-based encryption" which normally uses XTS (for file contents). Only devices still on "full-disk encryption" use CBC.
• Adiantum is still 5x faster than AES-256-XTS, and would even still be around 3-4x faster than AES-128-XTS. (Adiantum uses a 256-bit key, so it's more comparable to AES-256-XTS.)

AES is simply too slow to be viable for universal, default-on storage encryption on low-end Android devices without the ARMv8 crypto extensions, regardless of the mode of operation chosen. If there was a trivial solution, we would have done it :-)

Hm looks like Google was using AES CBC for full disk encryption...... isn't that significantly slower than AES XTS?

No wonder that ARMv7 Android devices have been struggling and having poor performance since encryption was introduced.

[Mangix]

Would this help much with ancient computers and such as well? For example Core 2 Extreme QX9300, still has okay performance as a laptop CPU, but it lacks encryption extensions found in new Intel CPUs.

On an un-related note, I wonder if it would be possible to create a kernel module that would could software emulate newer instruction sets for older CPU's, which would allow new games and such to run, albeit very slowly, on ancient computers(SSE 4.2, not found on Penryn CPU, but it is on Ivy Bridge, if it could be emulated on Penryn, then modern games could run...)

Yes it would. To give an example, on mt7621, an rsync transfer goes at 5MB/s purely because of AES. Switching to chacha20 gives an extra 1-2MB/s. There's a driver currently in development to use hardware acceleration from the SoC. ~39MB/s according to cryptsetup benchmark.

[starshipeleven]

Would this help much with ancient computers and such as well? For example Core 2 Extreme QX9300, still has okay performance as a laptop CPU, but it lacks encryption extensions found in new Intel CPUs.

Yes. I wouldn't say it has ok performance for a laptop, but whatever floats your boat.

On an un-related note, I wonder if it would be possible to create a kernel module that would could software emulate newer instruction sets for older CPU's, which would allow new games and such to run, albeit very slowly, on ancient computers(SSE 4.2, not found on Penryn CPU, but it is on Ivy Bridge, if it could be emulated on Penryn, then modern games could run...)

Just see how resource-intensive are emulators that actually fake a CPU arch like console emulators. (i.e. you need an i5 to emulate some prehistoric piece of garbage processor like the GameCube https://dolphin-emu.org/docs/faq/ )

No way that you could emulate a modern CPU instruction set on an old crap CPU fast enough to run anything actually relying on the modern instruction set, where is your logic even. "yeah let's make something exponentially harder so we can run it on old weak hardware, that's going to be great".

[starshipeleven]

Since I always read that people think Speck has been backdoored by the NSA, isn't it possible to check the source code since it's open source? I can immagine it's not that easy to decipher cryptographic code, but since it's in the kernel and a lot of parties are involved, it shouldn't be impossible?

The issue isn't in the code but in the math. https://www.theregister.co.uk/2017/1...cal_backdoors/

Actually finding backdoors in math, aka the algorithm itself is an entirely different type of fish than finding backdoors in code.

[F.Ultra]

Since I always read that people think Speck has been backdoored by the NSA, isn't it possible to check the source code since it's open source? I can immagine it's not that easy to decipher cryptographic code, but since it's in the kernel and a lot of parties are involved, it shouldn't be impossible?

Deciphering cryptography code is inherently complex. Granted that we have more cryptographers today than we had back in the 70s and 80s but as an example we can take DES that the NSA changed slightly in 1976 without a word on why (and DES was open source). It was not until the late 1980s when differential cryptanalysis was discovered that people understood why the NSA changed DES the way they did (their change made DES resistant to this very attack).

[willmore]

Why is the Spectre branch prediction logo being used on this article?