Announcement

Collapse
No announcement yet.

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

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

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

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

    With the upcoming Linux 5.0 kernel release there is initial support for Adiantum and implemented within the fscrypt file-system encryption framework in Google's pursuit to offering more viable data encryption on low-end Android devices...

    http://www.phoronix.com/scan.php?pag...tails-Adiantum

  • elatllat
    replied
    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

    Leave a comment:


  • willmore
    replied
    Originally posted by ebiggers View Post
    [*]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.

    Leave a comment:


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

    Leave a comment:


  • ebiggers
    replied
    Originally posted by sandy8925 View Post
    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 :-)

    Leave a comment:


  • sandy8925
    replied
    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.
    ​​

    Leave a comment:


  • Mangix
    replied
    Originally posted by mzs.112000 View Post
    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.

    Leave a comment:


  • starshipeleven
    replied
    Originally posted by mzs.112000 View Post
    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".

    Leave a comment:


  • starshipeleven
    replied
    Originally posted by EarthMind View Post
    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.

    Leave a comment:


  • F.Ultra
    replied
    Originally posted by EarthMind View Post
    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).

    Leave a comment:

Working...
X