5 ms·

> Which cryptographic algorithms can't be used? You can't use any algorithm that requires O(n) IVs (e.g. a separate IV per disk sector), because there's nowher

> Which cryptographic algorithms can't be used? You can't use any algorithm that requires O(n) IVs (e.g. a separate IV per disk sector), because there's nowhere to store the IVs. (Another consequence of this is that you can't store checksums anywhere, so you can't provide integrity checks.) You can't use CTR mode either, because you'll end up reusing counter values. What do you do when you need to overwrite a block with new data? XTS mode solves this, at least partially. It's like CTR mode, but with an extra "tweak" that essentially hashes the block's content into the encryption key. So if you overwrite a block with new data, you get a new encryption key. This isn't perfect, though, because it's still deterministic. If an attacker can see multiple states of the disk, they can tell when you revert a block to a previous state. But it's much better than other modes, especially since the main threat you want to protect against is your laptop getting stolen (in which case the attacker only sees a single state).

dependenttypes 7y ago
> You can't use any algorithm that requires O(n) IVs (e.g. a separate IV per disk sector), because there's nowhere to store the IVs Certainly you can. You just have to reduce the effective sector size that the file system can use. > What do you do when you need to overwrite a block with new data? You generate a new random nonce (as per XChacha) and you store it in the sector.
- Hello71 7y ago
  > Certainly you can. You just have to reduce the effective sector size that the file system can use. get back to me when you find a high-performance (FAT doesn't count) Linux filesystem that supports sector sizes of 496.
  - dependenttypes 7y ago
    Modern disks use much bigger sectors. See https://en.wikipedia.org/wiki/Advanced_Format https://en.wikipedia.org/wiki/Advanced_Format
    - jdsully 7y ago
      The issue is non power of 2 sector sizes. The kernel computes sectors with shifts not division (which would be slow).
      - dependenttypes 7y ago
        I do not see how you would need to use divisions in that case. But even if that was the case, you could just pretend to the OS that you have 7 sectors of 512 bytes each rather than a single sector of 4032 bytes. (or if that was not possible you could just take the hit)
        jdsully 7y ago
        You need division to go from a file offset in bytes to a sector number, hence the need for power of 2 sizes to make this fast. The kernel assumes in multiple places sectors are a power for 2 for this reason - it doesn't rely on the compiler to optimize it (which may not even be possible for some of the compilers it works on). If you are talking about using reserved sectors for book keeping at the end of the disk that is possible and commonly done.

dependenttypes 7y ago

> You can't use any algorithm that requires O(n) IVs (e.g. a separate IV per disk sector), because there's nowhere to store the IVs Certainly you can. You just have to reduce the effective sector size that the file system can use. > What do you do when you need to overwrite a block with new data? You generate a new random nonce (as per XChacha) and you store it in the sector.

Hello71 7y ago
> Certainly you can. You just have to reduce the effective sector size that the file system can use. get back to me when you find a high-performance (FAT doesn't count) Linux filesystem that supports sector sizes of 496.
- dependenttypes 7y ago
  Modern disks use much bigger sectors. See https://en.wikipedia.org/wiki/Advanced_Format https://en.wikipedia.org/wiki/Advanced_Format
  - jdsully 7y ago
    The issue is non power of 2 sector sizes. The kernel computes sectors with shifts not division (which would be slow).
    - dependenttypes 7y ago
      I do not see how you would need to use divisions in that case. But even if that was the case, you could just pretend to the OS that you have 7 sectors of 512 bytes each rather than a single sector of 4032 bytes. (or if that was not possible you could just take the hit)
      - jdsully 7y ago
        You need division to go from a file offset in bytes to a sector number, hence the need for power of 2 sizes to make this fast. The kernel assumes in multiple places sectors are a power for 2 for this reason - it doesn't rely on the compiler to optimize it (which may not even be possible for some of the compilers it works on). If you are talking about using reserved sectors for book keeping at the end of the disk that is possible and commonly done.