I'm trying to implement an encrypted file-system.

The file-system consists of 512-byte sectors. I encrypt/decrypt the contents of a sector as follows:

  1. Compute the SHA256 sum of the user password. This results in a 32-byte User Key.

  2. Compute the ESSIV for a sector by computing the SHA256 sum of User Key and the Sector Number. This results in a 32-byte Sector Key.

  3. XOR Sector Key with the plain sector data to get the cipher data as follows:

sector[0] = sector[0] ^ key[0]
sector[1] = sector[1] ^ key[1]
sector[31] = sector[31] ^ key[31]

sector[32] = sector[32] ^ key[0]
sector[33] = sector[33] ^ key[1]
sector[63] = sector[63] ^ key[31]

sector[511] = sector[511] ^ key[31]

When reading the sector back later, I XOR the Sector Key with the cipher data to get my plain sector data back.

Now, the ESSIV approach is supposed to prevent watermarking attacks. However, when I examine the ciphered sectors corresponding to a very large file (>> 512-bytes) full of only zeroes (0x00)...

  • I see that no two ciphered sectors of this large file are identical, which is great!
  • I see repeating patterns (each pattern 32-bytes long) within the same sector, which is not so great! These are obviously coming from by XOR step above.

My question is 2-fold:

  1. Can an adversary break open the above file-system encryption by copying carefully constructed files to this file-system? Or, is the above scheme good enough?

  2. When I copy the above file to a TrueCrypt volume, I see no repeating patterns. (I used AES and RIPEMD-160 as the encryption and hashing algorithms, respectively.) So, other than using AES, what can I do to achieve a TrueCrypt-like result via some simple and lightweight XOR-like operation?

2 Answers 2


Your approach is sound (even if we should always remember the first law of cryptography: "don't roll your own"). If I may suggest some slight twists:

  1. Compute the SHA256 checksum of some fixed salt (better if depending on the file system, e.g. a random sequence stored therein) and the user password. This prevents an attacker from having a database of SHA256 checksums of common passwords. The salt will be generated at random when(ever) the file system is formatted, and stored in the file system structure (Password Salt). The attacker has then to regenerate its SHA256 database anew after getting access to the file system (which means he is bruteforcing with zero advantage).

  2. Do not use the User Key for encrypting the disk. Better to use a random 32-byte key, and encrypt this key using the hashed password. Security is the same, but this way, should the user change his password, you don't need to decrypt and re-encrypt the whole file system, only decrypt and re-encrypt the key.

  3. Instead of using what is effectively ECB mode for sector encoding, use the slower but more secure CTR, using yor sector key as IV:

    SHA256( SectorNumber, DiskKey ) => IV for this sector

    SHA256( IV, 0 ) => XOR key for bytes 0..31

    SHA256( IV, 1 ) => XOR key for bytes 32..63


    SHA256( IV, 15 ) => XOR key for bytes 480..511

  • 1
    Q: In suggestion #1: Is the salt fixed (i.e., a hard-coded value inside the file-system driver, and thus 'fixed' for all instances of the filesystem, and which the adversary can reverse engineer); or, is it a random value varying with each file-system instance? If it's the latter, where and how will it be stored and read? (TIA)
    – Harry
    Commented Feb 26, 2014 at 15:37
  • But storing the salt inside the encrypted file-system (FS) will create a chicken-and-egg situation during regular mounting of the FS by its legal user. Namely, to get the salt out of the FS, the driver needs to decrypt the FS first, and to decrypt the FS the driver needs the salt first. In the applications of salt that I'm aware of (from its Wikipedia page), the salt exists -- and can be made available to the application -- independently of the user password. In my application (the FS), there is no such database outside of the FS. Am I right?
    – Harry
    Commented Feb 27, 2014 at 1:40
  • Yes and no. The salt and disk key have to be stored in non-encrypted areas of the FS (sort of a boot sector). As for the rest, I'm ashamed to say that I had mis-read and misunderstood your requirements; I was thinking AES, not XOR. I've modified my #3 suggestion accordingly.
    – LSerni
    Commented Feb 27, 2014 at 8:22
  • Nothing to be ashamed of. I still gained quite a bit of insight from this exchange with you. Thanks again. If you can think of anything else, please do post a comment, I'll meanwhile consider yours as final-enough response.
    – Harry
    Commented Feb 27, 2014 at 10:25
  • 1
    Yes, the ellipsis should be there (will add). And no, there's a difference in respect with XEX because XEX does encryption, while we're just XORing and using a hash function. The approach is however analogous, yes.
    – LSerni
    Commented Mar 2, 2014 at 15:47

I got a lead with XEX.

PS: Please feel free to share any better answers or insights, and I will select yours as final instead.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .