On Thu 2018-02-15 21:33:05 +0100, Juergen Christoffel wrote: > I'm looking for best practice tips for offline usage of GnuPG. What Do I > mean by offline usage? I plan to encrypt backups or files on my machines > with GnuPG and generate weekly or monthly keys for that purpose so backups > for example can run unattended and simply encrypt with today's public key. > As the backups need to be compatible with my software only, I could > possibly choose different configuration options than for my "online" usage.
GnuPG's defaults should be fine for the common, simple backup case. However, i note that you're talking about "today's public key" -- that suggests that you're imagining a regularly-updated key that your backup tooling will know about. This is in some sense antithetical to "offline usage" -- how will the backup scripts learn about the new keys if they can't go online to fetch them? It sounds like you're proposing an OpenPGP primary key that has a series of relatively short-lived, expiring encryption-capable subkeys. Is that correct? For further clarity, it'd be useful to understand what you see as the goal of key rotation here. Do you plan on deleting older secret subkeys? if so, how will you recover backups that were encrypted to the destroyed secrets? In an e-mail or messaging context, you can decrypt messages as they arrive, caching either the cleartext or the session keys; this allows you to rotate the asymmetric keys, destroying the old asymmetric secrets as they expire, which provides something approximating "forward secrecy". (see the recent improvements in version 0.26 of the notmuch mail user agent as an example of first steps on the way to implementing this strategy). But for backups, this is a slightly more complicated story. It certainly can be useful if you want to be able to robustly *destroy* backups that might be stored on servers that you don't have full control over. That is: encrypt the backup to public key X, send the encrypted copy to "the cloud", and then when you're sure you don't need it any more, delete the secret key corresponding to X to ensure that it's not recoverable. But most people have a hard time just getting their backups to happen on a reasonable schedule, and don't have a reliable schedule for backup destruction. Do you have such a plan? Or do you envision some other reason for the proposed key rotation? --dkg
signature.asc
Description: PGP signature
_______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users