On 04/25/2016 08:54 PM, Daniel Pocock wrote: > On 25/04/16 19:03, Christian Seiler wrote: >>> Does the workflow make sense? >> >> In principle yes, however it doesn't quite fit with my the >> workflow I'd like to use something like that for: my master key is >> on a two separate SD cards, and I only have one SD card reader. So >> what I do when I need to change something on the key is to insert >> one SD card, copy the .gnupg directory to a tmpfs, do the >> modifications, copy the directory back to the first SD card, and >> then copy the directory back to the second SD card. Any RAID >> solution wouldn't work for me, as I can't insert both cards at the >> same time. (Also, many people only have a limited amount of USB >> ports, and not every person wants to buy a hub just for this, so >> even with USB keys RAID might not always be easily possible, >> especially if you need one port for booting the system.) >> > > We could make it work that way > > One of the things that appeals to me about BtrFS is that if one flash > drive returns bad data, BtrFS will know which one has the good data > and the application won't have to compensate for that. Yes, but you'd still have to somehow communicate to the user that one of the drives was bad and that it has to be replaced, so the application will need to provide some kind of interface here. Also, in this case, if there really is corruption in essential data by the flash drive, this will immediately show up - as the public and private keys won't match in that case. > The solution you describe is feasible but would possibly require more > manual effort if one of the flash drives fail I don't believe so. btrfs replacement only works well if you have both the failed and the new drive plugged in (and at least the headers are accessible and good), otherwise you have to mount the device in degraded mode, manually add the new drive and then remove the missing one. Doable, but in my view this appears to be more complicated than a manual copy logic of a directory. > or if they become out of sync by way of human error. Yes, this would be the only advantage. On the other hand, at least with GnuPG 2.1+ (if I understand it correctly) the private keys are now just the mathematical paraemters required for usage. This in turn means that only the public keyring carries all the information (uids, expiry, etc.). And public keys can be merged without a problem. So for nearly all operations you could conceivably do (renewal, recovation, adding new subkeys [*], signing other people's keys) you don't actually need to keep them in sync explicitly, because you always take your public key with you to your normal system, so every time you boot the master key mgmt live CD, you have the master key drives as input for the secret key, but the public key can also come from the USB stick you use to interface the live CD with the rest of the world. I therefore don't see any real issue with synchronizing them. Additionally, I think there is a perfectly valid workflow where you don't modify all of the copies of the master key disk. For example, let's say I want to store one of the copies with family or in a safety deposit box, just as an additional backup against the house burning down or so. Then I generate the GPG key, make 3 copies, keep 1 of those copies for myself, store one in a safety deposit box at a local bank and give the other to e.g. my parents for safekeeping. For daily usage I just use my own copy of the master key, but if that fails (due to e.g. the flash drive giving up), I can use one of the other backups. > The Live DVD will have a terminal, like the installer, so anybody who > doesn't want to use the workflow can drop into the shell and do > whatever they want using the utilities that are present in the filesystem. Sure. I still think semi-automatic copies are easier to handle from an application standpoint than filesystem or block device RAID. Think of it this way: you need to put in 3 flash drives (be it USB sticks or SD cards) for normal operation if you only have a single copy: one for booting the live key management (unless you still have a CD drive, which my laptop e.g. doesn't), one that contains the master key, and one for exchanging data with the outside world. But if you just use copies, this is far easier: at the beginning you ask the user to plug in the master key flash drive. The .gnupg directory is then copied to a tmpfs ramdisk. The user is then told that they can remove the master key flash drive again and may now insert the flash drive used for data exchange with the outside world. The user then performs the operations they want to do (key renewal, signing of other users' keys, etc.). At the end they are asked to insert the master key flash drive again, causing the program to write any changes from the ram disk back. Then they are asked if they have additional copies of the master key flash drive and want to repeat the save operation. And if the user decides to create an additional copy for some reason, they can trivially do so at this step. I think this logic is far simpler and much more transparent for the user. >> [LUKS] >> > > That is a valid consideration but maybe it should be a wishlist item. Ack. >> Finally, I'm not sure I'd trust btrfs enough for this - especially >> in RAID mode if both devices are your only copy. I can't think of >> any feature in btrfs that might be required for this use case, so >> I'd rather stick with a plain ext4, at least by default. When it >> comes to this I'd rather be conservative. >> > > The BtrFS features I'm after are the RAID1 support and checksumming. > > MD and ext4 can do RAID1 but without checksumming. But I don't think checksumming is required here: if there is corruption in any relevant parts, it can immediately be detected by the application. Just let GPG check the self-signatures at the very beginning. And I also think that RAID is not the right way to go here. I think using simple copies is way more obvious than a RAID setup, especially if stuff goes wrong. Just my 2c. Regards, Christian [*] Either you don't actually store the secret sub key because you use a token, or you do store it, but you then need to make it accessible for everyday usage, so it's not only kept on the USB stick or SD card that contains the master key, but also on the machine you intend to using it from. And I don't see a use case for a subkey where the private key is only stored together with the master private key.
Attachment:
signature.asc
Description: OpenPGP digital signature