| 22 Dec 2024 |
 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 |
| waltmck | It looks like the ZFS pool is not being created, my config is here | 05:00:27 |
| waltmck | (and I have my datasets defined here) | 05:00:47 |
| waltmck | never mind, I ran the same command again and it seems towork | 05:10:59 |
| waltmck | some of this disko stuff is really strange, it is so close to being idempotent but then it isn't at weird times | 05:16:23 |
| waltmck | I had this happen to me once before on a remote server and it required me to manually wipe the disk. Probably this is just under-tested since people rarely provision disks | 05:16:53 |
|  allrealmsoflife joined the room. | 15:54:30 |
|  @xvwx:matrix.dapp.org.uk joined the room. | 18:48:01 |
| 23 Dec 2024 |
 blimbus | both disks seem to have devices properly defined unless I'm missing something. This is what I get from repl:
nix-repl> disko.devices.disk.nix.device
"/dev/disk/by-id/ata-QEMU_HARDDISK_QM00003"
nix-repl> disko.devices.disk.home.device
"/dev/disk/by-id/ata-QEMU_HARDDISK_QM00005"
| 00:06:24 |
