[Pkg-zfsonlinux-devel] Initializing LUKS volumes (was: Root-on-ZFS on Stretch)

[Nicolas Braud-Santoni]

On Sun, May 22, 2016 at 08:11:48PM +0200, Petter Reinholdtsen wrote:
> [Nicolas Braud-Santoni]
> > - `dd if=/dev/zero of=/dev/mapper/vacuum-crypt`  
> >   Zeroing out the encrypted volume results in cryptogarbage in the
> >   physical drive.  That's as good as initialising `/dev/sda2` with
> >   `/dev/urandom` and much faster.  0xCAFE time again!
> 
> What is your basis for the claim that it is as good as initializing with
> random data?  It seem to me like a sure way to provide a lot of examples
> of encrypted data with known plaintext, which seem like a bad idea.  At
> least I know from the Codebook and the history of breaking the Enigma
> that having knowledge about the plantext is very helpful for
> codebreakers. :)

There are several answers to this:

0) Calling luksFormat a second time would overwrite the LUKS header and
   use a new (unrelated) LUKS master key, making this a non-issue.

1) LUKS uses AES-XTS, which does not provide security claims regarding
   integrity, but should be secure (confidentiality-wise) againsts KPAs
   (Known Plaintext Attacks).  If initializing the plaintext to 0 causes
   a problem, it would only be a symptom of a much deeper issue with
   AES-XTS (and reason enough to outright stop using XTS).

2) As mentionned, XTS doesn't provide data integrity: this means an attacker
   with access to the block device could, in theory, tamper with the on-disk
   data.  In practice, since ZFS checksums the data on disk, the attacker
   should only be able to make select blocks unreadable (invalid checksum).
   Beware, though: hash-then-encrypt is definitely not a provably-secure
   construction  ;)

3) LUKS does not solve the data integrity problem /by design/ (to avoid the
   overhead of authentication tags).  Since ZFS already stores digests [0],
   a native ZFS encryption feature could solve this pretty nicely.  It is
   a work-in-progress upstream:

     https://github.com/zfsonlinux/zfs/pull/4329


[0] ZFS doesn't pay as much overhead as LUKS for paying authentication tags
    because its on-disk data structures are still aligned; this wouldn't be
    the case for some block-device-level authenticated encryption layer on
    top of which an arbitrary filesystem is stored.


PS: Sorry for the huuuuuge delay:
    I only noticed now that I didn't reply to the mailing list...
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pkg-zfsonlinux-devel/attachments/20160604/f0c1cbb5/attachment.sig>