45

Android uses full-disk encryption to encrypt files and decrypt them at startup. What I don't understand is that decrypting multiple gigabytes of files must take a lot of time, if nothing else then atleast the IO access time required to read all the contents of the storage, but android boots up in mere seconds. How is this possible?

Aayush Mahajan
  • 541
  • 1
  • 4
  • 6
  • 4
    in recent versions Android does not use FDE but FBE ( File Based Encryption) only the Data partition is encrypted. – architekt May 14 '18 at 07:38
  • 4
    hardware decryption is FAST, my computer, which is 7 years old now, can decrypt at 3.5 gigabytes per second. I know a phone is not as fast as a desktop, but it does not need to be (as per the answers), as it only needs to be as fast as the storage device, which is generally on the order of 100MB/s – Richie Frame May 14 '18 at 20:36
  • @RichieFrame: Hardware decryption? This is software-based right? – user541686 May 14 '18 at 22:46
  • 2
    @Mehrdad Hardware accelerated is probably a better term, the software makes it work, but the primitive is implemented in silicon by way of specific instructions, see AES-NI – Richie Frame May 15 '18 at 03:19
  • Is Windows or Linux encryption slow and how? – i486 May 15 '18 at 13:15
  • @i486 What? That question does not make sense. – forest May 20 '18 at 00:04
  • @forest The question is "Android encryption ... fast". – i486 May 20 '18 at 06:52

3 Answers3

85

Encryption happens in memory, not on the disk.

You are misunderstanding how disk encryption works. It does not read the entire disk and replace it with a decrypted version. Rather, when a file or sector of encrypted data is accessed, it is read into memory and decrypted in memory. Likewise, when writing to the disk, data is encrypted in memory before being saved to persistent storage. Operating systems keep copies of data that have been read or is to be written in memory (the filesystem buffer) as a performance optimization. It is in this memory that the encryption and decryption take place. This allows data to be read from the disk and decrypted once, but subsequently accessed many times from memory. Incidentally, using memory to store frequently-accessed files is why so many people mistakenly think Linux eats too much RAM.

I also want to point out that the bottleneck is often I/O, not encryption. You say that encrypting gigabytes of data takes a long time, but on most modern machines (including mobile devices), encrypting gigabytes of data can take only a few seconds (especially with hardware acceleration, encryption is really, really fast). However the solid-state drive in most modern Android devices is unable to read or write data at nearly those speeds. So no matter how fast you are trying to read or write data to the disk, the bottleneck will generally always be I/O, not encryption.

Older hardware often did suffer reduced performance when encryption was in use. This was because, at that time, storage speeds were improving faster than processor speeds. The lack of dedicated hardware acceleration for cryptography and the inefficient algorithms often caused a noticeable slowdown when accessing the disk. On modern systems, this is reversed. The processor is so fast that the storage device struggles to keep up. Any overhead is negligible.

forest
  • 64,616
  • 20
  • 206
  • 257
  • 3
    "Older hardware often did suffer reduced performance when encryption was in use. This was because, at that time, storage speeds were improving faster than processor speeds" --> That reasoning is not correct (or at least insufficient). If you accelerate faster than Person X, there is no indication that you are faster than Person X; you are just changing your speed faster, but that does mean you are faster. How about just "back then, disks were major bottlenecks, but nowadays CPUs have outpaced them". – phresnel May 14 '18 at 12:25
  • The processor might be fast, but are you sure it is faster than the flash memory? (Especially when encryption can only steal so much time from the actual programs to be run?) – user1686 May 14 '18 at 13:35
  • @grawity Yes, almost always. http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.den0024a/BABJDBHI.html "In many ARM processor-based systems, access to external memory takes tens or even hundreds of core cycles." And that's just to access RAM, accessing on-disk data is even slower. Which is why we still have RAM on modern systems. – JAB May 14 '18 at 16:14
  • @grawity There are some rare cases when the CPU can't keep up, such as with certain M.2 flash devices which can max out at a few GiB/s (for a short time, since they heat up quite a bit and need to throttle to cool down). – forest May 14 '18 at 16:19
  • Regarding Linux eating RAM, Windows does too. It will happily do the same as Linux does, only it doesn't report it in the same way, so it is less obvious for the average user to realise what is happening. – Baldrickk May 14 '18 at 16:29
  • 2
    "disks were the major bottleneck, but nowadays CPUs have outpaced them". This doesn't sound right. Actually, it sounds paradoxical. Bottlenecks are, roughly, the slower part of a circuit or algorithm. But then you say CPUs have only nowadays outpaced these slower disks. Which device was/is slower? – Cássio Renan May 14 '18 at 16:31
  • @CássioRenan I switched to that wording without really thinking. When my brain has started functioning I'll make a real edit to make more sense. – forest May 14 '18 at 16:33
  • 2
    @Baldrickk Indeed, but I mentioned Linux specifically because Android uses it. – forest May 15 '18 at 00:37
50

It doesn't decrypt the full disk at startup. Instead, it continously decrypts data as it is read from the disk when it is read from the disk, leaving the actual content on the disk untouched and encrypted. Since decryption is fast in comparison to disk reads, it shouldn't affect the reading speed significantly. Of course, it adds (marginally) to overall load, though.

Rodrigo de Azevedo
  • 242
  • 2
  • 13
Anders
  • 64,406
  • 24
  • 178
  • 215
  • 17
    Many smartphones in the last few years have hardware AES encryption, so full disk encryption adds very little to the overall load. https://en.wikipedia.org/wiki/AES_instruction_set – Schwern May 13 '18 at 01:50
  • 13
    @Schwern Yes, but nothing is free. Still costs battery and a few transistors. :-) – Anders May 13 '18 at 08:28
16

There's no reason to decrypt gigabytes of files at startup. Android only needs to decrypt exact files it needs to load in memory on startup.

FDE in Android doesn't encrypt the kernel, only the user data partition. You can read more on the official site.

Modern hardware-accelerated encryption is quite fast and doesn't slow the system down too much. Especially when it's only user files that are encrypted with FDE, and they aren't really speed-critical. There are other drawbacks, actually listed on the linked page, but speed is not the issue.

Android phones couldn't decrypt the whole partition on startup even if they wanted to - there's nowhere to store it.

ZOMVID-21
  • 2,450
  • 11
  • 17