| 29 Jul 2022 |
 K900 | So you can build one EFI executable and sign it for secure boot | 06:15:25 |
| K900 | Without the bootloader or whatever having to validate the initrd, etc | 06:15:37 |
| K900 | You just put it all in a big blob and sign the blob | 06:15:53 |
 Winter (she/her) | interesting
wait yeah so where are these magic section offsets from, did you pull those from sbctl or some spec or something | 06:16:22 |
| K900 | It's not ideal for NixOS because we end up with a big blob for every generation because the cmdline changes | 06:16:25 |
| Winter (she/her) | * interesting
wait yeah so where are these magic section VMAs from, did you pull those from sbctl or some spec or something | 06:16:41 |
| K900 | But I don't think we have any good ways around it except, uh, writing our own bootloader? | 06:16:45 |
| Winter (she/her) | the purely functional bootloader 🚀 | 06:16:58 |
| K900 | https://www.freedesktop.org/software/systemd/man/systemd-stub.html | 06:17:22 |
| K900 | That has the invocation example | 06:17:28 |
| K900 | Technically I don't think the offsets matter | 06:17:32 |
| K900 | It looks at the ELF headers | 06:17:37 |
| K900 | So as long as it fits in memory it should be fine | 06:17:52 |
| K900 | We can always bump it if the kernel gets bigger than 32M or whatever it currently has | 06:19:03 |
| Winter (she/her) | my questions are probably going off topic for here but like, idk, how did you start making this and finding all of that stub stuff and such? like i understand what's going on but how did you find all the info, did you look at the example bootspec stuff too? | 06:19:07 |
| K900 | https://wiki.archlinux.org/title/Unified_Extensible_Firmware_Interface/Secure_Boot | 06:19:40 |
| K900 | The Arch people have great docs on setting up secure boot | 06:19:49 |
| K900 | Also reading sbctl code and talking to sbctl people | 06:20:30 |
| K900 | I haven't actually looked at Graham's thing much, kind of intentionally | 06:21:37 |
| K900 | Because I wanted to see the footguns for myself | 06:21:56 |
 @v0id:nltrix.net | https://www.nist.gov/news-events/news/2022/07/nist-announces-first-four-quantum-resistant-cryptographic-algorithms | 10:51:47 |
| @v0id:nltrix.net | adjust your avx2 to burn ntt's soon. | 10:52:08 |
| @v0id:nltrix.net |
~600 byte signatures, >~1600 secret keys.
| 10:56:20 |
| @v0id:nltrix.net | *
~600 byte signatures, >~1600 secret keys.
| 10:56:28 |
| @v0id:nltrix.net | * . > ~600 byte signatures, >~1600 secret keys. | 10:56:31 |
| @v0id:nltrix.net | * . > ~600 byte signatures, >~1600 bytes secret keys. | 10:56:43 |
| 30 Jul 2022 |
| Winter (she/her) | If any PAM-knowledgable person wants to take a look at something, https://github.com/NixOS/nixpkgs/pull/173495 is looking for reviewers (and I can't think of anyone offhand). | 04:12:40 |
 vcunat | In reply to @v0id:nltrix.net
. > ~600 byte signatures, >~1600 bytes secret keys. Not exactly. SPHICS+ has short keys. 32B public, 64B private. But the signatures are even longer. (I think; I've only looked at these superficially so far.) | 06:15:19 |
| vcunat | In reply to @v0id:nltrix.net
. > ~600 byte signatures, >~1600 bytes secret keys. * Not exactly. SPHINCS+ has short keys. 32B public, 64B private. But the signatures are even longer. (I think; I've only looked at these superficially so far.) | 06:18:40 |
| vcunat | We can still be putting hopes into (link):
New Call for Proposals: Digital Signature Algorithms with Short Signatures and Fast Verification
I'm in particular interested in DNSSEC and the current lengths are very problematic with UDP.
| 06:21:56 |
