| 22 Dec 2024 |
 Enzime | as an immutable root? | 00:35:25 |
 waltmck | sys is unencrypted | 00:35:37 |
| Enzime | why not just encrypt it all? | 00:36:19 |
| Enzime | I'm not sure if you already have code to auto-rollback the root on each boot, you should be able to do something like:
https://github.com/Enzime/dotfiles-nix/blob/main/hosts/sigma/hardware-configuration.nix#L57-L59
https://github.com/Enzime/dotfiles-nix/blob/main/modules/impermanence.nix#L20-L31 | 00:37:16 |
| waltmck | That would also be reasonable. I don't see why it would necessarily be better than encrypting just the mutable parts | 00:37:16 |
| Enzime | In reply to @waltmck:matrix.org
That would also be reasonable. I don't see why it would necessarily be better than encrypting just the mutable parts I guess it would just simplify because you could make sys your rootfs dataset and have one less dataset | 00:37:43 |
| waltmck | In reply to @enzime:nixos.dev
I'm not sure if you already have code to auto-rollback the root on each boot, you should be able to do something like:
https://github.com/Enzime/dotfiles-nix/blob/main/hosts/sigma/hardware-configuration.nix#L57-L59
https://github.com/Enzime/dotfiles-nix/blob/main/modules/impermanence.nix#L20-L31 yeah, I do that on my laptop. I think it's more inconvenience than it's worth so I'm planning on scrapping it | 00:37:44 |
| waltmck | I have ran into terrible issues where impermanence fails to mount something and it prevents a usable system from booting | 00:38:19 |
| waltmck | In reply to @enzime:nixos.dev
I guess it would just simplify because you could make sys your rootfs dataset and have one less dataset One reason is that I am using dedup on my /nix partition, so it has to be a separate dataset anyway. dedup on root would be ill-advised | 00:39:00 |
| waltmck | In reply to @enzime:nixos.dev
I guess it would just simplify because you could make sys your rootfs dataset and have one less dataset * One reason is that I am using dedup on my /nix dataset, so it has to be a separate dataset anyway. dedup on root would be ill-advised | 00:39:18 |
| Enzime | I'm not too familiar with dedup, sys and sys/nix are separate-ish datasets no? | 00:40:06 |
| Enzime | In reply to @waltmck:matrix.org
I have ran into terrible issues where impermanence fails to mount something and it prevents a usable system from booting I haven't had a chance to try it but I heard this is better than impermanence | 00:40:20 |
| Enzime | https://github.com/willibutz/preservation | 00:40:22 |
| Enzime | In reply to @waltmck:matrix.org
I have ran into terrible issues where impermanence fails to mount something and it prevents a usable system from booting * I haven't had a chance to try it but I've heard this is better than impermanence | 00:40:28 |
| waltmck | In reply to @enzime:nixos.dev
https://github.com/willibutz/preservation I'll take a look at that! | 00:41:17 |
| waltmck | In reply to @enzime:nixos.dev
I'm not too familiar with dedup, sys and sys/nix are separate-ish datasets no? ah I see what you mean here. Yeah, root could be mounted on sys (if I encrypted sys) | 00:41:41 |
| waltmck | There is some performance improvement to not encrypting /nix, though it probably isn't very large. Mostly I think it is just cool to be able to have encrypted and unencrypted data on the same filesystem | 00:43:18 |
| Enzime | In reply to @waltmck:matrix.org
There is some performance improvement to not encrypting /nix, though it probably isn't very large. Mostly I think it is just cool to be able to have encrypted and unencrypted data on the same filesystem the only thing to be aware of is if you don't have anything ensuring the integrity of /nix, theoretically an attacker could update sudo in your /nix/store | 00:48:42 |
| waltmck | My hardware doesn't support verified boot anyway, they could just modify /boot | 00:49:42 |
| waltmck | * My hardware doesn't support secure boot anyway, they could just modify /boot | 00:50:11 |
| Enzime | yeah fair enough | 00:51:02 |
| waltmck | also, at least in principle AES does not verify data integrity (only confidentiality). I don't know if ZFS has an additional MAC for integrity, but I don't see that in their docs | 00:53:48 |
| waltmck | Ah wait never mind, ZFS uses galois counter mode which does guarantee integrity | 00:56:27 |
| Enzime | In reply to @waltmck:matrix.org
also, at least in principle AES does not verify data integrity (only confidentiality). I don't know if ZFS has an additional MAC for integrity, but I don't see that in their docs would someone not need your key to encrypt the bytes the same so that when they're decrypted they come out as what the attacker wants? | 00:56:53 |
| waltmck | In reply to @enzime:nixos.dev
would someone not need your key to encrypt the bytes the same so that when they're decrypted they come out as what the attacker wants? no, not necessarily. Like in CTR mode they could easily compute an encryption of the XOR of your plaintext with an arbitrary string | 00:57:52 |
| Enzime | I guess I'm not super familiar with the different AES modes | 00:58:16 |
| Enzime | In reply to @waltmck:matrix.org
Ah wait never mind, ZFS uses galois counter mode which does guarantee integrity never knew what GCM stood for 😆 | 00:58:25 |
| Enzime | In reply to @waltmck:matrix.org
no, not necessarily. Like in CTR mode they could easily compute an encryption of the XOR of your plaintext with an arbitrary string that's just because it's been broken, not by design right? | 00:58:51 |
| waltmck | AES in CTR mode is provably confidential (assuming AES is actually a pseudorandom function, which is thought to be the case) | 01:01:00 |
| waltmck | That was always its only guarantee. It can be combined with other cryptographic primitives (like message authentication codes) to get integrity/authenticity, but by itself it is neither | 01:01:41 |
