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

  • #11
    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".

    Comment


    • #12
      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.

      Comment


      • #13
        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.
        ​​

        Comment


        • #14
          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 :-)

          Comment


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

            Comment


            • #16
              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.

              Comment


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

                Comment

                Working...
                X