Skip to main content
more options
Source Link
Xen2050
  • 227
  • 1
  • 7

Since your commenting "For convenience, but also because I don't want to accidentally change the password and lose information" I'd suggest using a keyfile instead, it won't change. And gpg wouldn't know what cached passphrase you wanted to use when symmetrically encrypting a new file anyway.

But storing and using a keyfile safely becomes an issue. Storing it encrypted should be safe.

  • Using a very small LUKS container should store and decrypt it safely
  • Or store it encrypted in a gpg file, and extracted to ramfs (note tmpfs could be written to cache).

Then you can close the LUKS container or delete the file whenever you want to, and not worry about entering the passphrase correctly the first time if you only relied on gpg-agent's own caching.

Or, just use a gpg public key.


There's also gpg-preset-passphrase to "Put a passphrase into gpg-agent's cache":

The gpg-preset-passphrase is a utility to seed the internal cache of a running gpg-agent with passphrases. It is mainly useful for unattended machines, where the usual pinentry tool may not be used and the passphrases for the to be used keys are given at machine startup.

Passphrases set with this utility don't expire unless the --forget option is used to explicitly clear them from the cache --- or gpg-agent is either restarted or reloaded (by sending a SIGHUP to it). Note that the maximum cache time as set with --max-cache-ttl is still honored. It is necessary to allow this passphrase presetting by starting gpg-agent with the --allow-preset-passphrase.

Since your commenting "For convenience, but also because I don't want to accidentally change the password and lose information" I'd suggest using a keyfile instead, it won't change. And gpg wouldn't know what cached passphrase you wanted to use when symmetrically encrypting a new file anyway.

But storing and using a keyfile safely becomes an issue. Storing it encrypted should be safe.

  • Using a very small LUKS container should store and decrypt it safely
  • Or store it encrypted in a gpg file, and extracted to ramfs (note tmpfs could be written to cache).

Then you can close the LUKS container or delete the file whenever you want to, and not worry about entering the passphrase correctly the first time if you only relied on gpg-agent's own caching.

Or, just use a gpg public key.

Since your commenting "For convenience, but also because I don't want to accidentally change the password and lose information" I'd suggest using a keyfile instead, it won't change. And gpg wouldn't know what cached passphrase you wanted to use when symmetrically encrypting a new file anyway.

But storing and using a keyfile safely becomes an issue. Storing it encrypted should be safe.

  • Using a very small LUKS container should store and decrypt it safely
  • Or store it encrypted in a gpg file, and extracted to ramfs (note tmpfs could be written to cache).

Then you can close the LUKS container or delete the file whenever you want to, and not worry about entering the passphrase correctly the first time if you only relied on gpg-agent's own caching.

Or, just use a gpg public key.


There's also gpg-preset-passphrase to "Put a passphrase into gpg-agent's cache":

The gpg-preset-passphrase is a utility to seed the internal cache of a running gpg-agent with passphrases. It is mainly useful for unattended machines, where the usual pinentry tool may not be used and the passphrases for the to be used keys are given at machine startup.

Passphrases set with this utility don't expire unless the --forget option is used to explicitly clear them from the cache --- or gpg-agent is either restarted or reloaded (by sending a SIGHUP to it). Note that the maximum cache time as set with --max-cache-ttl is still honored. It is necessary to allow this passphrase presetting by starting gpg-agent with the --allow-preset-passphrase.

Source Link
Xen2050
  • 227
  • 1
  • 7

Since your commenting "For convenience, but also because I don't want to accidentally change the password and lose information" I'd suggest using a keyfile instead, it won't change. And gpg wouldn't know what cached passphrase you wanted to use when symmetrically encrypting a new file anyway.

But storing and using a keyfile safely becomes an issue. Storing it encrypted should be safe.

  • Using a very small LUKS container should store and decrypt it safely
  • Or store it encrypted in a gpg file, and extracted to ramfs (note tmpfs could be written to cache).

Then you can close the LUKS container or delete the file whenever you want to, and not worry about entering the passphrase correctly the first time if you only relied on gpg-agent's own caching.

Or, just use a gpg public key.