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

[Natanael]

Den 21 feb 2016 22:11 skrev "Ray Dillinger" <bear at sonic.net>:
[...]
> 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?

I too want improved FDE, and am thinking filesystem support is necessary.
In fact, the ideal maximum security solution would probably be a
capabilities type OS design coupled with a user controlled TPM type chip.
Something where the disk starts off encrypted under a single key with
block-wise salts and nonces, where read and write access is controlled by
access to the right tokens. Encrypt the nonce and you now need that
encryption key for access to that file.

Previous writing of mine:
https://roamingaroundatrandom.wordpress.com/2014/09/20/tamper-resistant-full-disk-encryption/

> 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?
[...]
> 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.

You just described a simplified version of the XTS mode. In it the disk
block numbers are used as salts in layer one, and since blocks can have
arbitary sizes it uses the cipher block number insides the disk block as
salt number two in layer two (IIRC).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20160221/7103499c/attachment.html>