| 22 Dec 2024 |
 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 |
| 24 Dec 2024 |
|  karlthane joined the room. | 14:11:01 |
| 25 Dec 2024 |
|  Tanja (she/her) changed their display name from Tanja (she/her) to Tanja (she/her) [DECT 6929]. | 14:48:11 |
| 26 Dec 2024 |
|  phaer changed their display name from phaer to phaer (8650 at 38c3). | 17:41:28 |
| 27 Dec 2024 |
|  raitobezarius changed their display name from raitobezarius to raitobezarius (DECT: 3538 / EPVPN 2681). | 07:32:26 |
|  rendakuenthusiast⚡️ left the room. | 08:42:28 |
|  pinpox changed their display name from pinpox to pinpox [DECT: 7170]. | 15:22:44 |
| 28 Dec 2024 |
 Mic92 | #ccc-nixos:lassul.us | 17:52:31 |
