4 ms·

Unless you’re in an environment where you literally have to type or provide the decrypting key on each start, you are dealing with a situation where your provid

by 404mm 5y ago

Unless you’re in an environment where you literally have to type or provide the decrypting key on each start, you are dealing with a situation where your provider has both the encrypted data and the encryption key.

throw0101a 5y ago
> Unless you in an environment where you literally have to type or provide the decrypting key on each start The OS may boot up, but one could have the data on a separate volume. Services won't start until that volume is mounted, which could be manual-only. Either LUKS-on-any-FS or encrypted ZFS would work. With encrypted (Open)ZFS you can actually send encrypted bits remotely: the destination does not need the key to save the bit stream to disk, so you can have a secure cold storage copy of your data. > There's an even more compelling reason to choose OpenZFS native encryption, though—something called "raw send." ZFS replication is ridiculously fast and efficient—frequently several orders of magnitude faster than filesystem-neutral tools like rsync—and raw send makes it possible not only to replicate encrypted datasets and zvols, but to do so without exposing the key to the remote system. > This means that you can use ZFS replication to back up your data to an untrusted location, without concerns about your private data being read. With raw send, your data is replicated without ever being decrypted—and without the backup target ever being able to decrypt it at all. This means you can replicate your offsite backups to a friend's house or at a commercial service like rsync.net or zfs.rent without compromising your privacy, even if the service (or friend) is itself compromised. * https://arstechnica.com/gadgets/2021/06/a-quick-start-guide-to-openzfs-native-encryption/ https://arstechnica.com/gadgets/2021/06/a-quick-start-guide-...
- pc86 5y ago
  Nobody is arguing that it's not possible. We're just saying it's a huge hassle and that even being willing to go through the hassle on every boot is itself a red flag.
  - pessimizer 5y ago
    It's not a huge hassle, it's a mild hassle. I'm no ZFS expert, but LUKS is trivial.
  - throw0101a 5y ago
    How many times do your systems reboot?
nine_k 5y ago
But typing in the key at boot / mount time is the only setup when disk encryption makes any sense at all.
- toast0 5y ago
  Full disk encryption with the key stored in a TPM or something makes sense as a way to enable a quick secure erase. If you clear the key from the TPM, the storage is useless; or if the storage gets removed for decommisioning, it's going to be hard to match it back up to the TPM, even if the TPM isn't cleared.

by 404mm 5y ago

throw0101a 5y ago

> Unless you in an environment where you literally have to type or provide the decrypting key on each start The OS may boot up, but one could have the data on a separate volume. Services won't start until that volume is mounted, which could be manual-only. Either LUKS-on-any-FS or encrypted ZFS would work. With encrypted (Open)ZFS you can actually send encrypted bits remotely: the destination does not need the key to save the bit stream to disk, so you can have a secure cold storage copy of your data. > There's an even more compelling reason to choose OpenZFS native encryption, though—something called "raw send." ZFS replication is ridiculously fast and efficient—frequently several orders of magnitude faster than filesystem-neutral tools like rsync—and raw send makes it possible not only to replicate encrypted datasets and zvols, but to do so without exposing the key to the remote system. > This means that you can use ZFS replication to back up your data to an untrusted location, without concerns about your private data being read. With raw send, your data is replicated without ever being decrypted—and without the backup target ever being able to decrypt it at all. This means you can replicate your offsite backups to a friend's house or at a commercial service like rsync.net or zfs.rent without compromising your privacy, even if the service (or friend) is itself compromised. * https://arstechnica.com/gadgets/2021/06/a-quick-start-guide-to-openzfs-native-encryption/ https://arstechnica.com/gadgets/2021/06/a-quick-start-guide-...

pc86 5y ago
Nobody is arguing that it's not possible. We're just saying it's a huge hassle and that even being willing to go through the hassle on every boot is itself a red flag.
- pessimizer 5y ago
  It's not a huge hassle, it's a mild hassle. I'm no ZFS expert, but LUKS is trivial.
- throw0101a 5y ago
  How many times do your systems reboot?

nine_k 5y ago

But typing in the key at boot / mount time is the only setup when disk encryption makes any sense at all.

toast0 5y ago
Full disk encryption with the key stored in a TPM or something makes sense as a way to enable a quick secure erase. If you clear the key from the TPM, the storage is useless; or if the storage gets removed for decommisioning, it's going to be hard to match it back up to the TPM, even if the TPM isn't cleared.