According to a post on Google’s Online Security Blog, researchers in the security division of the company have developed a solution that has plagued Android devices for some time. The issue specifically relates to how lower-level Android devices that have processors that are not capable of utilizing AES encryption. AES encryption (namely AES-256) is the go-to standard for Android devices, ranging from mobile phones to smartwatches and televisions, and it is utilized specifically to protect your data should a device be stolen.
To give encrypted storage protection to lower-level Android devices that cannot use AES, Google has developed an encryption standard called Adiantum. The blog post from Google goes into detail on how Adiantum functions and ultimately the blog post acts as a summary of a larger paper entitled Adiantum: length-preserving encryption for entry-level processors that will be presented at Fast Software Encryption conference this March. Google is adamant about the encryption found in Adiantum being effective for even the most basic of Android machines, which they claim is evidenced both in the paper and in the blog post.
A detailed explanation of Adiantum can be found in the below-quoted passage from the Google Online Security Blog post:
Adiantum allows us to use the ChaCha stream cipher in a length-preserving mode, by adapting ideas from AES-based proposals for length-preserving encryption such as HCTR and HCH. On ARM Cortex-A7, Adiantum encryption and decryption on 4096-byte sectors is about 10.6 cycles per byte, around 5x faster than AES-256-XTS.
Unlike modes such as XTS or CBC-ESSIV, Adiantum is a true wide-block mode: Changing any bit anywhere in the plaintext will unrecognizably change all of the ciphertext, and vice versa. It works by first hashing almost the entire plaintext using a keyed hash based on Poly1305 and another very fast keyed hashing function called NH. We also hash a value called the “tweak” which is used to ensure that different sectors are encrypted differently. This hash is then used to generate a nonce for the ChaCha encryption. After encryption, we hash again, so that we have the same strength in the decryption direction as the encryption direction. This is arranged in a configuration known as a Feistel network, so that we can decrypt what we’ve encrypted. A single AES-256 invocation on a 16-byte block is also required, but for 4096-byte inputs this part is not performance-critical.
Google’s research seems solid but, as with anything new, it will take time to truly gauge the efficacy of something as massive as Adiantum being implemented in all lower-level Android devices.
Featured image: Flickr / Yuri Samoilov