Filesystem encryption: updates

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;

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