tuxmain/website
Watch
1
0
Fork
You've already forked website
 0
Code Issues Pull requests Projects Releases Packages Wiki Activity

Blog illustrations

Browse source
This commit is contained in:
Pascal Engélibert 2026-06-23 20:22:16 +02:00
commit abcb3137f1
6 changed files with 89 additions and 16 deletions
Download patch file Download diff file Expand all files Collapse all files

12
content/blog/flash-filesystem-encryption/index.md
View file

@ -9,6 +9,10 @@ tags = ["cryptography", "ESP32"]
katex = true
+++
![Illustration picture: DIE of a flash memory showing beautiful light interference](illustration.webp)
_Illustration: CC By-SA 4.0 by [MacroWorld21 on Wikimedia Commons](https://commons.wikimedia.org/wiki/File:AMD_and_Fujitsu_Flash_Memory_Chip_from_1997.png)_
One of my long-term projects is an ESP32-based phone, using an SD card for storage. Then, why not encrypting the SD card?
_In this post, we first explain the basics of filesystem encryption, then explore ways to apply it to the case of an embedded device and flash memory. This last part is quite rarely analyzed in the literature._
@ -194,6 +198,12 @@ The fastest is XTS with one key (and salted sector number) and long sectors.
Sectors must not be too long, however, as random access to block j needs computing all j successive powers of $\alpha$. 32 blocks may be a good value, as it matches flash erase size.
### Erase size and program size
Damn, I forgot to tell about erasing and programming flash memories!
Flash memories work in a peculiar way: you first have to erase some part of the memory (by filling it with ones) then you can write data by replacing some zeros with ones. But that's not all. Each operation has a minimum size. You can generally (it depends on the chip) program down to 16 bytes, but you can only erase by chunks of (again, generally) 512 bytes!
## The key
### Deriving the key from a password
@ -222,7 +232,7 @@ If an adversary **steals your device**, they may copy your encrypted data before
**Data can be scrambled.** Altering encrypted blocks will produce valid garbage plaintexts, which may or may not be detected, depending on what files or filesystem structures are affected. Again LittleFS partly mitigates this issue, because every bit of data is covered by a checksum. A checksum is not a cryptographic tool as it has low entropy and is malleable, and its goal is to detect hardware faults, not attacks. However as XTS is not bitwise malleable, it may contribute to render active attacks harder, as a scrambled block can be marked as faulty.
**Why not authenticate?** We could write authentication tags along the data (e.g. AES-GCM, HMAC), but that would be very expensive to compute. It would also break the 1:1 correspondance between ciphertext blocks and plaintext blocks, that is vital to its performance. We would need either to write all authentication tags to a different partition (out of the filesystem, hence causing performance issues), or to make encryption part of the filesystem itself, which is a lot of work.
**Why not authenticate?** We could write authentication tags along the data (e.g. AES-GCM, HMAC), but that would be very expensive to compute. It would also break the 1:1 correspondance between ciphertext blocks and plaintext blocks, that is vital for performance. We would need either to write all authentication tags to a different partition (out of the filesystem, hence causing performance issues), or to make encryption part of the filesystem itself, which is a lot of work.
## Conclusion