Heads up: cryptsetup switches to LUKS2 by default
Hi, For some years upstream cryptsetup already used LUKS2 as default on-disk format. The Tumbleweed package stayed with LUKS1 so far though. As grub 2.06 recently gained LUKS2 support, cryptsetup can finally switch. A cryptsetup 2.4.0 update is currently in staging and will likely land in TW soon. After that new installations will use LUKS2 for encrypted hard disks. Unfortunately grub2 can't handle Argon2 as key-derivation function yet. So TW has to stay with PBKDF2 for now. Information about LUKS2 etc can be found upstream: https://gitlab.com/cryptsetup/cryptsetup/-/wikis/home cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.com/ SUSE Software Solutions Germany GmbH, GF: Felix Imendörffer HRB 36809 (AG Nürnberg)
Hi Ludwig, On Mon, Aug 23, 2021 at 03:13:04PM +0200, Ludwig Nussel wrote:
Hi,
For some years upstream cryptsetup already used LUKS2 as default on-disk format. The Tumbleweed package stayed with LUKS1 so far though. As grub 2.06 recently gained LUKS2 support, cryptsetup can finally switch. A cryptsetup 2.4.0 update is currently in staging and will likely land in TW soon. After that new installations will use LUKS2 for encrypted hard disks.
No, the support can only be considered partially. While the grub cryptomount may be able to mount LUKS2 volumes at boot up *if porperly configured*, the auto-configuation support through grub-install and grub-probe is not ready yet, so it can't really work atm. I would be surprised if that can pass the staging test ...
Unfortunately grub2 can't handle Argon2 as key-derivation function yet. So TW has to stay with PBKDF2 for now.
Yes this is still missing. Thanks, Michael
Information about LUKS2 etc can be found upstream: https://gitlab.com/cryptsetup/cryptsetup/-/wikis/home
cu Ludwig
-- (o_ Ludwig Nussel //\ V_/_ http://www.suse.com/ SUSE Software Solutions Germany GmbH, GF: Felix Imendörffer HRB 36809 (AG Nürnberg)
Michael Chang wrote:
On Mon, Aug 23, 2021 at 03:13:04PM +0200, Ludwig Nussel wrote:
For some years upstream cryptsetup already used LUKS2 as default on-disk format. The Tumbleweed package stayed with LUKS1 so far though. As grub 2.06 recently gained LUKS2 support, cryptsetup can finally switch. A cryptsetup 2.4.0 update is currently in staging and will likely land in TW soon. After that new installations will use LUKS2 for encrypted hard disks.
No, the support can only be considered partially. While the grub cryptomount may be able to mount LUKS2 volumes at boot up *if porperly configured*, the auto-configuation support through grub-install and grub-probe is not ready yet, so it can't really work atm.
Do we actually use those tools in a yast installation?
I would be surprised if that can pass the staging test ...
I thought I saw it green with the RC version. Still building in :M now after rebase, we'll see.. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.com/ SUSE Software Solutions Germany GmbH, GF: Felix Imendörffer HRB 36809 (AG Nürnberg)
On Mon, Aug 23, 2021 at 04:20:29PM +0200, Ludwig Nussel wrote:
Michael Chang wrote:
On Mon, Aug 23, 2021 at 03:13:04PM +0200, Ludwig Nussel wrote:
For some years upstream cryptsetup already used LUKS2 as default on-disk format. The Tumbleweed package stayed with LUKS1 so far though. As grub 2.06 recently gained LUKS2 support, cryptsetup can finally switch. A cryptsetup 2.4.0 update is currently in staging and will likely land in TW soon. After that new installations will use LUKS2 for encrypted hard disks.
No, the support can only be considered partially. While the grub cryptomount may be able to mount LUKS2 volumes at boot up *if porperly configured*, the auto-configuation support through grub-install and grub-probe is not ready yet, so it can't really work atm.
Do we actually use those tools in a yast installation?
Yes they are used and required by yast-bootloader to function properly.
I would be surprised if that can pass the staging test ...
I thought I saw it green with the RC version. Still building in :M now after rebase, we'll see..
I'm not sure if staging test covers FDE (full disk encryption) with luks2, or we only use that for data volumes, leaving /boot unencrypted. Anyway grub 2.06 needs extra patches to get LUKS2 autosetup working for FDE of which Fabian has worked out some patch to filling the gap. Thanks, Michael
cu Ludwig
-- (o_ Ludwig Nussel //\ V_/_ http://www.suse.com/ SUSE Software Solutions Germany GmbH, GF: Felix Imendörffer HRB 36809 (AG Nürnberg)
Michael Chang wrote:
On Mon, Aug 23, 2021 at 04:20:29PM +0200, Ludwig Nussel wrote:
Michael Chang wrote:
On Mon, Aug 23, 2021 at 03:13:04PM +0200, Ludwig Nussel wrote:
For some years upstream cryptsetup already used LUKS2 as default on-disk format. The Tumbleweed package stayed with LUKS1 so far though. As grub 2.06 recently gained LUKS2 support, cryptsetup can finally switch. A cryptsetup 2.4.0 update is currently in staging and will likely land in TW soon. After that new installations will use LUKS2 for encrypted hard disks.
No, the support can only be considered partially. While the grub cryptomount may be able to mount LUKS2 volumes at boot up *if porperly configured*, the auto-configuation support through grub-install and grub-probe is not ready yet, so it can't really work atm.
Do we actually use those tools in a yast installation?
Yes they are used and required by yast-bootloader to function properly.
I would be surprised if that can pass the staging test ...
I thought I saw it green with the RC version. Still building in :M now after rebase, we'll see..
I'm not sure if staging test covers FDE (full disk encryption) with luks2, or we only use that for data volumes, leaving /boot unencrypted.
Yes, staging does test FDE. It's only one simple scenario though. So I'll add some extra manual testing rounds. Thanks for keeping an eye on this! :-) cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.com/ SUSE Software Solutions Germany GmbH, GF: Felix Imendörffer HRB 36809 (AG Nürnberg)
On 8/24/21 5:16 AM, Michael Chang wrote:
On Mon, Aug 23, 2021 at 04:20:29PM +0200, Ludwig Nussel wrote:
Michael Chang wrote:
On Mon, Aug 23, 2021 at 03:13:04PM +0200, Ludwig Nussel wrote:
[...]
I would be surprised if that can pass the staging test ...
I thought I saw it green with the RC version. Still building in :M now after rebase, we'll see..
I'm not sure if staging test covers FDE (full disk encryption) with luks2, or we only use that for data volumes, leaving /boot unencrypted.
It passes because YaST explicitly enforces LUKS1 to the devices it encrypts. So no matter what's the cryptsetup default, if the users choose "Enable Disk Encryption" in the Guided Setup or if they use the Expert Partitioner to setup an encrypted volume, YaST will execute in the end something like: cryptsetup --type luks1 luksFormat /foo/bar That's done on purpose due to all the LUKS2 concerns I already linked before. Cheers. -- Ancor González Sosa YaST Team at SUSE Software Solutions
Ancor Gonzalez Sosa wrote:
On 8/24/21 5:16 AM, Michael Chang wrote:
On Mon, Aug 23, 2021 at 04:20:29PM +0200, Ludwig Nussel wrote:
Michael Chang wrote:
On Mon, Aug 23, 2021 at 03:13:04PM +0200, Ludwig Nussel wrote:
[...]
I would be surprised if that can pass the staging test ...
I thought I saw it green with the RC version. Still building in :M now after rebase, we'll see..
I'm not sure if staging test covers FDE (full disk encryption) with luks2, or we only use that for data volumes, leaving /boot unencrypted.
It passes because YaST explicitly enforces LUKS1 to the devices it encrypts. So no matter what's the cryptsetup default, if the users choose "Enable Disk Encryption" in the Guided Setup or if they use the Expert Partitioner to setup an encrypted volume, YaST will execute in the end something like:
cryptsetup --type luks1 luksFormat /foo/bar
That's done on purpose due to all the LUKS2 concerns I already linked before.
Oh well that explains why the tests work then. So far I assumed that the responsibility to use defaults that work with the distro were with libcryptsetup and other tools just follow (hence PBKDF2 despite LUKS2). How come yast even bothers? cryptsetup in openSUSE never used LUKS2 as default so potential problems with it should have never appeared on your radar, right? cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.com/ SUSE Software Solutions Germany GmbH, GF: Felix Imendörffer HRB 36809 (AG Nürnberg)
On 8/24/21 11:17 AM, Ludwig Nussel wrote:
Ancor Gonzalez Sosa wrote:
On 8/24/21 5:16 AM, Michael Chang wrote:
On Mon, Aug 23, 2021 at 04:20:29PM +0200, Ludwig Nussel wrote:
Michael Chang wrote:
On Mon, Aug 23, 2021 at 03:13:04PM +0200, Ludwig Nussel wrote:
[...]
cryptsetup --type luks1 luksFormat /foo/bar
That's done on purpose due to all the LUKS2 concerns I already linked before.
Oh well that explains why the tests work then. So far I assumed that the responsibility to use defaults that work with the distro were with libcryptsetup and other tools just follow (hence PBKDF2 despite LUKS2).
In that regard, when we asked the SUSE Security Team they didn't sound exactly excited about PBKDF2. See [1].
How come yast even bothers? cryptsetup in openSUSE never used LUKS2 as default so potential problems with it should have never appeared on your radar, right?
DISCLAIMER: starting here my reply may sound defensive (apart from being looong), but that was not the intention. I'm all for adopting LUKS2, but don't forget YaST should keep users away from problems. And now, the long reply: YaST bothers because LUKS1 and LUKS2 have differences that are relevant for libstorage-ng. They support different features (like labels), they have a different layout on disk, they use different mechanisms for resizing... All that may affect several calculations done by libstorage-ng and YaST. The level of support for both in Grub2 is VERY different. That affect how the automatic partitioning proposal should look like and also the warnings the Partitioner should show in some situations. And all that may be architecure-specific. In short, LUKS1 and LUKS2 are different enough to simply be treated as the same thing in YaST. We need to be in closer control since we cannot use LUKS2 as default until all the mentioned details are ironed up. It's reasonable (and even wanted) to add general support for LUKS2 in YaST. Right now we only use it in some controlled scenarios, see [2]. But that implies limiting where and when LUKS2 can be used (based on Grub support, memory availability and other criteria), offering the possibility of using alternative algorithms (and explaining the users the advantages/problems of each one), etc. Basically all that was already described in [3]. Afterwards, we can make LUKS2 the YaST default for all situations in which is safe. Otherwise, if YaST would have just started to create LUKS2 devices due to [4], ignoring all the mentioned considerations above, it would have been YaST's fault. YaST would have been blamed for changing an important security feature in an unnoticed way, for making it easy to create non-bootable setups in so many situations, for not taking the memory usage implications into account, for using a not-so-great encryption algorithm... So YaST has plenty of reasons to control which LUKS version it proposes and all of them boil down to a common one... providing a robust and surprises-free (open)SUSE system by default. All that said, it's maybe time for a first implementation of general LUKS2 support in YaST, but only on an already running system. Not supporting it during installation and/or for any mount point that is needed for booting. We can build from there, as long as Grub also evolves to support more setups. Cheers. [1] https://bugzilla.suse.com/show_bug.cgi?id=1142801 (maybe it's an private bug currently, although it contains no sensible information and I guess it could be made public) [2] https://yast.opensuse.org/blog/2019/10/09/advanced-encryption-options-land-i... [3] https://bugzilla.suse.com/show_bug.cgi?id=1185291#c1 [4] https://build.opensuse.org/request/show/913630 -- Ancor González Sosa YaST Team at SUSE Software Solutions
Ancor Gonzalez Sosa wrote:
On 8/24/21 11:17 AM, Ludwig Nussel wrote:
Ancor Gonzalez Sosa wrote:
On 8/24/21 5:16 AM, Michael Chang wrote:
On Mon, Aug 23, 2021 at 04:20:29PM +0200, Ludwig Nussel wrote:
Michael Chang wrote:
On Mon, Aug 23, 2021 at 03:13:04PM +0200, Ludwig Nussel wrote:
[...]
cryptsetup --type luks1 luksFormat /foo/bar
That's done on purpose due to all the LUKS2 concerns I already linked before.
Oh well that explains why the tests work then. So far I assumed that the responsibility to use defaults that work with the distro were with libcryptsetup and other tools just follow (hence PBKDF2 despite LUKS2).
In that regard, when we asked the SUSE Security Team they didn't sound exactly excited about PBKDF2. See [1].
How come yast even bothers? cryptsetup in openSUSE never used LUKS2 as default so potential problems with it should have never appeared on your radar, right?
[...] Otherwise, if YaST would have just started to create LUKS2 devices due to [4], ignoring all the mentioned considerations above, it would have been YaST's fault. YaST would have been blamed for changing an important security feature in an unnoticed way, for making it easy to create non-bootable setups in so many situations, for not taking the memory usage implications into account, for using a not-so-great encryption algorithm...
Ok, if you voluntarily take the responsibility that makes my life easier :-) So far I thought I can't switch cryptsetup to use upstream defaults as that would break all kinds of things, including installation. If yast passes all known to work parameters anyway that concern is gone. Now the question is whether cryptsetup should then ship with upstream defaults completely (ie LUKS2 and Argon2) and rely on tools that use cryptsetup to know whether that actually works. The other way to look at the situation would be that cryptsetup keeps the defaults that also yast uses. So no matter whether one creates a volume in yast or on the command line it ends up with the same format by default.
[...] All that said, it's maybe time for a first implementation of general LUKS2 support in YaST, but only on an already running system. Not supporting it during installation and/or for any mount point that is needed for booting. We can build from there, as long as Grub also evolves to support more setups.
Would it be possible to have a command line option/env variable to switch the installer default to LUKS2 for testing? That would make it easier for interested parties to try it out without further commitment from yast side. Even some DUD way would be good enough at this point I think. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.com/ SUSE Software Solutions Germany GmbH, GF: Felix Imendörffer HRB 36809 (AG Nürnberg)
On 8/23/21 3:13 PM, Ludwig Nussel wrote:
Hi,
For some years upstream cryptsetup already used LUKS2 as default on-disk format. The Tumbleweed package stayed with LUKS1 so far though. As grub 2.06 recently gained LUKS2 support, cryptsetup can finally switch. A cryptsetup 2.4.0 update is currently in staging and will likely land in TW soon. After that new installations will use LUKS2 for encrypted hard disks. Unfortunately grub2 can't handle Argon2 as key-derivation function yet. So TW has to stay with PBKDF2 for now.
Information about LUKS2 etc can be found upstream: https://gitlab.com/cryptsetup/cryptsetup/-/wikis/home
Take into account YaST still doesn't include general LUKS2 support because it comes with several challenges regarding installation. See https://bugzilla.suse.com/show_bug.cgi?id=1185291#c1 Cheers. -- Ancor González Sosa YaST Team at SUSE Software Solutions
Ancor Gonzalez Sosa wrote:
On 8/23/21 3:13 PM, Ludwig Nussel wrote:
For some years upstream cryptsetup already used LUKS2 as default on-disk format. The Tumbleweed package stayed with LUKS1 so far though. As grub 2.06 recently gained LUKS2 support, cryptsetup can finally switch. A cryptsetup 2.4.0 update is currently in staging and will likely land in TW soon. After that new installations will use LUKS2 for encrypted hard disks. Unfortunately grub2 can't handle Argon2 as key-derivation function yet. So TW has to stay with PBKDF2 for now.
Information about LUKS2 etc can be found upstream: https://gitlab.com/cryptsetup/cryptsetup/-/wikis/home
Take into account YaST still doesn't include general LUKS2 support because it comes with several challenges regarding installation. See https://bugzilla.suse.com/show_bug.cgi?id=1185291#c1
Thanks for the pointer. For now we can't use Argon2 due to grub limitations anyway. The topic of memory consumption may come back when that changes. We'll see whether we need special knobs in yast or whether libcryptsetup can be made to handle that itself then. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.com/ SUSE Software Solutions Germany GmbH, GF: Felix Imendörffer HRB 36809 (AG Nürnberg)
Am Montag, 23. August 2021, 15:13:04 CEST schrieb Ludwig Nussel:
Hi,
For some years upstream cryptsetup already used LUKS2 as default on-disk format. The Tumbleweed package stayed with LUKS1 so far though. As grub 2.06 recently gained LUKS2 support, cryptsetup can finally switch. A cryptsetup 2.4.0 update is currently in staging and will likely land in TW soon. After that new installations will use LUKS2 for encrypted hard disks. Unfortunately grub2 can't handle Argon2 as key-derivation function yet. So TW has to stay with PBKDF2 for now.
Information about LUKS2 etc can be found upstream: https://gitlab.com/cryptsetup/cryptsetup/-/wikis/home
So the encrypted home partition -- LUKS1 -- on my SSD will after a certain zypper dup be encrypted with LUKS2 ? That sounds scary to me, even more, since snapper rollback probably wouldn't work, would it? -- Regards, Alexander
On 24/08/2021 18.47, AW wrote:
Am Montag, 23. August 2021, 15:13:04 CEST schrieb Ludwig Nussel:
Hi,
For some years upstream cryptsetup already used LUKS2 as default on-disk format. The Tumbleweed package stayed with LUKS1 so far though. As grub 2.06 recently gained LUKS2 support, cryptsetup can finally switch. A cryptsetup 2.4.0 update is currently in staging and will likely land in TW soon. After that new installations will use LUKS2 for encrypted hard disks. Unfortunately grub2 can't handle Argon2 as key-derivation function yet. So TW has to stay with PBKDF2 for now.
Information about LUKS2 etc can be found upstream: https://gitlab.com/cryptsetup/cryptsetup/-/wikis/home
So the encrypted home partition -- LUKS1 -- on my SSD will after a certain zypper dup be encrypted with LUKS2 ?
AFAIK, no, migration is not possible, you have to create the encrypted space again from scratch. Like formatting. -- Cheers / Saludos, Carlos E. R. (from 15.2 x86_64 at Telcontar)
On Tue, 2021-08-24 at 19:11 +0200, Carlos E. R. wrote:
On 24/08/2021 18.47, AW wrote:
So the encrypted home partition -- LUKS1 -- on my SSD will after a certain zypper dup be encrypted with LUKS2 ?
AFAIK, no, migration is not possible, you have to create the encrypted space again from scratch. Like formatting.
There's "cryptsetup convert --type luks2". Never tried it. I suppose a backup would be recommended. Regards, Martin
On 25/08/2021 09.43, Martin Wilck wrote:
On Tue, 2021-08-24 at 19:11 +0200, Carlos E. R. wrote:
On 24/08/2021 18.47, AW wrote:
So the encrypted home partition -- LUKS1 -- on my SSD will after a certain zypper dup be encrypted with LUKS2 ?
AFAIK, no, migration is not possible, you have to create the encrypted space again from scratch. Like formatting.
There's "cryptsetup convert --type luks2". Never tried it. I suppose a backup would be recommended.
Didn't know that one, maybe it is new. I would hesitate to use it, though. Call me paranoid :-) -- Cheers / Saludos, Carlos E. R. (from 15.2 x86_64 at Telcontar)
Am Mittwoch, 25. August 2021, 09:43:11 CEST schrieb Martin Wilck:
On Tue, 2021-08-24 at 19:11 +0200, Carlos E. R. wrote:
On 24/08/2021 18.47, AW wrote:
So the encrypted home partition -- LUKS1 -- on my SSD will after a certain zypper dup be encrypted with LUKS2 ?
AFAIK, no, migration is not possible, you have to create the encrypted space again from scratch. Like formatting.
There's "cryptsetup convert --type luks2". Never tried it. I suppose a backup would be recommended.
Always and ever, but home partitions tend to have, like mine, hundreds of gigabyte and more. Reinstalling a system takes 90 minutes, but getting the home partition back is a completely other kind of sports. -- Regards, Alexander
On Wed, 2021-08-25 at 11:02 +0200, AW wrote:
Am Mittwoch, 25. August 2021, 09:43:11 CEST schrieb Martin Wilck:
On Tue, 2021-08-24 at 19:11 +0200, Carlos E. R. wrote:
On 24/08/2021 18.47, AW wrote:
So the encrypted home partition -- LUKS1 -- on my SSD will after a certain zypper dup be encrypted with LUKS2 ?
AFAIK, no, migration is not possible, you have to create the encrypted space again from scratch. Like formatting.
There's "cryptsetup convert --type luks2". Never tried it. I suppose a backup would be recommended.
Always and ever, but home partitions tend to have, like mine, hundreds of gigabyte and more. Reinstalling a system takes 90 minutes, but getting the home partition back is a completely other kind of sports.
Well, if you had your system running for more than a few months, getting root partition back with all configuration restored is more effort than just a simple reinstall. The migration path is still unclear to me. Multiboot systems would also be an issue - what if the disk is shared e.g. between a TW and a Leap installation? Will Leap get the LUKS2 support, too? Martin
On Wed, Aug 25, Martin Wilck wrote:
On Wed, 2021-08-25 at 11:02 +0200, AW wrote:
Always and ever, but home partitions tend to have, like mine, hundreds of gigabyte and more. Reinstalling a system takes 90 minutes, but getting the home partition back is a completely other kind of sports.
Why do you want to convert an existing LUKSv1 home partition to LUKSv2?
Well, if you had your system running for more than a few months, getting root partition back with all configuration restored is more effort than just a simple reinstall.
The migration path is still unclear to me. Multiboot systems would also be an issue - what if the disk is shared e.g. between a TW and a Leap installation? Will Leap get the LUKS2 support, too?
Why do you want to migrate a LUKSv1 partition to LUKSv2? And in the case of sharing a home partition between TW and Leap: just keep LUKSv1. Migration makes only sense to me, if you could use afterwards new functionality you urgently need. And most likely you will get this new functionality only with a fresh installation, since the "right" LUKS disk format is not the culprint. Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & MicroOS SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany Managing Director: Felix Imendoerffer (HRB 36809, AG Nürnberg)
On Wed, 2021-08-25 at 12:09 +0200, Thorsten Kukuk wrote:
On Wed, Aug 25, Martin Wilck wrote:
On Wed, 2021-08-25 at 11:02 +0200, AW wrote:
Always and ever, but home partitions tend to have, like mine, hundreds of gigabyte and more. Reinstalling a system takes 90 minutes, but getting the home partition back is a completely other kind of sports.
Why do you want to convert an existing LUKSv1 home partition to LUKSv2?
Why do we update to the new format? Because it has a few advantages, I suppose. LUKS2 "allows additional extensions like different PBKDF algorithm or authenticated encryption" says the man page. So there are reasons to want to use this for existing systems, not only for new installations. Personally, I'm just now preparing a new system which I intend to use over several years, so the choice of the disk format does matter, in particular the question whether LUKS1 will look totally outdated in 5 years. If there was a reliable conversion path, I'd happily use LUKS1 now. Otherwise it might make sense to apply some non-standard package updates to use LUKS2 already today, before substantial amounts of data pile up on my encrypted partition. Regards, Martin
Martin Wilck wrote:
On Wed, 2021-08-25 at 12:09 +0200, Thorsten Kukuk wrote:
On Wed, Aug 25, Martin Wilck wrote:
On Wed, 2021-08-25 at 11:02 +0200, AW wrote:
Always and ever, but home partitions tend to have, like mine, hundreds of gigabyte and more. Reinstalling a system takes 90 minutes, but getting the home partition back is a completely other kind of sports.
Why do you want to convert an existing LUKSv1 home partition to LUKSv2?
Why do we update to the new format? Because it has a few advantages, I suppose. LUKS2 "allows additional extensions like different PBKDF algorithm or authenticated encryption" says the man page. So there are reasons to want to use this for existing systems, not only for new installations.
Personally, I'm just now preparing a new system which I intend to use over several years, so the choice of the disk format does matter, in particular the question whether LUKS1 will look totally outdated in 5 years. If there was a reliable conversion path, I'd happily use LUKS1 now. Otherwise it might make sense to apply some non-standard package updates to use LUKS2 already today, before substantial amounts of data pile up on my encrypted partition.
LUKS1 vs LUKS2 is mostly about the header format. You can convert from one to the other. See man cryptsetup, convert subcommand. For data partitions you can safely use LUKS2. No extra hacks needed actually, it's supported by cryptsetup since 15.0 already. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.com/ SUSE Software Solutions Germany GmbH, GF: Felix Imendörffer HRB 36809 (AG Nürnberg)
On Wed, 2021-08-25 at 14:23 +0200, Ludwig Nussel wrote:
LUKS1 vs LUKS2 is mostly about the header format. You can convert from one to the other. See man cryptsetup, convert subcommand.
Yeah, we'd discussed that above. I guess the "convert" command only changes the header format without touching the actual data, right? In that case it'd be sufficient to backup the header before the operation.
For data partitions you can safely use LUKS2. No extra hacks needed actually, it's supported by cryptsetup since 15.0 already.
Well, I was looking into full-disk encryption. Thanks anyway. Martin
On 25/08/2021 12.09, Thorsten Kukuk wrote:
On Wed, Aug 25, Martin Wilck wrote:
On Wed, 2021-08-25 at 11:02 +0200, AW wrote:
Always and ever, but home partitions tend to have, like mine, hundreds of gigabyte and more. Reinstalling a system takes 90 minutes, but getting the home partition back is a completely other kind of sports.
Why do you want to convert an existing LUKSv1 home partition to LUKSv2?
As I understand it, AW did not want to convert, but worried that an automatic conversion would happen if the default changed. -- Cheers / Saludos, Carlos E. R. (from 15.2 x86_64 at Telcontar)
Am Mittwoch, 25. August 2021, 13:03:36 CEST schrieb Carlos E. R.:
On 25/08/2021 12.09, Thorsten Kukuk wrote:
On Wed, Aug 25, Martin Wilck wrote:
On Wed, 2021-08-25 at 11:02 +0200, AW wrote:
Always and ever, but home partitions tend to have, like mine, hundreds of gigabyte and more. Reinstalling a system takes 90 minutes, but getting the home partition back is a completely other kind of sports.
Why do you want to convert an existing LUKSv1 home partition to LUKSv2?
As I understand it, AW did not want to convert, but worried that an automatic conversion would happen if the default changed.
Yes.
AW wrote:
Am Montag, 23. August 2021, 15:13:04 CEST schrieb Ludwig Nussel:
For some years upstream cryptsetup already used LUKS2 as default on-disk format. The Tumbleweed package stayed with LUKS1 so far though. As grub 2.06 recently gained LUKS2 support, cryptsetup can finally switch. A cryptsetup 2.4.0 update is currently in staging and will likely land in TW soon. After that new installations will use LUKS2 for encrypted hard disks. Unfortunately grub2 can't handle Argon2 as key-derivation function yet. So TW has to stay with PBKDF2 for now.
Information about LUKS2 etc can be found upstream: https://gitlab.com/cryptsetup/cryptsetup/-/wikis/home
So the encrypted home partition -- LUKS1 -- on my SSD will after a certain zypper dup be encrypted with LUKS2 ?
Absolutely not. The intention was to use LUKS2 for newly created partitions. Existing volumes won't be touched and LUKS1 will basically work forever. Anyway as we've learned in this discussion even if cryptsetup uses LUKS2 by default yast would still continue to create LUKS1 volumes. So nothing changes actually. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.com/ SUSE Software Solutions Germany GmbH, GF: Felix Imendörffer HRB 36809 (AG Nürnberg)
participants (8)
-
Ancor Gonzalez Sosa -
AW -
Carlos E. R. -
Ludwig Nussel -
Martin Wilck -
Martin Wilck -
Michael Chang -
Thorsten Kukuk