From 4bc85e0c373b4ba1547c6e6204cd78d652d234be Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Pascal=20Eng=C3=A9libert?= Date: Sun, 26 Jul 2026 22:00:13 +0200 Subject: [PATCH] Filesystem encryption: updates --- content/_index.md | 2 +- content/blog/flash-filesystem-encryption/index.md | 12 +++++++----- 2 files changed, 8 insertions(+), 6 deletions(-) diff --git a/content/_index.md b/content/_index.md index b1d0ee3..d2c2c41 100644 --- a/content/_index.md +++ b/content/_index.md @@ -8,7 +8,7 @@ title = "homepage" * Human being until proven otherwise; * a.k.a. Pascal Engélibert; -* Libre developper, PhD student at INSA Lyon; +* Libre developer, PhD student at INSA Lyon; * Master degree of cryptology & computer security; * Rust, C, Python, PHP, web, French, English, Spanish, Esperanto; * Prefers tabulations; diff --git a/content/blog/flash-filesystem-encryption/index.md b/content/blog/flash-filesystem-encryption/index.md index 84e711c..02f4d54 100644 --- a/content/blog/flash-filesystem-encryption/index.md +++ b/content/blog/flash-filesystem-encryption/index.md @@ -51,7 +51,7 @@ $$C = E(K, P)$$ This mode of operation is called ECB for Electronic Code Book. It has, however, fatal flaws: * If two blocks are identical, an adversary can spot them and learn information. -* A adversary who has access to an encryption oracle (i.e. they can obtain the ciphertext from a plaintext, that could happen if you store incoming messages in the encrypted files) can try different values and decrypt other blocks by bruteforcing well-known formats. +* An adversary who has access to an encryption oracle (i.e. they can obtain the ciphertext from a plaintext, that could happen if you store incoming messages in the encrypted files) can try different values and decrypt other blocks by bruteforcing well-known formats. ECB alone is almost never a good idea. @@ -184,15 +184,15 @@ Here are the benchmark results (encrypting 100 times 128kB): | XTS | unaligned u128 LE | 8 | 2499 | 2448 | | XTS | unaligned u128 LE | 16 | 2399 | 2445 | | XTS | unaligned u128 LE | 32 | 2373 | 2420 | -| XTS | unaligned u128 LE | 64 | 2361 | 2408 | +| XTS | unaligned u128 LE | 64 | 2361 | **2408** ⭐ | | XTS | aligned u128 | 8 | 2549 | 2447 | | XTS | aligned u128 | 16 | 2449 | 2445 | | XTS | aligned u128 | 32 | 2424 | 2420 | -| XTS | aligned u128 | 64 | 2412 | 2408 | +| XTS | aligned u128 | 64 | 2412 | **2408** ⭐ | | XTS | [u32; 4] | 8 | 2495 | 2493 | | XTS | [u32; 4] | 16 | 2395 | 2490 | | XTS | [u32; 4] | 32 | 2370 | 2465 | -| XTS | [u32; 4] | 64 | 2357 | 2453 | +| XTS | [u32; 4] | 64 | **2357** ⭐ | 2453 | The fastest is XTS with one key (and salted sector number) and long sectors. @@ -202,7 +202,9 @@ Sectors must not be too long, however, as random access to block j needs computi 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! +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 ones with zeros (that's called "programming"). 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! + +Therefore, the AES 16-byte blocks minimize useless writes. That's ideal. ## The key