tuxmain/website
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity

Blog: Update flash filesystem encryption

Browse source
This commit is contained in:
Pascal Engélibert 2026-06-14 21:40:19 +02:00
commit e9a1608a8f
7 changed files with 165 additions and 20 deletions
Download patch file Download diff file Expand all files Collapse all files

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

@ -90,7 +90,7 @@ The problem is that flash memories are slow and become damaged after a limited n
> La peste soit du FAT !
>
>_Dom Juan_, Molière
> _Dom Juan_, Molière
Now that we've highlighted an important property of flash memories, it appears FAT32 may not be the best choice as a filesystem. Indeed, a modified block would stay at the same physical address, causing different regions of the storage to wear more rapidly than others. It would be better to spread the write operations across the entire space, in order to maximize the time before a failure happens.
@ -200,7 +200,7 @@ Sectors must not be too long, however, as random access to block j needs computi
AES128 needs 128 bits of key, however the user will only remember ASCII words, not fully random bytes. We need something to derive a key from a variable-length password. We could just compute a hash of the password, as the ESP32 provides a hardware implementation of SHA2, but for storing passwords it is better to use a dedicated function that is fast enough to run once but hard to bruteforce efficiently on optimized systems.
[PBKDF2](https://fr.wikipedia.org/wiki/PBKDF2) chains thousands of calls to a hash function, each one depending on the previous one, so it is impossible to parallelize. However an attacker can run thousands of instances in parallel on a GPU or cryptocurrency-mining chip.
[PBKDF2](https://en.wikipedia.org/wiki/PBKDF2) chains thousands of calls to a hash function, each one depending on the previous one, so it is impossible to parallelize. However an attacker can run thousands of instances in parallel on a GPU or cryptocurrency-mining chip.
A popular choice as of today is [Argon2](https://en.wikipedia.org/wiki/Argon2), which is memory-hard: one instance requires efficient access to a big amoung of memory, potentially megabytes or even gigabytes, so it is difficult to optimize even on dedicated hardware. Problems are that its implementation is quite complicated (it will take too much ROM) and its specs are not even complete.
@ -210,7 +210,7 @@ The benefit of password hashing functions on the ESP32 is a bit disappointing, w
### Storing the key
It can be useful to use two keys: the first one, derived from the password, is used to encrypt the second key, which is written to the storage. The second key is use to encrypt the filesystem. This way, the password can be changed, as the second key does not depend on it. If you have to destroy the data in a hurry and you have a reason to think someone with a gun may force you to hand over the password, you just have to erase the stored key.
It can be useful to use two keys: the first one, derived from the password, is used to encrypt the second key, which is written to the storage. The second key is use to encrypt the filesystem. This way, the password can be changed, as the second key does not depend on it. If you have to destroy the data in a hurry and you have a reason to think someone with a gun may force you to hand over the password, you just have to erase the stored key (however, in the case the attacker with a gun is a policeperson, erasing the key may be considered as destruction of evidence hence illegal).
## Active attacks and authentication