Comment forcer gpg2 à utiliser une clé expirée?

14

$ gpg -ear XXXXXXX
gpg: XXXXXXXX: skipped: unusable public key

$ gpg --debug-ignore-expiration -ear XXXXXXXX
gpg: Invalid option "--debug-ignore-expiration"

Comment crypter? Aucune mise à jour de la clé n'est disponible auprès des serveurs de clés. Les messages doivent être vus si l'utilisateur a toujours cette clé expirée ou pas du tout vu.

Y a-t-il une --just-do-that-I-wantoption qui permettra de le faire sans changer le code source de GPG?

gnupg cryptography expired-key

— Vi.
source

pourquoi tu veux faire ça? Il brise fondamentalement toute la sécurité Thing GPG est sur le point que vous pouvez littéralement l'envoyer en clair si vous faites cela. Je vous recommande de simplement demander à la personne destinataire de mettre à jour sa clé publique

— konqui

L'utilisation d'une clé expirée depuis longtemps offre une meilleure sécurité que l'utilisation d'aucune clé. Il peut également être nécessaire de déchiffrer l'ancien message de l'archive à l'aide de l'ancienne clé expirée depuis longtemps.

— Vi.

Shure a également peut-être un cryptage cassé meilleur que pas de cryptage du tout. Je l'exagère simplement à cause des raisons. Pour les anciens messages chiffrés avec l'ancienne clé publique à l'époque, oui, il doit utiliser son ancienne clé privée, mais cela ne me permet pas de créer une nouvelle paire de clés à utiliser pour les nouveaux messages. Il n'y a donc vraiment aucune raison d'utiliser une clé publique obsolète. La clé privée est une autre chose mais je n'ai jamais eu de gpg se plaindre de l'utilisation d'une clé privée obsolète pour Decription.

— konqui

12

Comme l'a suggéré @rob dans les commentaires, libfaketime gère bien ceci:

$ gpg  -v -v -v --batch --trust-model always -ear D5B9D38C <<< "qweqe"
gpg: using character set 'utf-8'
gpg: Note: signature key 077EA269D5B9D38C expired Sun 09 Nov 2014 12:57:25 PM +03
gpg: D5B9D38C: skipped: Unusable public key
gpg: [stdin]: encryption failed: Unusable public key

$ faketime  '2012-12-24 08:15:42'  gpg  -v -v -v --batch --trust-model always -ear D5B9D38C <<< "qweqe"
gpg: using character set 'utf-8'
gpg: using subkey 85231B396B9569ED instead of primary key 077EA269D5B9D38C
gpg: No trust check due to '--trust-model always' option
gpg: reading from '[stdin]'
gpg: writing to stdout
gpg: RSA/AES256 encrypted for: "..."
-----BEGIN PGP MESSAGE-----
...

Ancienne réponse:

Démarrez UML (mode utilisateur Linux)
Réglez la date dans UML sur une plage acceptable.
Crypter le message en UML

— Vi.
source

1

Peut également truquer la date en utilisant libfaketime. Même idée que la réponse, mais pourrait être plus facile pour certains.

— voler

2

il n'y a sérieusement pas d'option --force, donc seulement un hack de date suffit-il? m (

— mcantsin

3

Utilisez l' --faked-system-timeoption:

gpg2 --faked-system-time 20100101T000000 -e -r keyid

Je préférerais une option qui forcerait le cryptage à une clé expirée tout en enregistrant l'heure correcte (en particulier lors de la signature).

— Margaret
source

2

Réinitialiser le matériel et l'horloge système:

sudo hwclock --set --date "12/31/2017 23:59:59" && \
sudo hwclock --hctosys && \
gpg --sign-with $keyid --clearsign --armor < $file

Ensuite (j'espère que vous avez activé NTP) réparez votre horloge matérielle avec:

sudo hwclock --systohc

— client
source

2

Trop drastique. L'heure doit être remplacée uniquement pour gpg, pas pour l'ensemble du système.

— Vi.

2

faketime '2012-12-24 08:15:42' gpg ...est mieux.

— Vi.