| 17 Jul 2021 |
 Mic92 | Also interesting: https://github.com/mtth-bfft/tpm-otp | 08:18:28 |
 andi- | In reply to @mic92:nixos.dev
The key for what? The key for the passwords. | 08:47:47 |
| Mic92 | In reply to @andi:kack.it
The key for the passwords. It seems like a small win in security for an increased complexity, since the passwords itself are still in plain | 08:48:57 |
| andi- | Yeah but it defeats all kinds of offline attacks on my password database | 08:49:24 |
| andi- | you can use my entire disk and still have no way to decrypt my passwords. Not even if you also have a memory dump. | 08:49:38 |
| andi- | You only obtain what you can observe me requesting. | 08:50:02 |
| Mic92 | I can imangine for most people the risk of loosing access to all their passwords is higher when their hardware breaks than the added security. | 08:51:56 |
| Mic92 | * I can imagine for most people the risk of loosing access to all their passwords is higher when their hardware breaks than the added security. | 08:52:18 |
| andi- | I would only loose access to keys on that machine and not all my passwords. | 08:52:50 |
| andi- | which is a perfectly acceptable risk for me as I can still use my YubiKey to access passwords (or another device with the same scheme). | 08:53:32 |
| andi- | In reply to @mic92:nixos.dev
Also interesting: https://github.com/mtth-bfft/tpm-otp This looks like it wouldn't go well with other TPM applications as they try to manage the TPM directly and write to random nvram positions. | 09:17:56 |
 @grahamc:nixos.org |
Corrected a problem which generated improper hash values on 16 bit machines
| 23:34:21 |
| @grahamc:nixos.org | damn this file has a LOT of history | 23:34:58 |
| 18 Jul 2021 |
| @grahamc:nixos.org | okay andi- I was maybe predictable wrong about the rvram | 00:40:08 |
| @grahamc:nixos.org | to r/w space you have to preallocate a chunk with nvdefine, and it gives you an "NV Index" in response: | 00:40:49 |
