¿Cómo evitar que gnupg descifre archivos automáticamente?

Estoy en OSX 10.13.4, estoy aprendiendo a usar gnupg desde el terminal. Encripte un archivo con

gpg --cipher-algo AES256 -c input.txt -o output.gpg

me pidió una contraseña, hice una, el archivo ahora está encriptado. Pero entonces, cuando emito el comando, gpg -d output.gpglo descifra sin pedirme la contraseña? _?

¿Cómo evito eso?

EDITAR

Siguiendo esta he puesto max-cache-ttl 0en .gnupg/gpg-agent.confy parece que funciona, puede alguien confirmar que esto es lo que hay que hacer?

Establecer max-cache-ttl 0en su .gnupg/gpg-agent.confarchivo parece ser una buena solución. Especialmente porque funciona.

También existe la opción gpg-agent --no-allow-external-cacheque se supone que debe:

Dígale a Pinentry que no habilite las funciones que usan un caché externo para frases de contraseña.

Algunos entornos de escritorio prefieren desbloquear todas las credenciales con una contraseña maestra y pueden haber instalado un Pinentry que emplea un caché externo adicional para implementar dicha política. Al usar esta opción, se recomienda a Pinentry que no utilice dicho caché y, en su lugar, siempre solicite al usuario la frase de contraseña solicitada.

Eso suena como si siempre debe pedir la frase de contraseña, pero no parece que hacer eso. O, solo siempre pregunta, cuando existe un caché externo.

O bien, puede seguir permitiendo que las frases de contraseña de caché gpg-agent, sino en la demanda eliminarlas con enviando una SIGHUPseñal (con kill, killall, pkill, etc):

Esta señal vacía todas las frases de contraseña almacenadas en caché y si el programa se ha iniciado con un archivo de configuración, el archivo de configuración se vuelve a leer. Solo se respetan ciertas opciones: quiet, verbose, debug, debug-all, debug-level, debug-pinen‐ try, no-grab, pinentry-program, pinentry-invisible-char, default-cache-ttl, max-cache- ttl, ignore-cache-for-sign, no-allow-external-cache, allow-emacs-pinen‐ try, no-allow-mark-Trusted, disable-scdaemon y disable-check-own-socket. El programa scdaemon también es compatible, pero debido a la implementación actual, que llama al scdaemon solo una vez, no es de mucha utilidad a menos que elimine manualmente el scdaemon