-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
On 25/04/16 23:06, Christian Seiler wrote: > 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. > Some code is now available for building the bootable CD/DVD image: https://wiki.debian.org/OpenPGP/CleanRoomLiveEnvironment#Code It ensures the dependencies are all present, other workflow stuff is not implemented yet -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJXHx3RAAoJEGxlgOd711bE0ZoQAKjX53q3kKmUBgDhKgI7/CRu ebnq0m17cwwjDAOBg0RWBUXtBMVlUng9dwA7OHaGqTpx/cgOMWkdDqfAjB/QvAw9 QO6O6HqJtEe/zB5xEGyL3RoiyC0GJ+J2IfOVgZ650Zkk+tqWPtr6RdKvx1ZfFiVX ycaUzGWhYCKX93kCCNE87cBzFRaL4+rEs95nQ7QvyHlsP/QXLSV8xVQCFOxUaEjR lfPIZeUdmHsRL8txgM4/mn4udSLw55fYv4uwp6kGfau82O7voEybl9jskDrOtWum oSQmxqrKwukRGCefmSuc2rma60CRsuGUqcIhQ0729miuoJ608pLfAYf9d/8UC7NI SMaf6H/gi1exQjpGICR0ecOWWaF6duFQr7NUbVN21OCfd/ybOY8QasVCUqXvbJbz OgAk6tuDRyRLXdyYnLQ9rntn5oHKWe1jIaaocAgnrPaxtz45uK15FTkUC3exMMzm xZdckJ93kBjYAO5QNHP4h1vOGNdR+2wLRCq2tslREqJB7Bt70hr2Dfctq86DHWzu VYAxAs3Qi4OrTVq2nycI5Go/M8fMnH/xKDP9DIrzwF6NuM55gmhCkGweTBcJj1gH qQv5MNKMrD8vbU7u3RXOZaPbkwZdID7MQVAnVol8S5rMOLWrDW/Mkh/Mv6C5MrMs +UUKqIPdkIORScF9Ssmg =9n2u -----END PGP SIGNATURE-----
