| 22 Dec 2024 |
 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 |
| Enzime | interesting, I wonder if back when they designed it they just didn't see it as a valuable enough property to have by default? | 01:02:24 |
| Enzime | it's probably more that it's just a part of another building block in a cryptosystem and there'll be situations when you wanted unauthenticated encryption | 01:03:00 |
| waltmck | yeah, that's a big part of it. There were papers of micali and goldwasser giving cryptosystems with authenticity only a couple of years after the original probabilistic encryption paper, so it is probably more on the adopters | 01:04:23 |
| Enzime | not sure if you've read this but tangentially related | 01:05:08 |
| Enzime | https://words.filippo.io/dispatches/age-authentication/ | 01:05:09 |
| waltmck | There are a lot of desirable guarantees that we don't have even now. For instance there are "deniable encryption" schemes which are provably indistinguishable from random bits. The idea is that you can claim that the data is just random and nobody can tell if you are lying or if you have a decryption key | 01:05:39 |
| Enzime | In reply to @waltmck:matrix.org
There are a lot of desirable guarantees that we don't have even now. For instance there are "deniable encryption" schemes which are provably indistinguishable from random bits. The idea is that you can claim that the data is just random and nobody can tell if you are lying or if you have a decryption key I think VeraCrypt has support for this | 01:06:00 |
| Enzime | In reply to @waltmck:matrix.org
There are a lot of desirable guarantees that we don't have even now. For instance there are "deniable encryption" schemes which are provably indistinguishable from random bits. The idea is that you can claim that the data is just random and nobody can tell if you are lying or if you have a decryption key until they look at your NixOS config on GitHub :p | 01:06:31 |
| waltmck | Any idea what is going wrong here? | 04:58:19 |
