FYI: The AES-GCM patches as referenced in comment #19 were applied to
zfs 0.8.3-1ubuntu12.1 in 6 Jul 2020.
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to zfs-linux in Ubuntu.
https://bugs.launchpad.net/bugs/1857398
Title:
ubiquity
Status changed to 'Confirmed' because the bug affects multiple users.
** Changed in: ubiquity (Ubuntu)
Status: New => Confirmed
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to zfs-linux in Ubuntu.
Status changed to 'Confirmed' because the bug affects multiple users.
** Changed in: zfs-linux (Ubuntu)
Status: New => Confirmed
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to zfs-linux in Ubuntu.
Backporting that commit is rather non-trivial as it has some other
change dependencies and it's quite a large change for the normal SRU
process.
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to zfs-linux in Ubuntu.
The AES-GCM performance improvements patch has been merged to master. This also
included the changes to make encryption=on mean aes-256-gcm:
https://github.com/zfsonlinux/zfs/commit/31b160f0a6c673c8f926233af2ed6d5354808393
--
You received this bug notification because you are a member of Kernel
We discussed this at the January 7th OpenZFS Leadership meeting. The
notes and video recording are now available.
The meeting notes are in the running document here (see page 2 right now, or
search for this Launchpad bug number):
This is a very interesting idea, but care should be applied when
combined with cloud (disk) images. In particular, I worry that if an
encrypted disk image is distributed that the well-known passphrase could
be used to get the master key from any pristine copy of the disk image.
In effect, the
> It is not appropriate to require the user to type a password on every
> boot by default; this must be opt-in.
My suggestion was not to make EVERYONE use encrypted ZFS with a
passphrase, only those who selected an encryption option within
Ubiquity. (Perhaps my code was misunderstood as a
I agree with what Richard said above in comment #14, especially:
> The installer should prompt (with a checkbox) for whether the user
wants encryption. It should default to off. If the user selects the
checkbox, prompt them for a passphrase. Setup encryption using that
passphrase.
--
You
> It is not appropriate to require the user to type a password on every
> boot by default; this must be opt-in.
Agreed.
The installer should prompt (with a checkbox) for whether the user wants
encryption. It should default to off. If the user selects the checkbox,
prompt them for a passphrase.
> I would recommend setting encryption=aes256-gcm instead of
> encryption=on (which is aes256-ccm).
I think the right way to handle this is to change the behavior of zfs-
linux so that encryption=on defaults to the recommended algorithm -
rather than hard-coding the algorithm selection in
> I believe it would be rather trivial to have Ubiquity collect
> a password from the user, use "-O keylocation=prompt" and to
> expect the user to provide the password every reboot.
It is not appropriate to require the user to type a password on every
boot by default; this must be opt-in.
The
FWIW: Running Ubiquity 20.04 with a modified "zsys-setup" configuration
file that manually incorporates a password and encryption pool
properties works great.
echo | zpool create -f \
-O encryption=aes-256-gcm \
-O keylocation=prompt \
-O
I agree with Richard and we had the same discussion yesterday with Didier.
We should expose zfs encryption in Ubiquity and align is on LVM. This would
leave the decision to the user to use or not ZFS encryption and not force him
to use it if he selects ZFS.
Secondly, we don't have any sort of
I've given this a lot of thought. For what it's worth, if it were my
decision, I would first put your time into making a small change to the
installer to get the "encryption on" case perfect, rather than the
proposal in this bug.
The installer currently has:
O Erase disk an install Ubuntu
One last thing: I think we should test this on rotational disk and
assess the performance impacts before pushing it as a default. This will
give us a good baseline to decide if this should be pushed or if we need
to add even more warnings on the ZFS install option.
--
You received this bug
Thanks Richard for digging in, the performance comparison and the valuable
upstream feedback and pointers.
Good catch about retrieving the master key written in old blocks with the
previous (fix) passphrase even if changed later on. It seems that trimming
could help. Do you think that we should
I put these questions to Tom Caputi, who wrote the ZFS encryption. The
quoted text below is what I asked him, and the unquoted text is his
response:
> 1. Does ZFS rewrite the wrapped/encrypted master key in place? If
>not, the old master key could be retrieved off disk, decrypted
>with
I have come up with a potential security flaw with this design:
The user installs Ubuntu with this fixed passphrase. This is used to
derive the "user key", which is used to encrypt the "master key", which
is used to encrypt their data. The encrypted version of the master key
is obviously written
Here are some quick performance comparisons:
https://github.com/zfsonlinux/zfs/pull/9749#issuecomment-569132997
In summary, "the GCM run is approximately 1.15 times faster than the CCM
run. Please also note that this PR doesn't improve AES-CCM performance,
so if this gets merged, the speed
** Tags added: patch
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to zfs-linux in Ubuntu.
https://bugs.launchpad.net/bugs/1857398
Title:
ubiquity should support encryption by default with zfsroot, with users
able to opt in to running
This is an interesting approach. I figured the installer should prompt
for encryption, and it probably still should, but if the performance
impact is minimal, this does have the nice property of allowing for
enabling encryption post-install.
It might be worthwhile (after merging the SIMD fixes)
** Merge proposal linked:
https://code.launchpad.net/~vorlon/ubiquity/+git/ubiquity/+merge/377100
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to zfs-linux in Ubuntu.
https://bugs.launchpad.net/bugs/1857398
Title:
ubiquity should
ubiquity side of the equation:
https://code.launchpad.net/~vorlon/ubiquity/+git/ubiquity/+ref/lp.1857398
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to zfs-linux in Ubuntu.
https://bugs.launchpad.net/bugs/1857398
Title:
ubiquity
Here is a proof-of-concept patch for the zfs-initramfs side of such a
feature.
** Patch added: "zfs-linux-1857398.debdiff"
https://bugs.launchpad.net/ubuntu/+source/zfs-linux/+bug/1857398/+attachment/5314923/+files/zfs-linux-1857398.debdiff
--
You received this bug notification because you
25 matches
Mail list logo
