[Cryptography] [Crypto-practicum] Justify the sequence of operations in CTR mode.

[Ray Dillinger]

On 02/21/2016 04:27 AM, Jerry Leichter wrote:
>> You know, after considering stuff, I think I have a conclusion
>> about whole-disk security.  And it's brutally simple. 256
>> bits is not an unreasonable size overhead for a 64kbyte block
>> cipher.  That's an overhead of 1/2048 the size of the data, a
>> bit less than 0.05%....
> The problem is that file systems, from the disk layout to the paths the data flows to and from programs, don't leave you that 0.05%.  They read a write contiguous blocks of a size that's assumed, at deep levels of the code, to either be fixed, or to be an exact small multiple of the system page size.

And so you'd need to write a whole new filesystem.  ... yes, I had
sort of thought that might be the case.  I'd been thinking of it
anyway because I'd like to extend file system functionality in some
other non-transparent ways as well.  It's annoying, but is there
any alternative that provides the same degree of protection and is
even close to being as simple and reliable?

Hmmm.  What happens if we use a cipher that takes a key 64 bits larger
than really required to achieve security - say 180 to 256 bits - and
the key used to encrypt any particular block is the salt (disk sector)
plus the user's 128-bit secure key?

No chosen-plaintext leak because no detectable relationship of
any ciphertext produced by full key A to ciphertext of the same
plaintext produced by full key B, assuming the cipher doesn't
leak to linear cryptanalysis.

No differential cryptanalysis because no plaintext/ciphertext
pairs can reveal or confirm a similarity between keys A and B,
short of brute-forcing the 128-bit security key.

This has the *tiniest* imaginable leak - if the same data is
written to the same disk sector with the same security key, it
will look the same.

There is some extra complexity, because awareness of the disk
sector parameters has to get out of the drive itself and into
the encryption module.

If the opponent has subverted the firmware on the disk (which we
have to worry about because we don't have a way to check it) is
there any way they can jigger the block and sector numbers used by
the drive to get identical "salt" used on sectors they care about
being able to compare? Hmm...  I'm going to say 'nope' because
the sector numbers the drive reports are also going to be used
to chain inodes together to make files - any misreporting two
sectors as having the same sector number will just cause the least
recently written one of them (and the file it's in, effectively)
to get lost by the filesystem.

We still get space-conserving encryption - same number of bits stored
as the length of the block, so filesystem code needs only minimal
updating.  Any change in plaintext cascades through the whole block
because basic property of block ciphers.  Every change in the
salt/IV results in a new "full key." The ciphertext of the same
plaintext encrypted by a different full key is indistinguishable
from the same plaintext encrypted by any other full key, or else
the cipher leaks on differential cryptanalysis.  So knowing the
first 64 bits of the "full key" does not give an opponent any insight
into 128 (or more) bit secure key.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20160221/48e1052f/attachment.sig>