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

Jerry Leichter leichter at lrw.com
Sun Feb 21 07:27:57 EST 2016


> 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.

So, yes, if you have the option to do a clean-slate design, this is no big deal (In fact, at a lower level and a number of years ago, the designers of disk subsystems did that:  All the code around knew that disk blocks were 512, but if the lowest layers actually set aside, say, 536 bytes - using the extra space for ECC - who was to know?  This required that the drive makers also wrote the match drivers - but that was expected anyway.  These days, that level of code is all inside the drives and no one outside the maker's lab knows much about it.)

Technology does advance, though.  When you were talking about spinning rust, it was essential that any metadata associated with a block be physically part of the block - putting something like an IV off elsewhere in a metadata area would destroyed performance.  With SSD's, the cost of an extra read is much less, and you might be able to get away with separated metadata.  On the other hand, you have to write in large pages, so updating that information is expensive.  So a mode that could rely on a *fixed* set of IV's might be a big win.

New storage technologies are emerging, and what we know about good and bad designs for the disk stack is increasingly out of date.  As we develop new data structures appropriate to these new technologies, it would be a really good idea to consider cryptographic support from the ground up.
                                                        -- Jerry



More information about the cryptography mailing list