I recently bought an SSD drive and realized that my CPU (Celeron 1007U - has no AES instructions) cannot really keep up encrypting it and the SSD doesn't have hardware encryption built in. This made me realize that if I want to use all of the horsepower there, I need to give up on encrypting every HDD block.

After a bit of thinking, I realized I could keep my partition kind of "tamper-proof" if it kept integrity data (checksums) on a separate volume that is encrypted - in that case, data would still visible but the attacker wouldn't be able to change it. Excluding the problems related to storing the bootloader, is my thinking correct? Would it actually stand a chance of letting me utilize 500MiB/s on this processor if the SSD supports it? If yes, do you know any Linux projects that would let me do that (filesystems, device mapper plugins or LVM features)?

  • 1
    An attacker could still make changes. You would be able to detect them, but that won't help you recover any lost data.
    – Philipp
    Commented Mar 1, 2016 at 9:43
  • @Philipp: you're right and I accept that. It's just that I'd prefer to be able to detect them (and get I/O errors).
    – d33tah
    Commented Mar 1, 2016 at 9:43
  • How many bits does the data integrity algorithm use, and is it designed to be collision resistant? Remember that these algorithms aren't necessary crytographic hashes, and are designed for other purposes than to prevent attacks on them. Commented Mar 1, 2016 at 18:08
  • If CPU is not capable enough, maybe a GPU with CUDA would?
    – ArekBulski
    Commented Mar 7, 2016 at 3:13
  • @ArekBulski: interesting idea, but I doubt that my netbook has a GPU strong enough (it's an Intel integrated chip).
    – d33tah
    Commented Mar 7, 2016 at 7:44

2 Answers 2


What you are asking is not achievable for several reasons.

Problem 1: What block size of data would correspond to a single authentication tag?

  • Block size is smallest for SSD which is 4K. Tags are smaller, 256 bits or so, and assumed to be stored on SSD as well. This leads to write amplification on the side of SSD holding authentication tags, unless your writes are within 512K boundaries (half megabyte). Number comes from the fact that one 4K block can hold 128 tags, so one 4K block full of tags would correspond to 128 data blocks, each 4K in size.
  • Block size is again 4K but each authentication tag occupies 4K as well. This nullifies write amplification but storage required for tags is same as for data, ratio is 1:1. Terabyte of data comes with a terabyte of authentication tags.
  • Block size is larger. This leads to less space needed for authentication tags. The larger data block becomes the less space is used for authentication but at same time more data must be processed to compute tags. This leads to an effect similar to write amplification.

Problem 2: Hashing is more computationally expensive than encryption.

  • Hashing algorithms used in cryptography in the past like SHA1 used to be significantly more expensive in terms of cpb. Modern hashing like SipHash and another russian I cannot name from memory are becoming very close to stream ciphers but are still above them. They will not become cheaper than ciphers.
  • Block ciphers could be used for authentication. LRW mode could be used for example, but in that scheme each data block goes through two block encryption operations. So it is not going to be "cheaper than encryption."
  • Stream ciphers cannot be used for authentication.

How can you be sure that the data integrity is actually used?

If an attacker can write to arbitrary data and have it be read back, how can you be sure the attacker hasn't modified your kernel to simply ignore any data integrity miss-match?

I'm not intimately familiar with the data integrity checking of the kernel, but if the attacker could somehow either turn off data integrity checking, or modify it in some way, then the checking wouldn't matter.

  • I'd encrypt the system, but not the "not-private" partition.
    – d33tah
    Commented Mar 1, 2016 at 17:45
  • The kernel would reside on encrypted volume that would be assumed to be authentic. This is not formally sound but still better than encryption only that has no authentication anyway. He could also consider booting from external device like SD card. That would allow to establish the kernel as authentic.
    – ArekBulski
    Commented Mar 4, 2016 at 23:48

You must log in to answer this question.

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