1
$\begingroup$

So I am a newbie to this. Has anyone experimented implementing a stream cipher for full disk encryption?

EDIT

With the caveats that come with using a stream cipher over a block cipher of course! I am thinking in the context of mobile storage. I keep reading about these block ciphers but never stream ciphers.

$\endgroup$
4
$\begingroup$

The problem with full-disk encryption is that you don't want to "waste" space on authentication tags (because it would result in odd sector sizes or in a large latency / overhead on-disk).

So we can't have tags, but also don't want to completely give up on the nice features authentication offers, especially the fact that you can detect manipulation. With stream ciphers this is about impossible, because an attacker can change data at bit-level granularity and eg surgically implement a virus on the drive if he knows a file that gets automatically executed at system launch.

Now block-ciphers could make this much harder if you used modes which effectively turn whole disk sectors into blocks which where one bit-flip would destroy (i.e. randomize) the entire plaintext. Unfortunately these modes have computational overhead and thus aren't used.

What we actually do is encrypt each block individually with a specific "tweak"-value for this block which gains us these three properties that we wouldn't have with stream ciphers:

  • If you change a bit in the ciphertext, 128 bits of plaintext get changed
  • No matter how much you know about the underlying plaintext, changing bits in the ciphertext will result in different, unpredictable gibberish plaintext each time
  • You don't have to worry about IV/Nonce management which would be a major headache, because you'd have to change the IV for each sector update and storing the IV has the same problems as with tags, generating it from the sector index has the problem of IV re-use which usually leaks a lot of plaintext-information and incorporating a usage counter has the overhead of having to try different values or storing a counter which is back at the first problem
| improve this answer | |
$\endgroup$
  • $\begingroup$ Destroy the plaintext is probably better written as randomize the plaintext. $\endgroup$ – Maarten Bodewes Dec 1 '17 at 21:51
0
$\begingroup$

In order to work with existing unmodified file systems, disk encryption must map plaintext disk sectors to identical-size ciphertext disk sectors (typically 512 or 4096 bytes), independently for every disk sector position. This excludes adding any state such as a counter to each sector.

That means when you overwrite a disk sector, you are essentially limited to using a disk-wide secret key and the disk sector number—neither of which changes from version to version of the disk sector. That pretty much rules out using a stream cipher, because you need a unique input for each version of the disk sector to select a different key stream.

In the worst case of the best possible disk encryption scheme, where every disk sector position is encrypted using a 512- or 4096-byte permutation chosen uniformly at random, an adversary will be able to tell when a disk sector is unchanged from one snapshot to another.

Modern disk encryption schemes like CBC-ESSIV are approximations to that which leak a little more than just which complete disk sectors are unchanged but not much more: specifically, CBC-ESSIV leaks which prefixes of disk sectors, in cipher block units, are unchanged. (BitLocker used to use the so-called ‘Elephant diffuser’ to better approximate ideal disk encryption so that it doesn't leak the prefixes either, but it was removed a few years ago for reasons that remain unclear to me.)

Aside: The utility of disk encryption is important, but limited. It thwarts a thief who steals your disk, and it lets you recycle your disk or send it in for RMA without having to worry about sensitive information that might have been stored on it. It does not thwart an adversary who can modify your disk: if it's in your laptop, the adversary has far more interesting avenues of attack than overwriting parts of your disk, e.g. installing malicious firmware.

For something like a remote disk, like iSCSI, where tampering is relevant, you might sensibly use an authenticated encryption scheme involving a stream cipher at the level of the file system rather than to simulate a disk that existing file systems can work with. For example, ZFS supports authentication in the file system, whereas a disk could not transparently add that for all file systems without risking serious data loss in cases that the file system would otherwise handle gracefully.

| improve this answer | |
$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.